Why Software Development Methodology Adoption Fails

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).

Here goes.

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”

How to make Machinist and Autotest coexist

If you’ve tried to use Machinist and autotest (part of ZenTest) you have probably seen this exception that prevented you from using it:

It’s discussed in the machinist Google Group as well.

It’s because of a wacky hack that’s part of Machinist that overrides Module.name so you can do Sham.name, but ZenTest expects Module.name to do what it does normally.

I have a fix for this.
Continue reading “How to make Machinist and Autotest coexist”

Extreme Programming Experiences: Conclusion

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”

Extreme Programming Experiences: Part 5 of 5 – Pair Programming is for 100% of production code, not 100% of your workday

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”

Extreme Programming Experiences: Part 4 of 5: Technical Debt and Cruft

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”