
Speed Kills - stefano
http://programmer.97things.oreilly.com/wiki/index.php/Speed_Kills
======
run4yourlives
Do you know what kills more than speed? Code that isn't "done". Code that
isn't done doesn't ship, not shipping means no money, which means no food,
which means death.

In the end, bad code is simply trading your time three weeks, months, or years
from now for time _right now_. It's exactly the same as taking out a loan.
Sure, it's cheaper to save and not pay the interest on the loan, but unless
you have the luxury of time (You hardly ever do) the loan makes better sense
both in the long and short term.

Every time you rewrite code, just think of paying interest. It's a lot easier
to deal with if you see it as trade of for the nice warm house you're living
in or laptop you're coding on.

~~~
DannoHung
Rewriting code is paying principal. Dealing with the shit caused by bad code
is the interest.

The longer you go without paying the principal, the more interest you're
paying.

~~~
run4yourlives
I think you just paid some principal on my comment; nice
extension/extrapolation.

------
kungfooey
I'm going to call BS on this one. As a business owner, I realize that
sometimes there's a balance between "perfect code" and "getting to market."
You can't be a pragmatic business owner and a perfectionist.

Artists can afford to be perfectionists. A software artisan may wish for
perfection, but this sort of tripe is exactly what I was referring to in this
post: <http://dailytechnology.net/posts/3>

If you want to perfect software as an art form, then great, take this advice.
But if you do it for business, then you realize that there is a trade-off when
you aim for perfection. You may write the most stable, secure software in the
world, but if nobody uses it, then who cares? You painted the Mona Lisa, and
it's in a basement somewhere. Congrats.

~~~
btilly
You're obviously not familiar with the research on software development and
productivity. I would strongly suggest that you pick up some books from Steve
McConnell (eg Rapid Development) as well as some classics like Peopleware. You
may find some of the lessons invaluable.

Researchers have studied variation in speed of development between
programmers. A common scenario are coding tests where different programmers
are asked to do the same task. These studies have consistently found
differences in speed of a factor of 10 or more. Follow-up research has found
that programmers at the fastest end of that scale spend the smallest fraction
of their time actually programming. Instead they spend time in other
activities such as design and testing. So time invested in design and testing
pays back during development. And not just in a large project, but in a sample
coding exercise of less than a day.

Here is another data point of interest. Another study assigned multiple
professional teams the same project, but asked each team to optimize a
different thing. A few of the dimensions were performance, development speed,
maintainability of code, and memory usage. Most of the teams managed to win on
the characteristic they were optimizing for. The team that was aiming for
maintainable code came in second on most of the other dimensions.

When you consider that as an industry we spend about 70% of our software
development dollars in maintenance, aiming for maintainable code has lopsided
benefits relative to the other options. Your code is done almost as fast as
possible, performs reasonably well, uses a reasonable amount of memory, and
costs a lot less to maintain. Situations exist where that isn't the optimal
trade-off, but it is optimal often enough that it should be treated as the
default.

Which is exactly what this article was arguing.

~~~
kungfooey
I'm quite familiar with the research ("Code Complete" is a book I constantly
reread) and with the arguments for good design. As another commenter pointed
out, the argument wasn't so much for "perfection" as it was for "good code"
(which I can't argue with). It's still somewhat arbitrary, thought, and the
more "good" it is the more you edge into diminishing returns. There's some
point where the trade-off for "better code" trails off.

Design, however, is a whole 'nother ball game. As you pointed out, research
has shown that most of the problems, and indeed the most expensive problems,
are caused by requirements. (IIRC)

------
puredemo
Ironically it took a ridiculously long time for this article to load.

~~~
discojesus
But you should see how clean and maintainable the code is.

------
thrill
From a previous life ... "Speed is life" ... as long as there is control.
Speed with control is better described as velocity, and is a vector - it's
getting you where you want to be, rapidly. Speed without direction (control)
is simply rapid, and possibly random, change in position - you probably won't
like the end result - kind of like jumping naked off a tall Scotland cliff -
it's great fun for about 10 seconds ...

~~~
run4yourlives
Pilot? (Flying is the only thing I can think of where going faster gives you
more options, not less)

~~~
apotheon
Going faster in the right direction is a sign you've made the right choices --
not a way to get more options for the choices you make.

------
Raphael_Amiard
I view this as a lesser version of
<http://www.joelonsoftware.com/articles/fog0000000043.html>

When you read the 5. of joels article (and some others points) you realize
exactly in what this article must be right.

But without the facts this has no sense. Sometimes you need to go faster, but
it's a tradeoff you will have to fix later.

------
DanielBMarkham
This is all motherhood and apple pie and such, but I guess it deserves
repeating from time to time. He's got that Clean Code book out, which is a
pretty good read.

What I want to know is how in the heck do you get to call yourself "Uncle
Bob"? What? Is there like an agile family, with uncles and nephews and stuff?
If so, I want to be Cousin Dan

------
RyanMcGreal
_The best is the enemy of the good._

\-- Voltaire

~~~
JoeH
and good is the enemy of at all. (I attribute that to what I heard Paul
Buchheit say once at a YC dinner)

------
slackerIII
If you want a mantra to remind yourself of this, I like "fast is slow and slow
is fast".

~~~
Tichy
"slow is the new fast"

~~~
apotheon
More seriously, "Deliberate is the new fast."

------
mrbgty
tortoise and the hare

------
fizx
"Festina Lente"

------
Tichy
"Professionals do not write bad code — ever."

Bla, blub

