I thought this is a no brainer but alas, I should have known better. The web is full of stories about horrible code especially about enterprise software, that should be best coded of them all. You can blame it on the developers as they are the ones writing the code, but ask them and they will point the finger (not that finger) at the managers who "are clueless about software developing" and who don't care about anything as long as the software works and it's finished on time.

The truth is that both parties are to blame, although managers are the main culprits as they can enforce the quality of code. And their problem is that they don't understand that maintainable code has business value.

But let's define maintainable code: "Maintainable code is code that can be easily understood and modified without generating new bugs". Yes, it's my definition.

Managers care about 2 things: to finish the project on time and within the budget. Well, if the software is a product which generates revenue or it's an important business asset (used by the business itself to reduce costs or improve productivity) then the project is never finished. Bugs uncovered by users need to be fixed and new features will be added or modified as the client/business needs are changing. And that's where the quality of code will dictate your expenses.

Simply put, ugly code may work but it's very prone to bugs and any change takes longer than needed because the code is so coupled together that you can't change A without affecting B even if A and B are unrelated features. Fixing bugs usually means breaking some functionality and introducing other bugs. And in time, with every change everything becomes harder and harder, bugs appear more often, the users are unhappy (It doesn't work!!! Stupid software!) and more developers are needed to handle the monster.

Of course, the new developers need time to learn the code base and to understand it before they can actually do something and in the mean time your users are screaming. In the end, you get to increase costs (from hiring new developers and the good ones probably won't stay too long, unless you're paying them very well and you let them) while the pace of delivering fixes and new features gets slower and slower. And if it's a product you're selling  this means higher development cycle and more time required until you get income.

But what if the code was maintainable? Then, by default there would be less bugs as there would be automatic testing in place. Changes can be made much faster because of loosely coupled code and with unit tests, any break in functionality or new bugs would be caught instantly. There wouldn't be a need for more developers, in fact it may be the opposite as you wouldn't need a whole team to maintain the application. If you replace a developer, the new one can understand the code base in short time so you get to fix bugs and deliver new features faster.

Having less bugs and getting fixes and new features will make the users happy. If they are your clients, this means you get to sell them the next version faster. If the software is used internally by the business, then you help your co workers to become more productive and the business more efficient.

It's important to realise that good code is not just a developers concern because the code is the application. So you need to ask yourself what you want: shoddy software which just works (most of the time anyway) but it is a pain to maintain and develop further or a high quality asset which can be easily adapted to the stakeholders needs. One will increase costs and stress, the other will improve productivity and help increase profits. You decide!

Are you a coder or a software developer? Think a bit before you answer that.

You might answer that both are the same thing, just synonyms but the devil is in the details once again. What does a coder do? Well, he (or she) writes code! What does a software developer do? (S)He creates and maintains software as a virtual product which has value for the business.

If you're raising an eyebrow now thinking "The bullshit is strong in this one" fear not! It sounds like bullshit but actually it's the truth. Look, nobody's paying you to write code. You're paid to develop a virtual product which can generate revenue or reduce expenses or improves efficiency or it's useful for the business one way or another. That's it. If you could achieve the same result without coding, nobody will complain. Coding is just a tool to get the result.

Of course that every software developer writes code so automatically (s)he's a coder, but it's important to understand the difference between the tool (code) and the purpose (create business value). A good coder writes and cares about good code. A good software developer writes and cares about a good product which just happen to be developed using code.

Coding, by itself, doesn't bring any business value. It might bring enjoyment or help you understand programming better, but if the code doesn't mean an application which fulfills the stakeholders needs (and expectations), then it's useless. In fact it's worse than useless, it's an useless expense.

So if you weren't doing it already, stop being a coder and become a software developer. Your boss/client will be happier if you show them that you understand you're building a valuable product for them and it turn, this will improve your professional image and help you earn more money. A win-win situation.

I've just read this post . Especially this:

"Testing does not have value on its own. Neither does programming. I have seen more than one team crank out lots of code and yet be unable to ship a product anyone would buy. For that matter, designing doesn’t have intrinsic value either."

I don't agree. It's like saying that wood doesn't have an intrinsic value when you're crafting furniture. A pile of wood is a cost for a business but at the same time enables you to make that furniture. That is, without the wood, you have no furniture so how come the wood does not have business value? The fact that it enables you to have a product which will generate income is the business value.

Same with developing software. It's true that the business care about the end result but without programming/design/testing you don't have much of a result. And good programming/design/testing allows you to have a better product for all stakeholders. The customers will get something that works properly while the software company gets a product that is easy to maintain and thus it's much easier to add new features, less bugs to fix and consequently it doesn't have to ramp up the costs. Add the bonus that happy customers will recommend your product to others so you'll get more income. But can you deliver a good product without proper testing? Can you keep up with the competition if the code base is a mess?

I don't think there are many (if any) people who do testing just for the sake of testing or even coding just to code. Each activity even when done as a hobby has a purpose that builds value. If I like tinkering with programming languages I code so that I understand the language better, if I'm toying around with application architecture, it's to come up with a better solution.

In my opinion, you simply can't say that tool X doesn't have an intrinsic value as long as tool X is required to actually produce business value. Any tool that enables you to generate (more) income or allows you to not increase the costs or to stay competitive has business value in my eyes.