Many software engineers, especially young software engineers, are over-impressed with speed. They measure their software competence by measuring how fast they can complete a given task. They view software production as some kind of race which requires a never ending sprint to win.
I'm not going to deny that speed is important; it is. However, it's not as important as it might appear. The best programmer is not the one who gets the job done fastest. Often the inverse is true.
Some of my junior programmers recently showed me some working code. I was happy that they had got it working, however was not as happy with its structure. I asked them if they had refactored it; and if they thought that it was as clean as they could make it. They replied that it would take as long to clean it up as it did to write it. I responded that that might not be enough time, and that they might want to slow down a bit.
This puzzled them. They felt that slowing down to clean up the code was a waste of time. So I had to explain to them that the software they were writing was extremely valuable to me. Once installed on our website it will make it easier for our customers to access our services. While I want our customer to have that access as soon as possible; I also want such a critical piece of software to be as clean as possible.
That software is going to help Object Mentor make money - and *much* more money than we spent paying the engineers to build it. I don't want to base a critical revenue generator on a rickety piece of code. I want to make sure that code is as clean and structurally sound as possible. And I don't mind them spending the time it takes to achieve this.
This is an example of the topic of this paper. I think speed is seldom the issue. Nor is speed equivalent to time-to-market (TTM). There can be no doubt that TTM is critical. And certainly it requires a good speed to make TTM. However, getting to the market with quality is still better than getting to the market with quantity. If we invest our development time in the quantity of features we deliver and ignore the structure and cleanliness of the code; we'll almost certainly get to market later than desired, and with a dog of a product. On the other hand, if we throttle back the number of features and put effort into keeping the code as well structured and clean as possible, we'll get to market with quality, and be able to build upon that quality quickly.
The market is not stupid. IMHO buyers are reluctant to jump on first releases. They want to see the *pattern* of releases before they make a decision. If the buyers detect that the release schedule is unstable, or that there are too many bug-fix releases, then they may decide that the product it not stable enough to invest in. On the other hand if they see a sequence of releases occurring on a regular schedule, and each increasing the functionality of the product by a reasonable amount; then they will get warm and fuzzies about the product.
So. It's not just about speed. Being the fastest programmer does not mean you are the best programmer. Spending the time to clean up your code and invest in sound architecture is just as important as implementing the right functionality; and perhaps even more important.
Unfortunately development teams get caught in a web of expectations that are hard to change. By setting a price and date on delivered functionality, customer cut themselves off from high quality. Such development plans measure everything but quality. They measure date, cost, and functionality - and therefore, that's what they will get. And they will get these things at the expense of the only quantity that's not measured, the quality of the code.
What we need is a way to measure the quality of our software, and a way to incorporate those measurements into our plans. However, measuring the structure of code and its cleanliness is problematic. I did some work on this several years ago and came up with some design quality metrics that might help (see 'Object Oriented Design Quality Metrics' in the 'publications' section of www.objectmentor.com 
) but these are very crude and I would not want to see them used in any kind of formal contract.
That leaves us with having to ensure that quality is present in our software without being able to formally measure it. Without the formal measurement, it is difficult to justify the time required to ensure the quality is there. Yet we must take the time anyway.
That is one reason I like the XP style of project management. In XP one does not plan a project in terms of functionality and data. Rather one plans it in terms of the *derivative* of functionality and date. That is, we use project velocity as our metric. Customer see steady progress being made at a certain velocity. This gives them an idea of how long it will take to implement the necessary functionality; without the need to make a commitment based on functionality and date. The velocity automatically includes the time spent by the engineers in refactoring and cleansing their code. So, at very least, the XP planning process *enables* the production of high quality code.
Comments? -- Robert Cecil Martin
What about Worse Is Better? Bug Free Doesnt Sell? Netscape was the fastest growing company in the world before MSIE3.0. Marc Andreessen had a philosophy of features over bug fixes.
And how does Release Early Release Often fit into this? -- Sunir Shah, Devils Advocate
When you produce continuous quality instead of fixing bugs later, you also always have a product (missing a few features) that is worth of a release. So the answer ist: Release Early Release Often comes just natural. -- Juergen Hermann
Well, that isn't the philosophy of Release Early Release Often. Release, bugs included is the idea. That way it can been Peer Reviewed faster. But that's an Open Source thing anyway. -- ss
I couldn't agree with you more, Robert. I share your values on this topic, and thanks for articulating them here. I used to work with a guy (a good Smalltalker, incidentally) who was obsessed with improving the speed of development. In fact he once started a company named Software Quicker. My reaction was to threaten starting a company named Software Better. I believe that Beauty Is Our Business, and I believe William Edwards Deming's assertion that high quality costs less than low quality. This obsession with speed manifests itself in many ways. One Ejb Container company became the darling of the show at the Java Business Conference last December by demonstrating how they could completely generate, deploy, and run your application in 10 minutes. Oh sure, and you would want to run your business with the output of some wizard, right? Give me a break. I'm more aligned with The Pragmatic Programmer, whose preface admonishes you to Care About Your Craft and Think About Your Work. -- Randy Stafford
I've been on a number of conventional (IE: non-XP) development projects where the developers did their best to produce code quickly, at the expense of well-formed design and structure. These projects normally deliver late, because sloppy code usually contains a large number of bugs: it's hard to see if the code is right or not. The bugs often catch up with you before you release your code: Integration goes badly, and bug reports get out of hand. Or, you can deliver on-time, and deal with lots of emergency bug fixes as customers find a long series of bugs in production. It's icky, no matter how you look at it.
Spending time to improve the quality of code usually saves time overall, if you're measuring release dates rather than source control checkin dates.
-- Jeff Grigg
One of the things that I think people overlook is that speed and TTM aren't important if they aren't sustainable. It is more important how quickly you can iterate, change, and extend the functionality over time. Good software development is not only about how to go really fast. It is about how to create a system that enables you to KEEP going fast, and not get bogged down by horrible, unmaintainable code.
Hand-in-hand with this - good management practices are important in ensuring that your team is able to be successful in project after project. All too often managers seem to view the team as an expendable resource, when in fact their talent is the only means of production that makes any difference. Which allows you to go fast time after time. -- Bill Barnett
Your armor can move very quickly when you let it. Driven to the right spot at the right time, it can have a decisive effect upon the battle.
Let the armor outrun your supply lines, and it eventually runs out of gas and stops. Worse, it loses its only defense -- movement -- and becomes a liability.
Neverthless, outrunning your supply lines is sometimes the best option you've got. Sometimes it isn't. The good generals know when it is about speed and when it isn't.
Of course, when it is about speed, it still sucks to be the one sitting in the tank with no gas.
Good point. Sometimes it is about speed. See Worse Is Better. -- Robert Di Falco, Sunir Shah
One comment about formal measurement of software quality versus no measurement at all. Are those the only choices? When I used to practice piano (software to music analogy coming, beware) no one was measuring the quality of my effort formally, but several of us could tell when I was going too fast to do good.
About speed of execution and quality in general, there are times when you can go fast and get good quality results, but it's the result of doing things slowly first, and gradually increasing speed while controlling outcomes. You can't go fast all the time and do good work. It's always a good idea to slow way down to a crawl from time to time to re-establish fundamental techniques. You discover neat stuff when you do it, too. As I'm writing this, I'm thinking about piano playing and software development, both.
Thanks for an excellent paper, wish I'd written it. -- Walden Mathews
I'm not sure, but I suspect universities are capable of shipping product that knows how to do loop statements, but nothing about SE management theory. They'l have picked this up from anecdotes about sleeping in halls. The only thing more important than time-to-market is knowing exactly where you are right now. Only that lets you frequently release & track & such. And that's why Relentless Testing pinning down every feature is so critical. -- Philip Craig Plumlee
See original on c2.com