

Should you code well or code fast? - andyford
http://www.creativebloq.com/netmag/should-you-code-well-or-code-fast-121310118

======
jdlshore
This wasn't a very good essay. The closing line sums up its problem: "We need
to complete quality work in the shortest amount of time possible." Why, yes, I
would like a double helping of pablum! Thank you for offering. You know,
before now, I thought it was best to complete quality work in the _longest_
time possible.

Sarcasm aside, the most telling line was this one: "If the project is for a
three-month campaign that must be completed next week, the shortest path to
the finish line is probably best. I've only been a developer for five years,
and 95 per cent of my professional projects are [like that]."

This essay was written by a developer at BKWLD, an "independent digital
agency." They do a lot of advertising work. Of _course_ code quality doesn't
seem important! Code quality matters when you have a team of people developing
and maintaining software over a long period.

Here's a more nuanced view: speed matters, and you can be really successful
developing important, business-critical software by emphasizing speed over
quality. If it's a problem domain you're particularly familiar with,
especially if you have a lot of tools, frameworks, and libraries to help you,
you can get an impressive amount of work done.

As you continue to work, you'll slow down. At some point—about six weeks is my
guess—you'll actually be going slower than someone who's focused on quality.
They'll speed up over time (asymptotically), and you'll continue to slow down
(also asymptotically). You'll still be ahead of them, though, because you got
so much done in that initial burst of energy. Your life will start to suck,
though, and you'll be looking forward to when the project is done.

Eventually—about three to six months, I'd guess—you'll fall behind. You'll be
going so slow that your initial advantage will have been erased. Luckily, you
now get to hand the project off and start a new one. Win!

Three to seven years later, your code will be thrown away. It will be so
expensive to change that it no longer makes economic sense to maintain. If
it's still relevant, it will be rewritten at great expense and even greater
opportunity cost.

So, does quality matter? Depends on who you ask... and who ends up paying for
it.

~~~
davesims
"Code quality matters when you have a team of people developing and
maintaining software over a long period."

And for me, 'a long period' is anything longer than a month, or more
specifically, the time period it takes for me to have to change any code I've
already written in order to deliver new business value to a customer.

...and just noticed your 'six weeks' estimate. We're on the same page here it
seems. :)

------
davesims
Been thinking about this a lot lately, and I think one of the problems is the
language and metaphors we use to describe the quality of the code.

Words like 'clean', 'elegant', 'well-structured', even SOLID are qualities of
objects we want to consider at a distance, like statues or paintings. They are
words of repose and reflection. You know: business death.

Here's an example from this essay:

"There is a reason good code is considered to be a form of poetry. It's
elegant, clean, easy to read, and fun to write. These are all exceptional
qualities that we should strive for every single day."

Try telling a product manager or CEO or other stakeholder how 'clean', 'easy
to read', or -- God forbid -- "fun!" your code is, and watch their eyes roll
back in their head. (I exaggerate for effect.)

These ideas make sense to us as developers because that's what we spend our
entire day doing: considering, reflecting and thinking about code. But I think
what we should be talking about is the inherent _speed_ of the codebase. I'm
not talking about my velocity as a developer, or the velocity of the team and
how many story points they deliver per sprint, but the inherent velocity of
the codebase as a function of its technical debt. Codebases, from a business
standpoint, should not be "clean" or "dirty", but rather "fast" or "slow".

Technical debt should be surfaced to the stakeholders using language that
conveys the dollar value, the fiscal liability, of technical debt. The most
accurate way to describe that and show how debt is slowing your team down, is
to talk about its inherent speed.

"Our codebase is getting slower" makes business sense to a Product Manager.
"Refactoring this will make our codebase faster" is a phrase that conveys the
worth of initiatives that otherwise seem to have no immediate effect on the
bottom line.

