Speed Kills

Derick Bailey about 1 hour later:

• • “When you feel the temptation to rush, resist it. Leave the keyboard and walk around. Distract yourslef with something else. Do not give in to the call of your addiction.”

  • I did exactly that a week or so ago. I found myself in an unmotivated, lethargic state. my initial reaction was to try and find that rush to get me motivated again. i realized, though, that my desire to find that rush would only cause problems in the software – i would have taken the easy way out of a complex problem and causes additional problems in the system.

  • instead, i shut my computer down and went home. it was one of three choices: 1) rush and feel the rush, resulting in junk for work; 2) do it right knowing that i probably wouldn’t because i had no motivation, resulting in less than stellar work; 3) do it later when i had the motivation.

  • in the end, i know shutting it down was the right choice. the problem turned out to be significantly more complex than i originally thought and my cheap way out would have just caused other problems.

David Paxson about 1 hour later:

• • While it is true going too fast is unhealthy, so can going too slow be unhealthy.

  • I worked at a small company with a group of programmers who had the attitude of “the software will be ready when it is ready.” However, the funds for the company were drying up and they had to sell software to stay in business. With the programmers having this attitude, nothing was getting delivered in time for keeping existing customers happy or for getting new customers.

  • The company is now a memory.

  • Speed kills. But so does the attitude that we can take all of the time in the world.

Mark Nijhof about 2 hours later:

• • The Hero effect, the guy that got the job done by working the whole weekend. Everybody cheers! So now we got something that was created by a single guy in the middle of the night in an rush, most likely resulting in crappy code. No more heroes.

  • Now having said that, you can work throughout the night and produce quality work, it’s all in the mind.

  • -Mark

James Grenning about 2 hours later:

• • It’s good advice Bob. That rush is exciting. When we think the rush is needed, maybe what is really needed is urgency. Urgency can help keep us on track, and make sure that we work toward to goal without a lot of wasted efforts and an attitude of I’ll be done when I’m done. The professional works without wasted effort in a deliberate and repeatable way.

Craig Berntson about 4 hours later:

• • We’ve all scene the paramedics rushing through traffic, lights flashing, sirens blazing, but what happens when they get to their destination? They calmly take their gear out and walk into the building. They don’t run because when you rush that way, bad things happen. Great post!

Eliot Sykes about 4 hours later:

• • Brilliant. Thank you Bob.

  • Speed kills and it’d be great if there was a faster way than personal experience to teach programmers to take this approach to their craft.

  • Any tips for helping team mates adopt this approach?

Ralf Westphal about 18 hours later:

• • Does the group of students on Friday afternoon just succumb to the drug of speed? I don´t think so. There is another drug: the drug of accomplishment, of closure. People want to take home “little boxes” with whatever they did. People to leave tasks unaccomplished. They hate to “live in tentativeness”, in the interim. This is also the reason why agility is hard to adopt for some people: because agility means to not finish (yet). Agility is ever open to change. And that´s what contradicts many people´s striving.

  • -Ralf

Chris Johnston about 19 hours later:

• • So how do you convince management of this?

  • I have been on projects were the developers wanted to go slow and steady while management was slowly stripping away things like unit tests and pair programming because they say their bonuses and their jobs disappearing. Trying to convince them that writing good code a story at a time would allow their application to be released on time was next to impossible.

Kyle Szklenski 1 day later:

• • Hey Uncle Bob,

  • You inspired me to write about this. There’s a post at my blog. I’ll write more here tonight, and more tomorrow at my blog.

Kyle Szklenski 2 days later:

• • Okay, there’s not any more coming tonight on my blog. However, I will say this tonight: I think most truly good programmers are more efficient than others. It’s not the speed at which you work – it’s the effectiveness with which you work. JP Boodhoo or Oren Eini, these guys are SUPER effective at coding. They do make mistakes of course, everyone does. But when coding, they’re always thinking about their code and how it’s working together and where points of friction are and so forth. They don’t try to hack something out as fast as possible, but instead they write their tests and try to come up with every possible way to break their system in order to be fully covered by the tests, as well as design their interfaces accordingly to produce the least friction.

  • I can’t say I actually asked either of them about this – I just noticed it in their various podcasts/vodcasts/whathaveyoucasts. For example, people call Oren Eini (Ayende) a robot. That’s simply not true. He is so effective and efficient at writing code that it seems like he’s going way faster and ALWAYS knows what to do. Instead, he’s just thinking about the programming while doing it, I suspect, as well as writing the tests which help him decide how he really ought to be doing it.

  • In conclusion, it is my assertion that effectiveness and efficiency are far more important than speed of delivery, even if it means being late on a deadline.

thought-tracker.blogspot.com 3 days later:

• • I’ve remembered your post from 2007: Going Fast

  • IMO, a lot of people miss the point that they should build abstractions. Some people just hack down gazilions of code-lines per day, and go home with a feeling of super-hero-productivity.

  • We need less coders, and more anti-coders.

Marty Fried 4 days later:

• • I’ve learned from experience that what you say is correct, assuming you find the right balance; but I’ve also found that it’s a lonely avenue in most companies (at least the smaller ones).

  • I worked at one small company where the main programmer could get a buggy version running very quickly, and looked like a hero. Then, I would spend most of my time fixing his bugs, and looking like I couldn’t finish anything myself. Management never knew the score, and the other programmer was unable to change.

  • My last job was similar. I took longer to get projects promoted out of integration to QA, but once they were out, they didn’t come back nearly as often, so that in the long-term, I believe I was as fast as some of the others, and my code didn’t have many bugs once released. Plus, of course, I was having to work around or fix bugs from other people. But I still had a reputation for being too slow, and in fact, I’m now out of a job.

  • So, unless you are a very good advocate for yourself, and keep good records of your production vs your coworkers, you will have a hard time practicing many of these principles in a lot of jobs. Management has the attitude “write high quality code with no bugs, but get it done tomorrow.”

