Summary
In software the race goes to those who go well, not those who go fast.
Advertisement
Have you ever been to a tractor pull? Imagine a huge arena filled with mud and churned up soil. Huge tractors tie themselves up to devices of torture and try to pull them accross the arena. The devices get harder to pull the farther they go. They are inclined planes with wheels on the rear and a wide shoe at the front that sits squarely on the ground. There is a huge weight at the rear that is attached to a mechnism that drags the weight up the inclined plane and over the shoe as the wheels turn. This steadily increases the weight over the shoe until the friction overcomes the ability of the tractor.
Writing software is like a tractor pull. You start out fast without a lot of friction. Productivity is high, and you get a lot done. But the more you write the harder it gets to write more. The weight is being dragged up over the shoe. The more you write the more the mess builds. Productivity slows. Overtime increases. Teams grow larger. More and more code is piled up over the shoe, and the development team grinds to a halt unable to pull the huge mass of code any farther through the mud.
Our industry is addicted to speed; and it's killing us. As we leap out of the starting gate on a new project, if we focus on speed over quality, we sew the cause of our eventual defeat. As an industry, as a profession, we need to seriously re-think the way we do software. In software, speed kills.
The way to go fast, is to go well. Going well means taking time to keep the code clean, to write tests, to refactor, to take care of the code. Going well means taking a deliberate and caring attitude for the code, and the system. Going well means working as a team, communicating frequently, reviewing and inspecting code and designs. Going well means never checking in code that fails unit tests or acceptance tests. Going well means integrating frequently, at least once per day. Going well means staying rested.
There is always time to write tests. There is always time to refactor and keep the code clean. There is always time to review and inspect and pair. There is always time to integrate frequently. Indeed, there is no time not to do these things, because these are the things that keep us going fast. These are the things that keep the weight back over the wheels rather than over the shoe. These are the things that keep our productivity high, and our code flexible and malleable.
Over the years I've published a lot about design principles, design patterns, and development practices that can help teams keep their code clean and flexible. However, these principles, patterns, and practices are only of use to the folks who take the time to use them. Interestingly enough, these are the same folks who will get done faster, and better, than those who don't take the time. Those who don't take the time just keep dragging the weight up over the shoe.
The next time you say to yourself: "I don't have time to do it right." -- stop! Rethink the issue. You don't have time not to do it right!
Where did we get the idea that our companies wanted us to write crap? Aren't they paying a lot of money for this software? Aren't they going to depend upon this software for profits? Isn't this software worth a lot? If so, then why would our company want to pay for crap that slows us down? Wouldn't they rather have good clean code that keeps us running fast?
A few years ago I hired two apprentices. I gave them a project to do. They came back a day later and said they were done and asked if I'd like to see it. I knew this project should take more than a day, so I started asking them about how they had built the project. I asked them whether they had written tests, or whether they had separated concerns. I showed them alternate designs and different coding practices that were better than the ones they had used. They were incredulous. "We feel bad because you are paying us a lot and we want to get this done fast." they said. I explained to them that the software they were writing was intrinsic to my business, and that it was more important to me that it be done well, than done fast. I explained that if they didn't do it well, then they'd be maintaining a mess for years, and that maintenance would take much more time and energy than they'd saved by doing it fast. I told them to go back and do it well. And they did.
We often blame managers for schedule pressure. We often complain that our companies set unreasonable deadlines and have unrealistic expectations. This might be true, but it's only half the problem. The other half, the most important half, is within us. We consider our worth as programmers to be more associated with speed than with quality. And that's a tragedy; because it leads us to create messes. It leads us down the slower path. By rushing we ruin our chance to truly go fast.
I was with a team the other day, and the manager of the team said to them: "I want this code to be something you'd be willing to hang on your grandmother's refrigerator. I want it to be high quality. Remember, two years from now all people will see is the mess, they won't see how fast you got it done. Nobody remembers the speed, they only remember the mess. So do it right". The programmers looked at him skeptically. Their boss just told them to go well, instead of going fast, and they didn't believe him. What does it take?
Take my advice: go well, not fast. Care about your code. Take the time to do things right. In software, slow and steady wins the race; and speed kills.
Our half of the problem certainly calls for 100% of our attention; makes me remember this quote:
"Software is not limited by physics, like buildings are. It is limited by imagination, by design, by organization. In short, it is limited by properties of people, not by properties of the world. 'We have met the enemy, and he is us' " -Ralph Johnson
Lack of soft skills, like effective negotiation, the inability to say no, also adds up to that half.
This other quote comes to mind:
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." -C.A.R. Hoare
Of course they didn't believe him. When you've spent a career doing projects with arbitrary deadlines set by quarterly revenue-driven, technically ignorant executives, what you believe is that this manager, like all the others, will turn into a crazed schedule-monster as the required release date draws near, driven insane by the heat applied to him from above.
I wouldn't necessarily believe the manager either.
I believe I lost my last job largely because I took the time to code "correctly". My boss said that's what he wanted, in fact he even kept pointing out little things that were wrong or "not designed as well as they could be" in my code.
Thing is, we had a fixed deadline, and were doing contract work. And I didn't realize that the two times when he quietly said "We need to get this done"...in a tone not belying any urgency, what he really meant was "forget about this good design stuff, we just need it to work now, so do it fast and crappy". When I finished the section of the project I was on, I came in to work the next day to be told I was being let go.
In retrospect, if I did it over again, I would have ignored his "code nicely" advice and just done it as quickly as possible. Especially since we weren't maintaining the code anyways, "clean code" truely wasn't as big of a priority as speed.
+1 for not believing the manager. While no development manager in their right mind is going to openly advocate bad practice, in most companies if a good quality project ships late then the managers will still get it in the neck whereas if poor quality project ships on time then the managers say "we did our best - obviously the dev team seem to be of a poor standard". That's why I'm a strong advocate of taking the time to do it right - a.) I can think of few activities more depressing than churning out bad code to meet some ridiculous deadline, and b.) ultimately, in the process of covering up someone else's mistakes (with deadlines, etc.) you're just lining yourself up for a kicking when everyone eventually realises the codebase is crap.
I think one reason it's hard for people to believe that going well will be ultimately faster is because it's a long term notion. It's an investment. I'm not penalized in the early stages of my project for not building extreme quality infrastructure, so doesn't it slow me down for no reason?
In addition to internal myopia, don't we have a highly competitive marketplace where everyone else is going stupidly fast? So what if I'm better, the foolish fast guys will beat me to the punch, right? What about Macs losing to IBM clones, even though they were supposed to be better? What about Beta losing to VHS? What about all the other "betters" that lost to the "fasters"?
As with all things, it's a balance. I think it's important to differentiate between the process and the output. The aim in agile development seems to be high quality process in order to turn out "good enough" functionality quickly. The good news is we have cheap, powerful tools in the world of programming that give us options to build in high quality automated processes. The problem Uncle Bob is railing against is how often we foolishly screw ourselves by not taking advantage of them.
Agile methodologies are about marrying "good enough" functionality with extreme automated infrastructure to keep the quality of the "good enough" feature set high.
I've simply forwarded this article to all my colleagues, new and old ones. Quality-driven code leads to velocity: I am not surprised when managers do not understand these simple concepts, I am upset when even developers don't!
The early bird get the worm. A stitch in time saves nine. An ounce of prevention is worth a pound of cure. A cliche in the hand is worth two in the bush.
Rushing out bad code is a good lesson in humility for those who consider themselves hotshots. That is, you may be a hotshot when given tons of time to work and hone the code, but how good are you with limited time to do a ton of work?
Seems like XP is about trying to squeeze as much productivity out of mediocre programmers as is possible. Sometimes, especially when there is a good opportunity afforded by an economic downturn, what you should really do is fire the them and hire some real hotshots.
> Rushing out bad code is a good lesson in humility for > those who consider themselves hotshots. That is, you may > be a hotshot when given tons of time to work and hone the > code, but how good are you with limited time to do a ton > of work?
I knew a guy in school who could vomit more than any person you ever saw in your life. He'd eat and drink and eat and drink and then whooooooooosh! Impressive, until you stop laughing and realize how pointless it is.
Rushing out bad code faster than anyone else is actually worse than being a top-dog vomiter. Vomit goes away. People mature and it isn't funny anymore. Bad code, on the other hand, is something that teams have to wade in for a long time. The amount of money that companies waste fighting with bad code in the industry is staggering.
I like smart programmers, but when I see some smart guy pounding out bad code fast, just because he can, it tells me more about his maturity than his smarts.
I have never found a manager after 20 years of programing who accepted the line "we can't afford not to". Managers dont care, they have bonuses to protect, they have pretty UML diagrams to show other managers, they have me to blame.
In a week or so we will ship a new product that was coded in seven weeks, has been designed on the fly and still has to be fully tested.
Management calls it XP or Agile Programming, we call it "a steaming pile of shit".
When managers start to get it in the neck for the projects they should have been managing instead of the programmers then perhaps quality will be more than a buzzword.
Peter Hickman writes: > I have never found a manager after 20 years of programing > who accepted the line "we can't afford not to".
I finally became such a manager, but only after repeatedly taking senior management at their word when they said "No, this is a matter of survival: we must ship on time and are willing to deal later with the problems we create now."
Earlier in my career I was too junior to do much about the imposed deadline; I lacked authority. As I gained experience and real authority my belief grew that firm deadlines often caused more trouble than they were worth.
I've lost track of the number of times I was told how critical a deadline was, only to find when we missed it that it moved, then moved again, then was missed by hardware engineering, then by manufacturing, then finally to be told that the customer had decided not to install for another month because of internal issues (or similar stories). In most cases, the problems we created by aggressively targetting the initial "critical and unmovable" deadline, unrealistic as it was, were with us forever; the weight had shifted way over the shoe and the tractor was stuck in the mud.
Finally things started to come together. I had the authority to make some real decisions. I observed the pattern of "firm" deadlines which shifted repeatedly. I came to realize that senior management in many cases worked on a basis of wishful thinking, self-deception, and fear. They meant well - they just weren't making courageous decisions, leadership decisions.
The last thing to fall into place was agile development, specifically XP and, even more specifically, courage as a key principle. I started using my own judgment and taking risks when senior management insisted on a particular deadline. I concluded, based on other information, that the deadline would never be met by the company as a whole. I told my own team, in effect, "go well, instead of going fast (because we won't be the last)", and they did believe me, because as an agile team we had trust in one another and understood how fast we could safely go.
To Peter, however, I say that I also have never seen another manager who accepted that line. Not really. They said they did, and I believe they believed in it, but when it came time to act they did not act differently than the typical manager who buckles to pressure from above and punishes quality when it impacts speed. Why? I think they just lacked courage.
I agree with the overall theme being discussed here, but too many posters (and the original author) are falling into the absolutism trap.
Proposition number one here is that all managers in software are bad. This is the primary undercurrent of the comments (but not the original blog entry). A minority are willing to admit that there are some good managers, but by definition a manager can't be good if he's willing to ship a product known to be shoddy.
Proposition number two is that all software must always ship at the highest possible qualitiy, and by extension shipping quality software should be your number one priority.
Proposition number three is that you should take as long as required to create quality software. Presumably this should really be "take as long as necessary to ensure quality, but no longer" - but that stronger and more definitive message is somewhat lost in the zeal for quality.
Now, as I said in the beginning of this comment, I agree with the overall gist - people are writing shoddy stuff for bad reasons, and the need for speed is killing many projects. But at the same time, both the blogger and the commenters seem to be falling into the classic trap of being repulsed by one practice, and then swinging 180 degrees in the opposite direction to most fully oppose it - and in doing so, end up in just as bad a situation as they were before.
Software quality is not the #1 issue of a team, as is stipulated here. Doing what the users require, _within the budget indicated_, is the #1 issue of a team. Most of the time this includes shipping quality code, but that's not always the case.
Inherent to this argument is psychology: the impliction that the programmers are really important, as are their works, and as such they should be treated that way. In other words, ego - this thing is so important I won't ship it until it's 100% solid! Get over yourselves. Not all software is that almighty important, and rarely are the developers involved that central to the business.
Software development, particularly in a business IT environment, is a series of compromises. It's _always_ about compromises, because we do not have infinite budgets, or staffs, the team isn't always made up of overenergetic geniuses, because we do not have infinite time to develop code.
Yes, there are bad managers - but this is not universal. Sometimes a developer sees "bad manager", when in reality what he's seeing is a good manager dealing with a difficult situation and making tough compromises. Part of the real message here is that your problems are not necessarily very important to the company, and quality of your own personal code base may not be as vitally critical as you believe. I know a number of developers who become incensed when managers and the users say "We can live with it as is". Wake up people - they paid for it, they're the ones often bringing in revenue, it's _their call_. You may think you're a critical link in the corporate infrastructure, and that your code is what's propping everything up - but most often, neither is true. Many times - not all, but many - people outside of your group know better. Many times those people are _much smarter than you_. Again, get over yourselves. It's pooh-poohed here, but many times there actually is a real deadline and the software is "good enough". Sometimes releasing a mediocre product today can generate millions of dollars in revenue - revenue that will keep _you_ employed. And not releasing it today can often lead to little more than a pink slip.
I believe in software quality, and that too many people release shoddy things for no good reason. But it doesn't pay to focus only on that. Just because there's shoddy code doesn't mean you should go on a jihad and focus on quality above all else. _Always_ remember first principles. The first principles here are not quality, it's keeping the users happy and the business humming. And doing that isn't black or white - it's always a series of compromises that has no room for absolutism.
Don't let your ego get in the way of doing your job. Do not assume that because you're a Mighty Software Developer that you're better and smarter than the business people. Don't assume that your manager is an idiot because you disagree with some of his decisions.
The biggest fallacy here is when Martin says:
"We often blame managers for schedule pressure. We often complain that our companies set unreasonable deadlines and have unrealistic expectations. This might be true, but it's only half the problem. The other half, the most important half, is within us. <i>We</i> consider our worth as programmers to be more associated with speed than with quality. And that's a tragedy; because it leads us to create messes. It leads us down the slower path. By rushing we ruin our chance to truly go fast."
Martin here is ASSuming that software developers know better than their managers and the business people what is needed, what the schedule should be, and what the priorities are. Embedded in their is a call to arms - if the developers think something is being done wrong, such as developing too fast, they should proactively change that. Horse hockey! The developers and managers and end users should work together towards some goal, and of course developers should disagree if something is being done wrong, but at some point someone has to make a decision and hit the "Go" button. And guess what folks - your business people and managers may disagree with you. "This is what we want; we understand your concerns, but we can live with them". When you get to this point, realize that you are not super-geniuses with a license to re-write business rules. Do not blithely assume your users and managers are idiots and that you're going to "fix" things.
Maybe in many cases teams are coding too fast. If so, the users and managers and deveopers should get together and hash it out. The absolute _worst_ thing to do is have the software developers unilaterally start trying to change the rules and saying "We know better than those idiots; we'll do it our way".
We don't live in a Utopia. Face it, developers, sometimes a given situation means somebody somewhere might have to do some shit work that nobody likes, and that somebody may be _you_. That's life, and that's business.
Here's a central message that software developer's should live by: the universe does not revolve around you. The world does not exist to help you make better software more easily. Most of the time, horror of horrors, you are paid to do a job.
By keeping the "internal code quality" high -- which means no unnecessary code, writing code that does what it is supposed to do *and no more* -- teams can go faster, and meet the demands of "external quaility" -- the requirements of the customers.
Teams that try to attain speed by avoiding good practices pay the price in having to fix bugs that their would otherwise not allow them to ship the product. Fixing bugs takes longer than using good practices to avoid bugs.
Lately, I've heard of five companies where the programmers spend 75% of their time fixing bugs found by their testers and their customers, and only 25% of their time writing new code (which, because of lack of good practices, is full of bugs).
How much time does your company spend fixing bugs it could have avoided?
I understand that many programmers have experience with schedule-driven managers. I've worked for 3 different companies on agile teams where the managers emphasized quality over speed. So these managers do exist. What DOES it take to motivate programmers to use good practices?
Flat View: This topic has 30 replies
on 3 pages
[
123
|
»
]
Previous Topic
