The Seven Deadly Sins of Software Application Development – Part 2 of 2

by Lorne Cooper, CEO, AccuRev 

 

A Top 25 WordPress Blog Post of the Day

 

In Part 1, we looked at the sins of Building a Weak Team and Ignoring the Future.  Once you’re committed to hiring talent and building a forward-looking process, there are two more sins to avoid.

 

Sin #6: A Long Tail After Development is Complete

 

We constantly see organizations where the time from “requirements-in” to “feature freeze” is half the time to “solutions-out.”  That 50% “tail” on development provides no direct value to customers, but is there because of limitations in our development process.

 

Sometimes that tail is twice the length of the initial development. 

 

Ironically, while the long heavy tail is grown to protect the organization from delivering bad product, it eventually decreases response time until it becomes an instrument in the organization’s death.

 

But many industries have a long tail, don’t they?  Surely it doesn’t hurt the construction of bridges that the plans are completed long before the bridge is built.

 

For forty years people have tried to make analogies between software development and more mature engineering disciplines, say, like building buggy whips.  The designer of the buggy whip might make a sample or two to try it out on his children, then send it off to the factory, where a slew of Industrial Buggy Whip Engineers would spend months figuring out how to sew the damn things, buying up horse-hair, and hiring immigrants to sit at sewing machines. A year or so late, Pony Express delivers the new buggy whip to general stores all over the Grand Trunk Railway line. 

 

We can all certainly learn a lot from that.

 

Now try telling your customer that the problem she’s been working around is well understood, and in fact fixed, but she’s not going to get it for three months.  She’ll be looking for alternative suppliers before the screen door has hit your butt. 

 

Everything moves too fast to use that tired old process.  Frankly, I use to blame computers.  Now I blame the Internet. 

 

When you take a hard look at the time it takes to get completed product out the door, you’ll probably find it dominated by two things: testing, and fixing bugs that the testers find.  Both stem from the problem that you’re not doing enough testing during the development process, and you’re trying to test too much at one time.

 

I’m no fan of Hawthorn-effects, or what the politically incorrect might call gimmicks, like pair programming or stand-up meetings, but projects that use an Agile development with automated regression test processes are certainly doing more right than wrong. 

 

Is it really so hard to manage by tasks/issues, normalize them to a small unit of work, merge in just one set of changes into each build, and test just that perturbation?  What if you knew you would consistently get better code out the back of the process, and therefore make your organization more responsive to your customers?

 

Your development process must minimize latency, instead of trying to maximize bandwidth.  Don’t miss the changes in requirements and environments that produce opportunities for better products, or sooner or later you’ll end up locked in a suicide pact with a project no one wants.

 

Sin #7: Complacency

 

Calais’s stone walls were so thick the city had no fear of invaders, until they showed up with cannons.  Napoleon’s Old Guard was undefeated in battle after battle, until they were cut down by Wellington at Waterloo.  Big Blue’s OS/2 would crush little Microsoft’s Windows product.  Big Microsoft’s Live Search would crush little Google’s search engine. 

 

Hubris on ice will leave you with a heck of a hangover.

 

That brilliant team using that wonderful process you put together last year, is just a few months of complacency away from dysfunction.  People move and, thanks to the 13^th Amendment to the US Constitution, may leave their jobs and there’s little you can do about it.  Environments change and architectures become outdated.  The marketplace changes and requirements change with them.

 

One VP Engineering I know told me he asked his off-shore application development partner to give him 110%.  They did, but it turned out to be turnover.

 

Your process needs to be constantly monitored and upgraded, because everything in the process is changing.  If your offshore partner has high turnover, their part of the process might require more code inspection and knowledge transfer.  If your biggest customer can’t use your product until it supports their new environment, you need to put a special team on building a custom version of the product, and then merge that back into main development.  If you have to replace an old veteran with a rookie, then you might create new integration points and a more rigorous test protocol.

 

Recognize that everything will change, and the assumptions under which you built your last success are no longer valid.  Make small process changes early and often, or in the long run the big changes will be made by your replacement.

 

Stirring Conclusion

 

Managing a software development organization is a very challenging task, as tough as playing a violin with your toes, and less fun. 

 

I don’t mean to trivialize important management functions such as customer management, budget and project tracking, running a good meeting, and designing effective compensation structures. And by all means, hiring someone to spend their time doing all of that.

 

But that won’t protect you from the seven deadly sins.  Only you can do that.

 

I’ll finish with the Four Virtues, which are the antidote to the Seven Sins:

1. Hire great people or don’t hire.
2. Plan to build a product that will have a long life.
3. Keep your process nimble, and deliver less, faster.
4. Keep improving everything.

Always Act Like This is The Release

by Damon Poole

I think of this practice as a major guiding principle of software development. If every practice is done as though it is part of the final act of releasing the product, then you will automatically have fewer practices. Fewer practices means less chance of problems falling through the cracks until the last minute and a higher level of maturity for things that have been done multiple times.

For instance, instead of having one process for developers to build during development and another build process for release, use exactly the same one. That way, when it comes time to release, the path is well worn and the chances are better that you will be able to completely reproduce the release if and when the time comes.