[aahortwwy]

Nope.

The startup I work at has been compartmentalizing and chipping away at our shitty code for the past eighteen months. We're not doing this because it offends our aesthetic sensibilities. The shitty part of our codebase is truly shitty. It fails to do its job regularly, causing significant toil in various parts of the business. Junior engineers can't make simple changes to it without causing serious regressions in seemingly unrelated parts of the system. It's slow as fuck. New engineers have to spend weeks reading the codebase if they hope to understand it, and some just give up. There's a big, measurable, drop in velocity whenever we have to work with the shitty codebase. So now we're effectively forced to do an incremental rewrite in order to build new features, which is terrible because rewrites suck and bring their own drop in velocity with them.

In practice, writing shitty code is not all that much faster than writing good code if you know how to write good code quickly - but I guess some people don't bother to learn.

I read somewhere once that at a growing company the next person who works on the code you wrote is highly likely to be new to the company and have less industry experience than you. When you write code, you should write so that that person can work on it productively.

[ryandvm]

I believe you, but would the startup even exist if they had spent 2 or 3 times as long developing the MVP?

The reality is that good engineering has higher upfront costs than quick-and-dirty. Sure, it's usually cheaper in the long run, but initially it either takes longer to plan or it takes more expensive engineers to execute. And for a lot of startups, getting that cheap MVP out the door is the only path to additional investment.

I'm all in favor of quality engineering, but I'm also pragmatic enough to realize that sometimes you have to sling a little shit in order to gain the luxury of doing it the right way.

[aahortwwy]

This is the standard rebuttal, but I don't buy it.

> would the startup even exist if they had spent 2 or 3 times as long developing the MVP?

It does not take 2-3 times longer to write good software. Arguably a non-shitty version of our MVP would've actually been faster to develop, because we have a custom web framework, ORM, and build tool when we could've used mature open-source projects in their place.

> it takes more expensive engineers to execute

This is probably true, or perhaps "more carefully selected" (which just means a more expensive recruitment process).

[cryptica]

Agreed. Once you have experience, writing good code takes less time than writing shitty code, even in the short term. Good code is easier to test, easier to reason about and it's easier to work on it as a team.

Shitty code is impossible to work on as a team. Only for solo developers. I think shitty code can be fine for bells-and-whistles kind of logic but the foundation has to be carefully thought out. Good code is code which anticipates requirement changes. I disagree with the author of the article that it's not possible to predict the future. You only need to have a very vague idea about different future possibilities in order to be able to design a very good architecture.

Compare the shitty code approach to the good code approach when building a very simple front end application:

---

Shitty code approach:

You happen to know Swift so you just start coding the thing natively in Swift for iOS... Then after 6 months you did a lot of work and you start getting a few users then you figure out that a lot of people are complaining that you don't support Android, so then you start to build the same app again for Android using Android Studio... After 6 months, you roll it out. Then after 1 month users are complaining that the mobile app is unwieldy and they're asking for a web version... You are shocked. You did not see this coming. So then you spend another 6 months building another version of the app with React. Users start complaining that the UI in the web version of the application doesn't match the mobile version... Also, now some users demand a new feature... Now you have to implement it and test 3 times (once for each device), you are wasting huge amounts of resources, your team hates you. You're moving too slow. Your investors decide to cut your funding. Your career is over.

Good code approach:

After carefully looking through the requirements, you figure out that users will probably want to run the app on desktop, web, Android and iOS... So you look at what frameworks support all these platforms... You decide on VueJS with Electron because it's lightweight, has few dependencies and can run on all platforms including mobile. You decide to use CSS media queries for responsive design because it provides a relatively consistent UX/UI accross different devices. You spend 6 month building the app, you ship. Users start using your product, telling their friends about it (who are using different devices)... Some users point out that a feature is missing... No problem, you develop it once, test it once and ship it to all devices at once. Your users love it. Your employees are happy, your investors are pleased, they invest more. Your career is looking promising.

[scottious]

I feel like the author is really saying "don't over-engineer". At no point does he say create code that does not work. The closest he says is that ALL systems will fail and that he'd rather fail with throw away code than some overly abstracted, lovingly hand crafted pile of code.

The point the author is trying to make is that trying to build a perfectly designed cathedral of code can often be counter productive.

[the_cat_kittles]

ah, so shitty code got your startup to a point where multiple engineers and new hires can complain about it for 18 months? score one for OP

[aahortwwy]

That's one perspective.

Another is that we're in a highly competitive industry. Our shitty code is severely hindering our ability to move fast and respond to competitive pressure. Had we paid more attention to quality while building earlier versions of our software we would be building an insurmountable competitive advantage right now.

NB: there are non-shitty parts of our codebase which have been able to evolve effectively as the company has grown. So I have definitive proof it's possible to produce good code at the MVP stage.