You Should Write Ugly Code

This all sounds great, but I've worked in places where this has been the philosophy.

Unless you have somebody in charge who understands the importance of code quality (and why a bad codebase can be a ticking time bomb) you will find it very difficult to budget time/money for the removal of technical debt.

You will often meet the attitude of "well it works now, why waste time rewriting it?" or "sure, do that. But let's clear this milestone first", "oh, priorities have changed we need to add this new feature first".

This usually gets externalized to developers who end up working excess hours firefighting a horrific codebase or implementing a bunch of features twice, once in the clean codebase and once in the dirty one.

I've had times where I worked 8 hours at work and then came home and worked another 6 getting the new codebase in sync to a point where it could be replaced.

And when people start loosing money because shit is falling apart due to a tangled, buggy codebase without proper tests guess who's ass is on the line?

> Would you be willing to buy a piece of furniture twice the normal price because the craftsman uses the most expensive tools available? And what would you think of a poor craftsman who, using poor equipment, manages to create great furniture? Who's the best craftsman of the two?

The author forgot to mention most likely alternative here: a poor craftsman uses poor equipment to create poor furniture that breaks easily.

We shouldn't write maintainable code because the idioms might not seem fashionable at some point in the future? Never mind that code is read way more than it's written and that maintenance costs way more than development. Building up massive technical debt is fine in the short term but eventually you'll have to address it and that's going to cripple development on the product. OOP principles aren't a fad, they're fundamental to structuring code in PHP.

The analogy with the furniture is particularly misleading. Would you pay half as much for a chair that occasionally falls over? That takes a long time to get repaired because each of the legs is tightly coupled to one another? I'd rather pay double for the reliable version.

I've worked with a lot of code bases in the past where the developers have had a resentment towards new methodologies and saw people who tried to use new ideas as just trying to show off. It's a disheartening experience to want to use such fashionable concepts as 'objects' only to be told that the way things are done is procedural programming with SQL queries nested in markup like it's 2000 again. In my experience it's been because they've not wanted to invest in learning new things. That's not a good ethos for a programmer. Let's not promote it.

I actually thought the article would be about indention, style, etc.

Brakes generally aren't expensive (obviously, this is all relative... but lets ignore that), so instead of waiting a year, your more likely waiting a few days at most.

The cost of good quality code isn't expensive either, in the short term or even in the long term. However, for the un-or-misinformed, writing good code might seem higher. Indeed, I'll even go so far as to say that for less skilled individuals, good quality code might seem to increase the cost dramatically.

> if you're being chased by wild hungry bears, you don't care whether the car has brakes.

A little planning would mean I wouldn't be in that situation: bears and no brakes. Though, it's amusing coming up with ways I could find myself in that position. =)