
Code sucks - LeonidBugaev
http://leonsbox.com/blog/2012/12/01/your-code-sucks/
======
mgkimsal
"The only thing that matters is Business value. "

Yes... and when it takes me 3 days to make a change to an undocumented,
untestable pile of crap, when it should normally take 2-3 hours, any
requirements more than, say, 2-3 changes should entail gutting and/or
rewriting, and that's because of _business value_ , not because I'm some
superawesome dude who likes to do nothing better than write code. I'm growing
to hate it (the actually _code writing_ part - not the problem solving part).
But when _I_ am responsible for delivering _business value_ with code that I
didn't write, all options are on the table.

~~~
Cyranix
Agreed. "Business value" shouldn't be a justification for constant quick-and-
dirty work; otherwise, the implication is that you don't see long term value
in your business. If you always budget some portion of time for paying off
technical debt or (hopefully) creating a more well-crafted solution in the
first place, you can still keep your time-to-delivery reasonably short yet
improve your ability to maintain pace.

~~~
mgkimsal
I guess more to the point, 'business value' has to be measured - it's
generally going to be measured in dollars.

If doing XYZ with the business will earn $50,000 over 6 months, let's consider
doing it. Now, we need to look at the cost. If the cost is a few days of work
- say... $5k for a team of people, it's a no brainer.

If, however, making the code do new things breaks old stuff, and ends up
taking 4 weeks, the cost may be $20k now, as well as 3x the opportunity cost
of the extra weeks, as well as potential lost good will or extra customer
service required to deal with things that broke because we pushed out new
functionality without any ability to comprehensively test.

Suddenly that potential $50k at the hard cost of > $20k might not be so
appealing, and is far less a sure thing.

This is one of the reasons it's been hard for me to be an 'employee' for any
length of time anywhere - the politics involved in trying to see a big
picture, and convince other people you can, in fact, do this, is troubling in
most organizations. However, as an outside consultant, you're treated
differently. And to the extent that you still run in to obstinate politics...
you get to move on instead of having to work in the same org for years on end.

------
columbo
Of course it does! It isn't necessarily about premature optimization or
temporary code or documentation. It is because _we don't know where we are
going_.

Give anyone on this board a clearly defined waterfall project, five years,
fifty million dollars and ten developers and I bet they'll make something
beautiful. Even if you don't agree with their decisions by and large you
should appreciate how well it would be written. This is because the first
couple years will be spent prototyping and learning while the last couple of
years will be spent building the finished product.

Our industry is permanently locked in prototyping and nobody knows where the
keys are. Companies want the software out yesterday and when they see it they
believe it is 'done'. I gave up telling people that I write applications,
rather now I just say I'm adapt at building very complex prototypes.

This is why we hate our own code when revisited. Maybe it is because we are
smarter, but it is also possible we don't remember what stress was forcing our
decisions.

I don't see this changing anytime soon. Working with the subpar, the hastily
decided and the rushed release is just something to be accepted.

~~~
LeonidBugaev
Thanks! Good point.

------
ringmaster
To be sure, it makes sense to ship over making everything perfect under the
hood. But to many who would read this post, it's granting implicit permission
to write code that is utter drek. They hear you offering consent to make code
that "just works" over actually giving thought to how users will ultimately
use the code or how future coders will maintain and augment the project's
codebase. Most developers I've met can't evaluate what "good enough" code is,
and shouldn't be given license to release merely working code.

As a person who has spent the bulk of his career now cleaning up other
people's lousy code and fighting technical debt, I would ask you to please
stop telling other people that it's ok to ship code that, in reality, does
suck.

~~~
LeonidBugaev
Thanks for response. I did't said that code should be awful, sure you should
control code quality, to be maintainable. I mostly talked that premature
optimizations and rewriting from scratch is bad.

------
hakaaak
I think that the Twitter analogy was awful. It implies that you have to have
an incredibly large team writing Java to be "enterprise", somewhat implying
that Java is needed to handle load. It isn't. Facebook is a great example of a
company that still survives uses a scripting language, and GitHub is as well.
I worked on an excessively large Java team, and the main highlight was slow
progress. I'd argue that the better way to look at it is that you often need
to be fast-and-dirty in development in the beginning, but later you just need
to slow down and be more careful and thoughtful- language and team size aren't
equivalent to success at later stages.

~~~
rpd9803
To be fair, I don't think you can reasonably consider Facebook's mega-crazy
(mega-crazy being applied without value judgement) PHP-to-C++ scaling method
to be the same as surviving using a scripting language. You can also argue
that (most) of the heavy lifting Github does is in git itself, which is an
amalgamation of C, Bash and Perl.. and the "good" stuff is all in C. Bash is
mostly interfaces and perl is for random stuff like sendmail, cvs import,
etc.)

Just because your Java team was slow doesn't mean all of ours are ;)

------
freyrs3
This article is loaded with implicit assumptions about what "business value"
is and how it gets created. All software businesses are different and I dare
say that most are not web startups. A company that develops SaaS, or
compilers, or fluid modeling software are going to have different needs at
different stages of development.

~~~
LeonidBugaev
Agree. I was talking mostly about web-services, as its mine main
specialization.

------
teresko
What a nice call for mediocrity.

How about instead of "your code sucks, but you shouldn't care", you had used
"your code sucks, improve it a bit and commit in a better one".

Also, writing readable and understandable code is not a premature
optimization.Quite the opposite. What you are "selling" is to write quite and
dirty site and then just patch them up. It is a road to unmanaged and
intentional technical debt.

