Code sucks | Hacker News Reader

Code sucks

leonsbox.com

34 pointsLeonidBugaev43 comments

"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.

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.

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.

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.

Thanks! Good point.

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.

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.

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.

I'm just going to throw this in: Facebook has developed its own VM for PHP to make it fast enough for their scale. https://www.facebook.com/note.php?note_id=10150415177928920

Facebook developed HipHop a compiler for php, they don't use php as an interpreted scripting language.

Twitter uses the JVM, but the code is for the most part compiled from Scala.

Hi! Thanks for response. You get me wrong.

I was not talking about Java, i just mean then when your projects scales to twitter/facebook level you will have to use different tools, and it's ok.

Regarding Facebook, someone already replied about PHP. But i also should add, that Facebook use LOT of Java, just check their open-sourced projects http://developers.facebook.com/opensource/.

At such scale its ok even to develop own hardware.

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 ;)

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.

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

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.

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.

Thanks! Exactly what i mean.

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.

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.

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.

Good point.

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.

"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

http://abstrusegoose.com/432

be sure to read the tooltip. that's the important bit.

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"

Thanks for link :)

I did't mean that code should suck. There are lot of techniques that allow you to write good enough code, that will be easy to maintain. For example TDD, and using code-reviews (hello to Github pull-requests).

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.

> 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.

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

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.

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.

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

Thanks for response!

For sure I don't mean that you should write crappy code. I mostly talking about premature-optimizations. Right now there are lot of tools and techniques that allow to control code quality. At least test, code-reviews and code analysers.

Even awesome code won't automatically scale because the developer is a genius. The idea of premature optimization applies to architecture and infrastructure as well.

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

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.

We're constantly developing as programmers and I'm sure where you open your code written a year ago you first intention is to say "What a crap!"

Proper grammar helps tooooo.

Yeah, i'm working on it...

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