All of the tools and agile methods we have talk about velocity in terms of
what a team is delivering, and can parse that down to the sprint and developer
level. But in my experience, the most significant contributor to a team's
relative speed is the (intertia|speed|velocity|momentum) of the codebase
itself, as a function of its technical debt. I think we need to start using
language that intuitively and constantly surfaces the dollar value of
technical debt to the stakeholders, so that "just ship it!" no longer sounds
like a sound business strategy.

~~~
lifexkills
This is a great idea. Thanks for sharing.

It's definitely much easier to convince people when you're talking dollars
rather than "beauty" or "maintainability" which are much more abstract
concepts. This pushes that to the forefront.

I wonder if anyone has experience with trying to use this language that they
can share. I'm curious because it seems like a great idea. But I wonder if it
would solve the "just ship it!" mentality. I still feel like there may be a
missing component which is that what might be fast to build now will slow down
the overall development effort later on. I think that time gap is one of the
big things that stakeholders fail to think about. They're thinking "what can
we get out the door now?" and not further down to what impact that will have
on getting other things out the door a few months from now.

Great post!

~~~
davesims
Yeah I'm trying to get my head into how this would come about. It would be
along the lines of how agile thought leaders shifted the notion of 'man hours'
to 'story points', or how we stopped measuring LOC as a feature of
productivity.

But there would have to be some cultural and language support for an entire
idea around _what_ a codebase is. The idea that it is an object that can
_possess_ the property of velocity will take a bit of enculturation. But the
software/agile community has done it before, so...

------
jinxedID
Slow is smooth and smooth is fast

~~~
agumonkey
Infinite upvote. A French word for fast is 'vite', from Latin visitus meaning
to see; slow -> see -> fast.

------
redact207
Answer: learn to do it the right way and you'll end up coding faster.

~~~
mathattack
I was thinking similar. The best (and deepest thinking) programmers that I
know are also the fastest. They don't always work the most hours or seem the
most harried (which doesn't bode well for places like Advertising which like
to seem "Busy and Creative") but they can produce in 20 lines in a day what
others produce in 500 lines in a week. They may not look as fast though.
("What? All day? Just 20 lines?")

~~~
collyw
I also notice that good design decisions can go a long way. I implemented a
"shopping cart" type feature where users can select a set of samples they are
working with. Initially it was just to compare ones which would have been
paginated apart on the interface, and there would have probably been a quicker
fix. But it has proved useful for many other features since then.

------
DrinkWater
When a question asks whether to do A or B, you know the answer is: "it
depends"

Just use your brain, use your judgement on the result, make a decision,
iterate.

~~~
dllthomas
[http://en.wikipedia.org/wiki/OODA_loop](http://en.wikipedia.org/wiki/OODA_loop)

------
mpermar
The best way to code fast is to code well.

When your code sucks or you intentionally code fast you end up adding tons of
things that will drag you over and over again. And unavoidably you'll end up
asking yourself "why didn't I code well. I would have ended up much faster".

------
wafuru
The best developers I know have the experience to know when each is required.
Getting the right balance between speed and quality is one of the things I
find hugely valuable in a developer, usually more so than their maximum coding
speed or maximum output quality.

~~~
cpncrunch
The best developers code well AND fast in my opinion.

~~~
wafuru
When pushed to their limit, one of the two will drop first.

------
JackMorgan
I give some actual advice and suggestions on learning to become a faster
programmer here: [http://deliberate-software.com/quality-is-future-
speed/](http://deliberate-software.com/quality-is-future-speed/)

------
ndhoa
I think code visibility is more important (intention revealing). It allows you
to move forward (with proper abstraction) while still provides a chance to
refactor later. DRY and Boy Scout Rule should always be honoured.

------
Teapot
'Release early, release often.' This suggests quick and dirty code is better
than slow and mature code.

Though worse code benefits the most by having well-enough made Comments.

------
alexrson
My favorite pithy insight on this subject is from McConnel's code complete
(mangled, most likely):

"Code is usually read more times than it is written."

------
amagumori
por que no los dos?

------
samnardoni
Yes.

