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”
Git is getting a lot of press in the open source world lately, but hasn’t got much traction in the closed source corporate development world. There’s a reason for this, and it’s more than conservatism on the part of the corporate developers. Git (or any DVCS, really) embodies a development culture that isn’t very enterprise-y.
Continue reading “Thoughts about using Git for closed source projects”
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)