------
jokull
Right on. This is related to "the big rewrite" that kills a lot of projects.
Time and usage makes code value go up. Even if it’s written in an old
framework that you wouldn’t use today, uses urllib instead of requests. Just
ignore the urge and move on (for now).

I’ve recently worked on an old project (www.oath.is), dusted it and launched
it as an app. It was a Django project and my urge was to rewrite the whole
thing so I could use SQLAlchemy and Flask which I had picked up in the
meantime. On the frontend I immediately wanted to rewrite everything in
CoffeeScript and Backbone.js. But I resisted it and managed to spend my time
adding features, a new design and unit tests and launched in like a week.
After launching I had some extra time to rewrite the jQuery-spagetthi, which
paved the way for some more advanced client side features without becoming a
horrible mess. So I guess you have to make that decision multiple times over
the lifetime of a project. But yes, holding off the urge is a good practise.

~~~
j-kidd
When the existing code base is at least functional, then of course, a big
rewrite is not warranted.

However, some of us are not as lucky. The situation is often such that the
existing code base is full of bugs that it can cause a ton of support requests
from the users, or even crash and bring down the production server.

In such situation, you can choose to firefight all days and have no time left
to implement new stuffs, or choose to rewrite.

Not using the latest hippiest libraries is really the least of my problem.

~~~
jokull
Agreed. When it comes to code that’s "not exactly how I would have done it"
but _also_ bug ridden I think it’s an easy decision.

------
ianstallings
This is one of those big challenges. Deciding when to tear something out that
is subpar to replace it. I'm going through this now with code inherited from
others and stuff I've written in the past that I think I can do better. As a
lead it's my job to "prune the tree" of code and guide it but I can't just
roll over every decision ever made simply because I want something better.

It's never perfect.

So what I do is for every chunk of code I think needs to be replaced or
solidified I ask myself first how it will impact my schedule, how it will
impact other coders as they do maintenance, if the end goal is a better user
experience, and if so does that serve the business? From answering these
questions I can determine if we should make a change now, or if we want we can
defer the change to a specific place in our timeline and plan it out. This has
worked well for me in the past.

~~~
bmohlenhoff
I agree. The temptation to roll over existing changes when inheriting a new
codebase can be overwhelming at times, and the only sensible way that I've
found to deal with it is to consider the impact to the schedule and how that
ties into the overarching business need for whatever it is that you're working
on. Without a bit of discipline here, I've found that it's way too easy to
start working on things that don't advance the project towards its overall
goals.

------
SonicSoul
_"Remember Twitter story. When it was first started it was super buggy Rails
app, that was down all the time"_

For every one of these examples there are 10 where newly shipped code is not
"super buggy".

I've stopped using many services because of their attention to bugs was poor.
Business value diminishes quickly when your product fails all over the place.
sure you can find examples of companies that pulled through even with glaring
problems, but there are also ones that succeeded because of competitive
advantage from great code, and i dare to opinionate that the latter has a
higher success rate.

Should you rewrite entire code when it's bad? no, this is almost never the
right move. <http://www.joelonsoftware.com/articles/fog0000000069.html>

------
swatkat
<http://abstrusegoose.com/432>

~~~
chewxy
OP's blog post wasn't about other people's code. It is about one's own code
and how it's quite important one stiffle one's inner voice that says "Your
code sucks"

------
jiggy2011
There is always a lot of packaged up implied assumptions in stuff like this.

Maybe there are problem domains where immediately rewriting everything in
Scala and applying TDD would be a huge win over some PHP that "seems to work".

Of course you have to weigh short term vs long term consequences and not rush
to conclusions (especially if you are new). You may have hiring difficulties
but that may work in your favour (see "python paradox").

Also I think that the best way to write code is to assume that bad code will
be written and apply stuff like unit testing as a means to make replacing that
bad code as easy as possible.

~~~
LeonidBugaev
> Also I think that the best way to write code is to assume that bad code will
> be written and apply stuff like unit testing as a means to make replacing
> that bad code as easy as possible.

Can't agree more. Tests and code-reviews help a lot.

------
fox91
Luckily there are people that write good code, is difficult to find them but
they exsist.

If you want to speak about the average (or below average) coder I agree, they
write crappy code and you have to deal with it, someday

~~~
LeonidBugaev
Yeah, sometimes, if the code looks like shit happens that it actually is this
:)

For sure it works only if you have someone with good sense of code quality.

------
wickeand000
I have really internaized this recently; more specifically I have made sure to
think about my code from an outsider's perspective and address complaints this
person might have.

------
calinet6
Hey man, speak for yourself. Not all of us write crappy code.

~~~
shasta
Yes we do. In 50 years a decent programmer looking at your code will think
it's crap.

~~~
freyrs3
They'll think its old code. I work with plenty of old Fortran linear algebra
libraries and I don't think they're crap, they're just old but they still get
the job done more efficiently than any modern software.

------
zeroexzeroone
Proper grammar helps tooooo.

~~~
LeonidBugaev
Yeah, i'm working on it...

BTW, this blog is open-sourced, and if someone helps with grammar i'll be
grateful :)

[https://github.com/buger/buger.github.com/blob/source/source...](https://github.com/buger/buger.github.com/blob/source/source/_posts/2012-12-01-your-
code-sucks.markdown)

~~~
zeroexzeroone
Very cool, far ahead of the curve.

