Getting Started by Getting Agile
In an earlier weblog entry, I stated that I had become frustrated with Coder to Developer. I felt that the author breezed past areas that deserved attention, and slowed down and addressed areas that did not need attention. By way of example, the author writes, “There is a valuable discipline of software architecture, and for even small projects it remains a good starting point,” and then pulls from his hat an architectural diagram. Where did it come from? How did he arrive at it? To me, that is as useless as a cooking book that provides a list of ingredients on one page, a photograph of the finished dish on the following page, with no pages in between providing the cooking instructions.
I put Coder to Developer to one side, and started reading Code Complete by Steve McConnell. In the first two parts of the book, the author talks about the value of planning and the basic approach to application design. The operative word there is basic; this is not the how-to book that I yet hope to find. Still, any guide is better than no guide, so I again put pen to paper and started designing Charlie.
As my diagrams became more involved, I felt increasingly that I was not planning, but guessing. I felt that I simply do not have the experience necessary to know what designs would work, and what would not. I still believed that I could make Charlie a first-class application, but not by designing too much of it up-front.
Inertia set in.
A few days later I happened to purchase the Australian edition of International Developer magazine. In it was yet another article on Agile development. I scanned the article, and upon viewing two diagrams I had an “ah ha” moment. The diagrams were as follows.
Above: The Traditional Development Process
Above: The Agile Development Process
For two reasons, these diagrams spoke to me in a way that all prior articles on Agile development had not spoken to me. First, while I had understood the frequency of Agile’s iterations, I had not appreciated the changing scope of those iterations. Second, my own application had already stalled in the design phase, and I could not see how to move foward.
Agile development was offering a solution to my problem. The second diagram above whispered in my ear that it was okay to design only a part of Charlie, and then build it, test it, and deploy it. Having done so, I could increase the scope of Charlie's design, without having to guess at what more the design would need. This concept of iterative development of increasing scope was the motivational force I needed to overcome the inertia that had set in.
Now, I am not suggesting that I have decided upon an Agile development methodology. I still do not sufficiently understand it to suggest that I am applying it. But I am happy to prise from Agile a gem of an idea, and give it to Charlie.
by Alister Jones | Next up: Advice from an Aardvark →
----
Post a Comment