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”
I’m working on a Rails app that uses the ym4r_gm plugin, getting Google to do the geocoding for Thentic. I liked the idea of stubbing the web service call, because all those calls to an external service add up to over 20 seconds of test suite run time(!). That’s almost half of the 50 second run time of my unit tests (and 50 seconds is much too long for a unit test suite).
I found a good starting point at geokit stubbing for faster tests. I also wanted a way to stub a geocoding failure, and a way to prevent any unit tests from using the real geocoding web service.
Here’s how I did it.
Continue reading “Fancier Stubbing of GeoKit for Rails unit tests”
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”