Hacker News Reader

Comment by codingdave | Hacker News Reader

I'm always surprised that "It works." is not #1 on these lists.

I get that as developers, it really matters quite a lot whether the code is good. But on a higher business level, software development is a tool, and the most important thing to the business is that it works. Working well and making it better and more efficient are incremental improvements to the business... but code that doesn't work is a deal breaker.

Beautiful readable, testable, maintainable code that fails to meet the business need is still a failure.

View on HN

It's easier to make Beautiful readable, testable, maintainable code that fails to meet the business need into working code than it is to turn ugly, unreadable, untested, unmaintainable (but working) code to a state where it's not a tragedy waiting to happen.

Edit, in a less snarky tone:

If beautiful, readable, testable maintainable code is buggy, I'd bet money on the project being structurally sound, but the developer having failed to understand something about the business requirements. It'll likely take a little while to get familiarised with the structure of the code, and then some more time to identify (and fix) the parts of the business logic that are not working as expected.

Ugly, unreadable, untested, unmaintainable code that "works" usually doesn't actually work, not really anyhow. It works fine for the cases that make the bulk of day-to-day work, but is almost certainly going to fail horribly when you hit an unusual corner case, and fixing that corner case is going to be a pain, because the lack of structure and testing is going to make it really easy to accidentally break something, and really hard to identify that this has happened (and why).

You are conflating "ugly/unreadable" with "untested" and with "unreliable". There's plenty of horrible but reliable code out there, and vice versa.

I'm conflating them because, in my experience, they're not independent. There are, of course, plenty of exceptions, but those characteristics tend to go hand-in-hand.

It's also often the case that what superficially looks like "ugly reliable code" actually means code that was, at one point, very simple and tidy but has been battle-hardened by years of maintenance. It's ugly because code that implements a lot of complexity tends to look scary as hell.

Finally, it's ultimately a truism: truly unreadable code is also code that's hard to modify, and very few systems will go through their lifetime without changes. Even if it works fine today, it'll not meet business requirements tomorrow, and its unmaintainability is a liability.

It's on this list as "does well what is intended to do". In fact the article specifically discusses the fact that people, when surveyed, did not mention "it works" as a priority:

Works: writing code should always have one purpose, deliver some value to somebody. Writing code that works, that it’s actually deployed somewhere making somebody happy is one of our top priorities. So we were kind of surprised every time a developer didn't include that item in the answer.

I guess it depends on the work the code is supposed to do. There's the proximate business problem for which the code provides an answer and then there are all the other business problems which a piece of code might create despite solving the proximate business problem.

There's a business case for optimizing on each...and one for everything in between.

I think your point goes without saying, code that actually works is the first thing.

But a dimension you've missed... Code that works but isn't readable, testable, maintainable, will end up costing your business dearly. It's a nightmare for any developer working on any task - finding a bug, iterating, new feature, whatever - to have to work with a shitty code base. You could quantify the losses in $ stemming from having to work with shitty code... not only that but you'll have a lot more trouble finding technical help (I'm not alone that I'll ask in an interview "What's your technical debt like?", if the answer is bad, that's probably the end of the interview.)

Reply on news.ycombinator.com