Code sucks

"The only thing that matters is Business value. "<p>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 <i>business value</i>, not because I'm some superawesome dude who likes to do nothing better than write code. I'm growing to hate it (the actually <i>code writing</i> part - not the problem solving part). But when <i>I</i> am responsible for delivering <i>business value</i> with code that I didn't write, all options are on the table.

Of course it does! It isn't necessarily about premature optimization or temporary code or documentation. It is because <i>we don't know where we are going</i>.<p>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.<p>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.<p>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.<p>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.

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

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.

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.

What a nice call for mediocrity.<p>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".<p>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).<p>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.

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.<p>It's never perfect.<p>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.

<i>"Remember Twitter story. When it was first started it was super buggy Rails app, that was down all the time"</i><p>For every one of these examples there are 10 where newly shipped code is not "super buggy".<p>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.<p>Should you rewrite entire code when it's bad? no, this is almost never the right move. <a href="http://www.joelonsoftware.com/articles/fog0000000069.html" rel="nofollow">http://www.joelonsoftware.com/articles/fog0000000069.html</a>

<a href="http://abstrusegoose.com/432" rel="nofollow">http://abstrusegoose.com/432</a>

There is always a lot of packaged up implied assumptions in stuff like this.<p>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".<p>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").<p>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.

Luckily there are people that write good code, is difficult to find them but they exsist.<p>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

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.

Proper grammar helps tooooo.