// On Agile software development

My biggest passions in software development these days include Agile software development, architectural design, and functional, attractive user interfaces. While my first and favorite love is code, my primary focus these days is more on the processes and team structures that lead to rapidly developed high quality products. While I'm by no means and expert at these yet, I'm a firm believer in Agile and Scrum and avid practitioner of these whenever possible. I believe that continuous integration and thorough automated testing are critical to the success of any large-scale, long-term project. I've even experienced the surprising, counter-intuitive benefits of Pair Programming.

Sadly, most teams I've been a part of have done none of these and it was plainly evident; the overwhelming need for dedicated testers to catch even trivial bugs, the amount of seemingly daily refactoring necessary to compensate for short-sighted, tightly-coupled design, and the  surprising lack of communication among team members leading to significant information silos. All of this contributes to the generally slow plod of development that most people seem to think is normal, acceptable, even optimal.

Among the biggest challenges of adopting Agile practices is the mental transition. Established teams are usually resistant to change, refusing to believe their process can be meaningfully improved. There can be figurative kicking and screaming as they are made to adopt processes they foresee no benefit from, but it's worth it. Eventually there will be a moment when their eyes are opened. Perhaps it's a unit test that breaks unexpectedly when a seemingly unrelated piece of code is changed, or perhaps they gain confidence as they watch the burn-down progress towards a completed sprint. Maybe they even finally buy into the value of code reviews when they begin to see the consistency of the code base improve. Despite their resistance at first, once they begin to see the benefits first-hand there's no going back.

I've been fortunate enough to be on teams transformed by adopting these development strategies and I've seen teams who have spent years mastering them.  I know the before and the after, and I know which side of that line I want to be on.