
We must ship now and deal with consequences - fogus
http://blog.objectmentor.com/articles/2009/10/15/we-must-ship-now-and-deal-with-consequences
======
swombat
_Writing bad code never increases your net worth_

This is a really silly point to write, and obviously disprovable. Here's a
really simple and realistic example:

You've just deployed your app. It's perfect... except there's this huge
performance issue with one of the most important pages. Your app's just gone
up on Slashdot, TechCrunch, and everywhere else. Zillions of people are using
it. You have two options:

1) An ugly evil hack that will sort out the performance for that page. Total
time: 30 minutes.

2) A re-architecting of that part of the application that will cleanly resolve
the performance problem with efficient use of caching. Total time: a week.

If you choose option 2, you're a moron (sorry, no other way to put it). Option
1 obviously increases your net worth. Yes, you need to go back and do 2) as
well, but this is a pretty damn good scenario where it makes a lot of sense to
write and ship bad code knowingly. And yes, it does increase your net worth -
those zillions of users might stick around instead of claiming your app's
broken and moving on.

~~~
projectileboy
Your first sentence sums it up nicely. Speaking as someone whose family has
been kept fed by the "agile" gravy train, let me say first that I think all
that stuff is valuable. However, many of the industry gurus make these broad,
sweeping generalizations based on their own experiences, and most of their
experiences come from consulting work for huge, broken corporations. Applying
these lessons to startups, or to small, fast companies in general, is just
nonsense.

------
trebor
I'll be imprudent:

    
    
      What is this talk of 'release'? Klingons do not make software 'releases'.
      Our software 'escapes' leaving a bloody trail of designers and
      quality assurance people in its wake.
    

<http://gradha.sdf-eu.org/textos/klingon_programmer.en.html>

Heh, this always gets me to laugh. I've been on both sides of this issue
though: I worked at a place that shipped code and their version 3 release is
shaping up to be what their 1.5 release should have been. But I can also get
to the point of paranoia, "I can't release _this!_ it still has bugs!"

Maybe we just need to have a "release determination board" filled with 50%
pessimists and 50% optimists. That way, you'd have a huge argument over when
to release.

To release is risk, but is risk itself imprudent? I doubt it.

------
10ren
I think his definition of debt is the same as "not perfect".

There's a lot of evidence from successful people that good enough is good
enough.

------
edw519
After reading both this post and yesterday's, I got to thinking more about
technical debt.

We all create it. Sometimes for better reasons than others.

It's everywhere, it's costly, and it sucks.

Then I thought about another scary truth that wasn't mentioned in either post:

 _Much of it never has to be paid back._

That's right, we create "technical debt", but so what?

I often maintain code that's 5 to 10 years old with as many as 100 mods. But
just as often, I come across something 10 years old that looks like crap with
_no_ mods. How can this be?

Because it works. Somebody wrote a function they needed 10 years ago, and it's
apparent today that they didn't know what they were doing. Since then many
others have called that function. You want to rewrite it, but you dare not
touch it. Why risk production without a request?

It's ugly, it sucks, but it works and has always worked. I bet about half the
"technical debt" I've encountered is like this, debt that will probably never
be paid back. Then is it really debt at all?

~~~
far33d
The biggest reason you never have to pay back technical debt is because the
company doesn't exist anymore.

The next biggest reason is because that debt no longer applies - the idea,
feature, or product you wrote that code for is unnecessary and has been
scrapped.

The original context of this whole "debt" conversation was startups. If you
can't find product-market fit, you are dead, no matter how clean your code is.
You have to move fast and iterate quickly because finding that fit is more
important than clean code.

All the rules change for established companies with clear product road maps.

------
far33d
I think this metaphor is being stretched way too thin at this point.

