Agile Concept of the Week: Technical Excellence

Posted by Keith McMillan

January 14, 2013 | Leave a Comment

Continuing the theme from last week, where we discussed some of the principles behind the manifesto, this week’s concept is technical excellence. The principles say “Continuous attention to technical excellence and good design enhances agility”. Why should that be so? Can’t we just add quality in later?There are a few problems with taking your eye off the ball when it comes to design and implementation excellence. The first sad reality is if you don’t make it the best you can right now, you’re not going to get a chance to go back and do it over later. You’ve built a shaky foundation, and at some point, it’s going to collapse under the weight of subsequent development.

Building on that reality, if you’ve got a shaky technical foundation, at some point you will need to build upon it. If it’s not up to the task, because it wasn’t built as well as you could, then you’re going to take the hit to fix it when you try to build on it, and it collapses. Then, you’ll need to fix it in order to proceed. Like playing a game of Jenga, once you get past a certain point, you can’t continue because your foundation is too shaky.

Does this mean that every project must be completely flawless from a design and implementation point of view? That’s really a trick question. It’s not possible to know everything before you start to construct software systems, and even if you did, your requirements would change before too long, invalidating your perfect precognition eventually. But to be fair, in most organizations, the pendulum is, and maybe always has been, way too far in the direction of “just get it done” to be healthy.

What if you’re building a system with a short lifespan? Do we need to do everything perfectly for that system too? Isn’t that a waste of money, brains and talent? Sure, but “temporary” systems have a way of living long after they should have retired.

To summarize, there are a couple of big problems with taking your eye off the technical excellence ball: the first obvious problem is the quality of the resulting product.

A more subtle problem, but perhaps an even more serious one is that eventually your estimate for new development activities will be way off, because you’ll have to pay the cost to rework inadequate foundations in order to proceed. This can make a task that otherwise should have taken a day to stretch on for weeks.

Paying attention to technical excellence pays benefits in terms of keeping your estimates more accurate, keeping the quality of your product up, and the joy of working with well designed software, rather than a pile of spaghetti.


RSS feed | Trackback URI

Comments »

No comments yet.

Name (required)
E-mail (required - never shown publicly)
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.