Comment by AceJohnny2 | Hacker News Reader

Comment by AceJohnny2 | Hacker News Reader

These are great examples, and they hint to, but do not mention, the big counterpoint: development time. In his own examples, the author admitted that though the code was ugly, it worked. He then spent extra time reworking the existing code to make it, well, prettier.

"If I had more time, I would have written a shorter letter." -- Voltaire

The problem is that, in many (most?) professional settings, the developer is under huge pressure to get shit done. Not get it done perfectly, not done beautifully, but just done in the first place. We rarely have the leeway to spend extra time refining existing code, existing features or bugfixes, to make them prettier. It's gotta be done, and it's gotta be done yesterday because maybe some other part of the project is blocked because of it or some customer paid for it and it was supposed to be done last month or it broke and why the hell isn't it fixed yet!?

Some projects, I daresay mostly open-source projects, can afford to be detached from the pressure of deadlines that corporations require, and reject code that isn't to their quality standards. Sadly, that's not the case for most of us.

I think you are overlooking a number of things, first of all the code examples are not just prettier they are faster as they bypass test conditions. Save possible compiler optimization or CPU branching strategies which I am not too familiar with, this would at least still save execution cycles in certain cases/languages. Might seem small here, but when it's for library code, code that gets duplicated in memory and needs to also copy variables and closures (i.e. rows on a webpage), or simply a practice all across the codebase, it will have effect.

Not only that, but as the author outlined it's easier to read and parse for another developer, and there are less chances for errors.

I, for one, strongly believe that pushing software excellence reduce the number of high pressure situation to "get shit done", as it's better to take control of the code than other way around.

Apart from trivial or throwaway projects, code is read many more times than it is written. Spending time reworking some code to make it easier to read will pay off over the long term.

(There's the question of whether making code more compact but more "clever" truly makes it easier to read, but that's a separate point.)

But how much of that deadline pressure arises from mounting technical debt due to skimping on code quality?

This demonstrates the general move in the marketplace from companies developing software, to instead hacking out quick product for fast money.

The startup mentality has made this worse, and continues to do so.

Good software requires thought and time to get right. Unfortunately, those people buying software are often willing to pay for low-quality hacks these days, in the name of a quick fix.

It's just another commodity now, and as such, like many other products, more about cost than quality.

> This demonstrates the general move in the marketplace from companies developing software, to instead hacking out quick product for fast money.

I can attest that there never were "good ole days" of software development. There never was "take all the time you want, do it right". There were always schedules, commitments, and budgets.

>Some projects, I daresay mostly open-source projects, can afford to be detached from the pressure of deadlines that corporations require

That's partly why open source has staying power and so many corporate projects get junked.

Absolutely.

They are taking development time into consideration, development time in the long term.

It is certainly true, if there is absolutely no time to clean up, there is nothing to do be done about it.

However I think there are too points to consider here.

First, cleaning up code is a skill and as such it improves with practice. That is the more you get used to fixing code quality the faster you are at it and the easier it is to include it under time pressure. If you are never given the opportunity to do it, there is no chance to become more efficient at it and there will never be enough time to do it inefficiently. (The above is IMHO even more true about testing.)

Second, it is the favorite excuse of the lazy programmer. "Pragmatism", etc. From the outside it's hard to distinguish between lacking time and lacking willingness.

"If I had more time, I would have written a shorter letter." -- Voltaire

You're quoting Pascal, not Voltaire ;)

"The worst thing about the internet is how quotes are always misattributed." - Albert Einstein

Zut!

While the improvement might or might not be worth the cost of figuring it out for this case in isolation, note that a more experienced programmer would write the final better version first, without even considering looping over the whole 2d array. How do you learn to do that? By revising your code!

If you never get to learn better, you're letting your management force you to retard your own development. Unless you're a temp it's probably even costing your employer more than it gains. Of course, there's a balance between learning and firefighting. Just don't put the fulcrum all the way over on the left edge.

It may be quicker for the original developer to throw together some awkward but working code -- the real expense comes from the time spent by subsequent devs having to read and understand it.

Reply on news.ycombinator.com