[jwatte]

"they're probably wasting more money because the codebase is terrible."

A terrible code base that serves customers is better than a beautiful codebase that goes unused. I think your criteria is expressed poorly. Perhaps you meant that bad developers are unable to produce code that serves customers well? Add in, a terrible product. (Product != codebase)

[eikenberry]

Personally I think this idea of a terrible codebase that still presents a wonderful user experience is an urban legend. In 20 years I have never seen it. I've seen plenty of terrible codebases that limp along, with the staff constantly fielding bug reports from unhappy users. But never one with happy users that just happens to be ugly under the covers.

[jazzyk]

This. A hundred times.

[sfennell]

I do agree that a product that functions on bad code is better than no product at all. If there where very terrible design decisions made in the beginning. This could have a very negative impact as the business starts to add customers.

A terrible codebase will _eventually_ fail to serve customers for a few different reasons. Scalability is huge and may be very difficult to find performance problems and fix. maintenance time, and time to add new features are places where a terrible codebase will eventually impact a customer.

[Roboprog]

Scalability is overrated :-)

Ability to add new features without breaking things is nice. Uptime is nice.

Many products do just fine with a few thousand occasional users, but too many developers think that they are building the next Amazon or something, and overcomplicate things to death for performance reasons.

[throwawaythisis]

That's a good point, and I agree that I expressed my criteria poorly.

When I'm saying 'the codebase is terrible', I'm talking about front-end code for a web app that is a convoluted mess of jQuery written by someone who is clearly not used to writing javascript, and quite possibly a bad developer even in the language they are comfortable with.

Even if they're decent at whatever their primary language and 'domain' is, the front-end side of things is such a mess that it noticeably impacts performance and the ability to work on the app well before even the MVP is done.

I've worked with front-end apps (and even websites) that were multi-megabyte monstrosities that loaded multiple versions of jQuery, hacks upon hacks to make things work, and not even the simplest of optimizations (lazy-loading images, 'browser-side' caching, etc).

I've worked with jQuery-only front-end apps that took more than a month to build, did only the most basic of things, and were almost impossible for me as a contractor to work with. I would rewrite the whole thing in either Backbone or some variation on the react/flux approach in, at most, two days, and be able to get the in-house developer up to speed in another one to two days if they were capable and, perhaps more importantly, willing and remotely curious.

In part this has been due to the current speed of development in browser technologies and frameworks/libraries, and in part it's just part of working with in-house developers who have no love for their job or have other things that they prioritize (35+ with kids, understandable!).

Usually this level of horror only presented itself in older, more established companies with 'legacy devs', but I've seen similar issues with (web) startups that hired without knowledge of the domain.

So, to be clear: getting the job done is the priority. I've worked on Backbone projects where I would've loved to use the latest and greatest, but happily worked with stuff that I would consider, in front-end-hacker-news-hipster terms, old-fashioned. And I've come to realize that if you have clever developers with curiosity, you can get a 'front-end app' done that isn't pretty, but works well. But too often, especially in the 'cheaper' startups with little founder-level technical know-how of the domain (front-end), I've seen things go very, very wrong.

[julie1]

Most of the time spent is in debugging/maintaining.

Terrible code base says that the value per customers is decresaing while customers increases because your costs (of software QA) are eating your margins.

Ugly codebase that does not scale with increasing efficiency for instance.

Remember low OPEXes always beat KPEX (investment)

People focus on features in software as the only value, I think it is the recuring costs per feature that should be the value.

For instance storing digitalized book is plain stupid. The first book printed is still there because paper/ink are cost efficient in terms of recurring costs for their value of keeping information whereas servers/software ... will doom data to an end because of reccuring costs that don't scale.