Organizations often try to adopt a software development methodology, in hopes of reducing the risk of cost and schedule overruns in their software development project. Veterans of previous methodology adoption attempts roll their eyes or actively resist, while less experienced team members drool in anticipation of some order and predictability. In this post I describe how software development methodology adoption efforts can fail, based on my own experiences.
This is a personal perspective, so it doesn’t go back all the way to the early days of computer science. It starts when I started paying attention, which was in the 1990s. Nevertheless, I think it’s pretty accurate with respect to what was going on in the 1990s through today (late 2015).
Once upon a time, in the final years of the 20th century, there were some experienced software folks who had been through some successful projects and some failed projects, who had developed a sense for what to do and what not to do in certain situations.
Continue reading “Why Software Development Methodology Adoption Fails”
Now that I’ve worked in a team that really was doing XP (except for our Lack Of Onsite Customer shortcoming) I can say that it works pretty well, but only to the extent that you do all of the practices together. Of course, that’s what the XP folks said from the beginning: you can’t just apply 1% of it and make a judgement about it.
Continue reading “Extreme Programming Experiences: Conclusion”
Pair Programming is for 100% of production code, not 100% of your workday
Pair Programming is intense, mentally and physically. You need to take breaks, stretch, walk around, and hopefully go outside for sunshine and fresh air. Even so, 8 hours of solid pair programming is a very tiring day. That much pairing time may be appropriate now and then, but it isn’t physically sustainable.
Continue reading “Extreme Programming Experiences: Part 5 of 5 – Pair Programming is for 100% of production code, not 100% of your workday”
Technical Debt and Cruft
There is a fundamental tension in software development between delivering something quickly now, and being able to deliver something quickly later. Over time, quick and dirty hacks pile up, and code becomes difficult to work with.
Continue reading “Extreme Programming Experiences: Part 4 of 5: Technical Debt and Cruft”
Lack of Onsite Customer
This is a serious problem. Your project exists to serve somebody, and your success is directly proportional to understanding what they want, so that you can build it. You need as much communication bandwidth between the programmers and those people as possible.
Continue reading “Extreme Programming Experiences: Part 3 of 5: Lack of Onsite Customer”