Speed vs Quality

It seems that there were some issues with voting machines in the US recently. Paul Johnson proposed a reason why.

Too often projects are run predominantly with a short-term business focus. Lip service is paid to quality, but when things get tight, it is not actually that important. However, all that changes once the project is 'finished'. Suddenly the longer-term becomes more important, but by then it is too late.

In a software project, there is generally a relationship between quality ¹ (from the developer perspective) and speed of development (from the business perspective). You can sacrifice quality for speed, but as the project becomes bigger or more complex, it becomes harder to change and so development speed decreases. The short-term gain (probably measured in days/weeks) becomes a long-term loss.

At the other end of the spectrum, you can spend most of your time focussed on quality and not worry about speed of development. As previously posted, this is not commercially sustainable either.

IMHO, one of the most interesting things Agile Methodologies bring to a project, is the opportunity to make development cost/speed and quality more transparent throughout the life of the project. In the end though, someone has to make decisions about quality and speed on a day-to-day basis. It seems to me that a business savvy developer will be more likely to succeed than a tech savvy business person. It is a tough line to walk though.

¹ Quality means different things to different people. In this case I am referring to both how well code is written and whether it exhibits correct behaviour.