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”
This is a follow up to On Our Project, We’re Always 90% Done.
The coder is the one on the hook for long nights, weekends, and stress-related health problems if the estimates suck. It’s in your interest to exert as much control over estimation and scheduling as you can. If you’re not making the estimate, someone is making it for you.
Continue reading “Software Project Estimation: Inaccurate and Unavoidable”
I’ve written before about tips for offshoring. One specific thing I said to watch for is the bait-and-switch of talent: during the sales process you’re shown rockstars, but the real code you get is written by clueless newbies. When you set up a project such that you’ve minimized the cost per hour of development, but you don’t have anyone checking the work product (i.e. code reviews) coming from the subcontractor, very bad things happen.
Continue reading “Bad, Bad Code”
Most of his rules are applicable to generic software consulting.
Josh’s Rules (of Database Contracting)
Starting with Netscape 4.5, I’ve used Netscape, then Mozilla, then Thunderbird for email. I have a similar relationship with Firefox. I’ve watched with great hope and been disappointed over the years as Thunderbird bugs that really annoy me just… stay. I think I know why. It’s because Firefox and Thunderbird are built in such a way as to create a catch-22 situation — one that actually discourages new contributors.
Continue reading “The Mozilla Platform’s Catch-22 Problem”