The Crooked Path to Quality
Obviously, if you want a high quality product with a clean codebase and low defect counts, you need to be very careful and methodical in your approach to developing software. Ready-Fire-Aim is a sure road to disaster, leading to chaos and confusion. Not only that, but it speaks to a general immaturity and lack of professionalism of the development team and its members. That is, unless you iterate rapidly and continuously improve.
I’m not a fan of the word “Agile”, as I feel that people have already formed their opinion of what Agile is, and generally I don’t agree with them. Instead, I prefer to speak about particular aspects of my interpretation of Agile. Regardless of your opinion on Agile, it’s hard to argue against the value of rapid iteration and continuous improvement. When you iterate rapidly you find design flaws and bugs quickly. When you continuously improve, you fix design flaws and bugs quickly. The result is what some call “chaos”, but I call it progress.
I like progress — a lot — but I wasn’t always this way. I mean, I would tell people I liked progress, and even believed that I did, but the reality was that I was so obsessed about producing high quality code with a low defect count that I forgot the point of software development — to develop software. What I have now realized is that to arrive at quality code, I have to iterate my way towards it in order to make incremental progress, which is more important to me than arbitrary point-in-time subjective assessment of quality. The path is crooked, and at times chaotic, but if you are backed up by a strong team fully bought in to rapid iteration and continuous improvement, then I highly recommend you give it a shot. Just don’t call it Agile.