Dylan Smith 6 days later:

• • I’ve recently been involved in a project where they have been rushing features to market for a long time now and as a result the code-base has extremely poor internal quality. The questions I’m trying to tackle now is how to justify the investment needed to drive up the quality of the code-base. My gut tells me we need to take a little more drastic action than what Ron proposes in his post (I may be wrong). My challenge has been trying to justify that investment. What costs are there to the low level of quality we currently have that would go away or be reduced by focusing on improving the quality level? Or stated another way, what benefits would we realize by investing in the quality of the application in a significant way?

  • I tried to organize some of my thoughts on this over here:http://geekswithblogs.net/Optikal/archive/2009/02/09/129299.aspx

Arjen 10 days later:

• • Well I do understand your point of view, and a good pace might be sign of craftmanship…. on the other hand i find a lot of colleagues lately trying to get the specs and design right 100% taking all the time. In the name of quality… While i more and more find myself leaning into the movement of build a prototype and have it evolve, which is the fast way to build something… Behavior driven development style for quality control…

  • While this might not match your idea of fast vs slow, most of the people of ‘the other group’ did told me that i was going to fast , which made me link it to this blog… i think that just stating that fast development is not inline with quality is a bit of going short

Dave Schinkel 10 days later:

• • Try telling that to CEOs who don’t get that quality will produce far better ROI than a hack job.

Anonymous about 1 month later:

• • I too am sick and tired of Managers who promote Code & Run environments then blame it on the lame “business needs it now, or head honcho says he wants it” when the head honcho is WRONG to force this kind of environment and atmosphere within the people they hire to create working and reliable solutions. That is one of the most stupid things you can do to a development team and the product they create for you. That’s why good developers LEAVE and that’s what has made our industry a pile of shit to work in. That’s why the business FAILS. That’s why everything is CHAOS in your department. I’ve seen this over and over.

  • Good development teams know that iterations are key and sticking to the plan is key. And sticking to priorities is key. If a stakeholder wants to interrupt the plans, then you can’t expect now x AND y to be done at the same time…that’s just CHAOS. Sorry, but you have to say NO sometimes to the business and reorganize the deadlines have to be adjusted and YES that means some things are pushed out. That’s common sense.

  • Pride should be having a sane department, sane and prioritized goals, sane deadlines and development standards which means you do not rush to put out a hack or purchase a 3rd party system because now you are still running and you can’t say no to slow the business down a bit and now you’re buying all 3rd party to get things done at light speed. That shit will fail faster than you can believe and you’ll be paying costs all over the place as well as adopt a shitty API most likely that you cannot extend. That’s the result of RUSH.

  • You are saying you’d rather pay for bugs at a higher cost later than test now and add in time to test with a realistic good deadline, and code a decent quality code base that can maintained, extended easily, and which works well for your customers. That’s what gives back to the business, not a hack job and not a burned out IT development team who humanly cannot meet 5 deadlines at the same time due the the fact that when every day or week you introduce a new project add a shit ass deadline that interrupts what they were currently working on but you still expect both to be done? Common. Wake up.

Terry about 1 month later:

• • I as a developer never wanted or felt the need to rush…I don’t enjoy fixing or maintaining that kind of code later and I will certainly not work until 2 am based on lack of structure and practices. So I do not agree that all good developers want to rush… In fact they slow to build solid code and that is how you support your organization effectively.

Fireplace design 3 months later:

• • Same here Terry. I’m not a developer myself but when I’ve outsourced such work I’ve always emphasized that the developer spends a it more time to build solid code, even if it costs me more.

Scott Smith 6 months later:

• • Great discussion. My additional 2 cents: 1) I find much more accomplishment in the numerous completions in getting each unit test to work. 2) Until management expects unit test coverage and velocity tracking as part of the software delivery process, then that team effectively has no software processes in place. Consequently, that team is at a continually-increasing risk of delivery failure/increasing bugs over time.

Kid friendly 9 months later:

• • I too am sick and tired of Managers who promote Code & Run environments then blame it on the lame “business needs it now, or head honcho says he wants it” when the head honcho is WRONG to force this kind of environment and atmosphere within the people they hire to create working and reliable solutions.

matt 9 months later:

• • Totally agree with the post. If you want it done the right way then you need to set a side enough time between then and the deadline. Companies who promote this type of work atmosphere are not getting the quality work they hired their employees to do.

Free Advertising 11 months later:

• • Developers don’t realize the long term consequence for trading speed to quality because bad quality code can make you suffer in the longer term development process and cause development to take slower and slower reducing the speed.

Peter Kofler 11 months later:

• • [...] One of my favourite quotes for crappy but fast developed code is Uncle Bob’s “rushingtogetawholebunchofshitcodedandsortofrunning”. Wearingthis shirt you don’t even have to say it out loud . On its back there is a highway sign, so you can rush right away ;-) [...]

exterior french doors 12 months later:

• • I agree matt..If you want it done the right way then you need to set a side enough time between then and the deadline! I do not agree that all good developers want to rush, rushing reduces quality in almost every case.