Saturday, July 14, 2007

to read: The World is Flat

read more here Amazon.com: The World Is Flat: A Brief History of the Twenty-first Century: Books: Thomas L. Friedman

Friday, July 13, 2007

Agile Methodology: A first take

Agile methodology, extreme programming, test driven development go hand in hand and complement each other to help software engineers to create value for people at large and avoid the proverbial 'tar pit'.

Here, is my primer for the much appreciated methodology:
  1. Software Configuration Management: You can have nothing else in your technical environment other than a version tool and still manage the 'chaos' if you can uniquely answer Who did it? What did he do? When did he do? Why did he do that? (optional but strongly recommended.)
  2. Planning: Here it is important to understand the concept of a plan. A plan is a road map to move from point A to a point B and steps required to return back to the starting point A. The relevance of such a concept of a plan becomes easy to digest if one considers that a change in the a software artifacts is analogous to the experiment conducted in a lab, in a controlled environment. The risk involved must be controlled and if even after the best attempt the experiment fails one could always return back to the last known stable state of the system. Care must be taken that while it is fairly easy to plan to move ahead, it requires a thinking mindset to retrace back after cleaning your footprints in case some goof up happens.
  3. Unit Testing: Let's take the simplistic concept of 'unit' as the piece of code block which completes a logical set of activity to achieve a single objective and no more. While writing the test cases one must remember Pareto's 80/20 principal while writing important test cases plus the test cases which ensures that the system is performing as expected with the right set of inputs. There is no point in being over ambitious by attempting to write exhaustive test cases for a discrete system. Unit testing really shines during regression cycles, where in you can ensure that any new line of code is not breaking the existing system and can easily measure and monitor the 'ripple effect' if any. Please do not assume the being easily done is easy :)
  4. Feedback Loop: Make it short and make it fast. Doing this will help you identify the problem early and save COST. There are tools available today for continuous integration which can really help one to achieve this end.
The above is not merely a listing of my random thought about this methodology, but is an incremental set activity that one might need to undertake to completely embrace this practice from being an absolute novice.