I bumped into one of my former project managers a few months back. We talked a little about how things were going on the old project (which by all accounts goes live tomorrow... 3 years and 7 months late) and how things were for me in my new position. I told him a bit about XP and how much I enjoyed it. He seemed rather sceptical about how it could be costed. A couple of days later I came across this article and forwarded it to him.
Sometime later he replied. Part of his reply was, as he put it, "a bit controversial to stimulate the debate". After a few days of thought and few weeks of procrastination I replied, here it is:
PM: The Current Climate – the software industry does not have a good track record in delivering large projects. Therefore, customers are very nervous about entering into what they see as an open ended contract. From experience, it is very difficult to secure funding when you can’t guarantee what will be delivered at the end or when.
Having spent most of my IT career in the public sector I had no reply to this. I suppose I could have argued the "what will be delivered at the end" saying that a customer would get exactly what the customer wants and needs, but I guess his point was about funding.
PM: Design – the agile approach assumes an ongoing design process. The software industry is pretty unique in this regard. In most other industries (eg construction), no-one would contemplate starting a project without a completed design……why should software be any different? I have bitter experience of developers having to re-factor code (which really meant rip it up and start again) because module x no longer worked with the new architecture.
Me: Please tell me you aren't trying to compare the job of a programmer to a brick layer? The waterfall approach of Big Design Up Front has been almost completely discounted by the agilists. The reason I see for this reaction is that, at a detailed level it's almost impossible to fully understand every eventuality/path through a software system. If you were to try to envisage and document every scenario, my guess is that you would have spent as much (if not more) time than it would have taken to develop a working system. Not a complete working system that meets all of their business needs, but one that could meet their most critical business needs earlier and could be put into production and be of value.
Another major issue (which ties back to your earlier point) is that customers don’t know what they want, especially not from a large system and they can’t be expected to. They are the best people to understand the domain problem they have of course, but not the best solution that solves that problem especially not upfront. That’s why designing and implementing a large system before letting a customer use it is why, I guess, the software industry has a bad reputation.
As for refactoring, it is about refining code to: increase quality; re-useability; maintainability; simplicity; etc, all of the things that reduce bugs, please customers and make applications easier and cheaper to maintain and modify going forward. Refactorings like you suggest, where large steps are taken to rewrite areas of code, occur when the processes of incremental design and refactoring are not put in place.
PM: Quality – the quality argument in the article seemed to skip over the fact that a bad programmer is a bad programmer no matter what methodology you use. The article (and fans of agile programming) suggests that agile programming is the panacea and will solve all the quality problems….garbage! At the end of the day, the customer still has to have a working system (i.e., bug-free).
Me: A bad programmer is a bad programmer I agree. But with techniques like test driven development (TDD) and pair programming a bad programmer can become a better programmer (I won’t go as far to say a good programmer). But a bad programmer who understands and practices TDD, commits code regularly to a code base which has automated continuous integration can produce reliable code. Where as a bad programmer left on there own without writing tests first can end up in a spaghetti junction of bad code with no way of verifying the quality of their work. Either way good or bad programmers who don’t write tests first can write code that’s buggy.
I agree that Agile development methods aren’t a panacea to bug free code, good developers play a big part. But I do honestly believe that projects benefit massively with agile techniques like:
- TDD;
- Refactoring;
- Continuous integration;
- Pair programming;
- Short development iterations;
- Daily stand up meetings.
They increase:
- Code quality;
- Understanding of requirements;
- Understanding of a code base throughout a team, which for one helps reduce risk when team members move on;
- Communication both internally and externally.
- …
