

Whatever works - sahillavingia
http://sahillavingia.com/blog/whatever-works/

======
icebraining
_Although immature code may work fine and be completely acceptable to the
customer, excess quantities will make a program unmasterable, leading to
extreme specialization of programmers and finally an inflexible product.
Shipping first time code is like going into debt. A little debt speeds
development so long as it is paid back promptly with a rewrite... The danger
occurs when the debt is not repaid. Every minute spent on not-quite-right code
counts as interest on that debt. Entire engineering organizations can be
brought to a stand-still under the debt load of an unconsolidated
implementation, object-oriented or otherwise._

Ward Cunningham (<http://c2.com/doc/oopsla92.html>)

See also, Technical Debt (<http://en.wikipedia.org/wiki/Technical_debt>).

~~~
brlewis
The point of the debt analogy is to communicate that it's something long-term
undesirable, although it can be a short-term expedient. Where the analogy
falls short is that real debt almost always has to be repaid. In a startup
searching for product-market fit, the opposite true re. technical debt.

------
chollida1
Joel Spolsky made a similar point in one of the stack overflow podcasts.

He and Jeff were talking about twitter's downtime and Joel said something
along the lines of "and look at how all those other startups destroyed twitter
by having more up time."

The point being is that twitter just went ahead and shipped. They were able to
fix their software issues after they found out what their product actually
was.

~~~
absconditus
Perhaps people also have low expectations for software.

~~~
chollida1
> Perhaps people also have low expectations for software.

Maybe, but I don't think that has anything to do with the point that people
could have easily migrated to other clones but stayed with twitter as it was
the best platform, performance woes aside.

------
irrationalfab
There is an important side effect of this mentality: you are stuck with a weak
foundation. Not only technically but also in front of the eyes of the
consumers.

When you ship a product users build expectations about it. They use in
different ways that the ones you might have expected. If during further
development you understand that a feature is not desirable anymore (e.g for
technical problems with some other super awesome feature) pulling support may
backfire.

This was evident in each Facebook redesign, or in the new version of Final Cut
Pro.

Therefore, I think that there is definitely a sweet spot and that this spot
isn't "ship it as soon as it works".

------
bvi
It's a pretty common concept. You can't be a successful entrepreneur or a
manager without a "well, as long as it works" mentality.

"Jugaad":
[http://blogs.hbr.org/cs/2010/01/jugaad_a_new_growth_formula_...](http://blogs.hbr.org/cs/2010/01/jugaad_a_new_growth_formula_fo.html)

------
posabsolute
I really do not agree with that, now that can work with small websites you
don't care about and just not going to do maintenance.

but in my experience, the technical debt will be a big problem later on, if
not a total deal breaker. This is a problem found a lot in html integration,
and jQuery new comer that push one millions of events in the dom.ready

Unmaintainable mess = hours and hours of lost work

I find that the easiest and cleanest solution is generally the better, I
always try to not over engineer my code.

------
recursive
Sounds like someone who doesn't have to maintain his own code.

~~~
unit_testing
I had the very same thought.

This mentality is fine if you don't want to (or have to) maintain and support
anything—and from looking around the author's site, it appears he makes dozens
of small things and then leaves them to rot.

~~~
aparadja
Making dozens of quick things to try them out (and then abandoning them) isn't
such a bad strategy when searching for a good business idea. Obsessing over
the backend of an mvp might be a net negative.

------
TheFuture
I find myself struggling with this constantly as I develop iOS apps. There's
something about the programmer's brain that gets obsessed with the details,
and doing it the "right way", and tweaking for completely insignificant
performance gains, and just loves researching all the minutia.

You need to Get It Done. Especially if you're dealing with consumer software,
you need to get something infront of the customer, because in 6 months
everything may have changed!

If you have the luxury of working on corporate software where you have loose
deadlines, open budget, and no competition, well go ahead and comment all your
code and research all your best practices. It might even be worthwhile,
because there's a much better chance that code will still be around in 8
years. If you're a startup, forget it, your product will likely be defunct in
6 months.

------
fauldsh
The only point to rewriting is to extend the project.

You can't always predict if new features will be wanted. So unless you want to
have to wait on a rewrite for each new feature you will need a rewrite.

Rewriting all your code because you might need to extend it is a bigger waste
of your time than spending that 20% longer to make all your code extendible.

If you don't want to rewrite for the new feature then you contribute to the
spaghetti.

Due to your bad code it'll take increasingly long to add features and you will
eventually spend longer implementing the whole system (with extra features)
than implementing a nice version first.

------
ddelony
As C2 puts it, "Do the simplest thing that could possibly work."

[http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.htm...](http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html)

------
chaosfox
For a sufficient definition of "works", whatever indeed works.

------
rick888
In business, you sometimes have to release code that isn't perfect. However,
I've seen too many apps that were hacked together to get them out the door.
After customers are using it, you really almost never get a chance to rewrite
it from scratch and the end result is a system that becomes a monster to
maintain.

------
Zev
_But it works. And users will never know the difference._

Sure they will, when your app starts to crash, or become unreasonably slow due
to something hacked together without a second thought as to how well it would
work.

~~~
pkulak
Like how dataapp.com is not responding right now, you mean? I think he just
disproved his point...

~~~
brlewis
From the article: _In later versions, I had to rewrite the entire database
solution I had built (think one large array of objects for the entire app…
yeah, seriously, but it worked!)_

The rewritten version doesn't prove anything about the initial hack.

------
funkah
It is occurring to me now that mastery of software development probably
involves knowing how and when to invoke "whatever works" wisely.

~~~
mwsherman
Indeed, I am coming to this conclusion myself. Most of us can write code. Most
of us can do capital-A Architecture by reading blogs. The thing that separates
programmers that I want to work with are those that who maximize the ratio of
benefit to work.

It's not about the code, it's about economics in the broad sense --
understanding opportunity cost, understanding what "benefit" looks like,
understanding your team, and making informed trade-offs.

No one thinks duct-tape code is "good" as an art form, but it might be the
right decision for a given point in time.

