Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How terrible code gets written by sane people

chrismm.com

Post reply on HN
Print view View original

51–60 of 151 posts

Re: How terrible code gets written by sane people

#51

Post by dahart »

It feels like people are focusing on bad conditions and unreasonable deadlines, and not the idea that in the real world smart people under execellent conditions do this very, very frequently.

I've worked for long periods of time in 3 codebases that were over 2 million loc in my career, all had great conditions, all had very smart people. Those are not huge codebases by any standard, and yet all 3 had people talking about ground up rewrites. All 3 had people complaining about every single example the author used. Two of them undertook the ground up rewrite estimating one year. Both admitted to having made a huge mistake 3-5 years later.

My theory is that all software eventually becomes difficult to maintain and full of warts, regardless of smartness, regardless of conditions. We all have code ideals we believe and talk about that don't work as well in the real world as we imagined. We all have deadlines that are shorter than we want -- it's a universal constant. We all imagine we can write code and fix big problems faster than we really can. And we all fail to fully understand what's working right in a messy large codebase and tend to focus on what's wrong.

I don't know how to fix this, but it's very possible the author ran into thoughtful paradigms he just hadn't seen before and didn't fully understand. Some styles seem messy if you haven't seen them before.

React is an intentional lack of separation of concerns between code and markup. Some projects are required to mix tabs and spaces depending on tools. For that matter, bash scripts alone require mixing tabs and spaces for some features. And so on, it's important to have context for why things are the way they are before jumping to the conclusion that it's bad.

Re: How terrible code gets written by sane people

#52

Post by Clubber »

devonkim wrote: post #41
Clubber wrote: post #28

Earlier quoted context omitted.

It appears that way short term, but long term, having a bad codebase can retard a company's growth through lack of scalability and maintainability (read easily add/remove/change features). Companies spend a hell of a lot of money for growth. If they don't know how to manage software development, then the software will nullify all that cost spend on growing, because the system can't handle it. I am truly amazed at how…

What I've learned is that most companies that are really not in it for the long haul and just want to exit will pass the technical debt off to a much larger company that can supposedly shoulder the burdens of technical debt. The M&A process at large companies really don't look at how sustainable the codebase or infrastructure is - they only look at regulatory liabilities like super bad security practices and that's o…

Thanks, that was an insightful reply. It's like when the banks pushed off mortgage risk to the public market before the great recession. Companies accrue massive technical debt (risk), but push it on the buying company who either isn't competent enough to DD the software, or simply doesn't care. In the end, someone has to pay for that negligence, but it's like playing hot potato or musical chairs.

Re: How terrible code gets written by sane people

#53

Post by 102938010 »

erikb wrote: post #38

Honestly, I think the best developers are not the ones that write beautiful code and put quality above everything else. The best ones are the ones that can push out a solution given too little time and given a (maybe self inflicted) bad code base. Because that's real life, and not the pony farm. Money trumps everything else in capitalism. Getting money means paying your bills today. And even more so than skill, quali…

> The best ones are the ones that can push out a solution given too little time and given a (maybe self inflicted) bad code base.

If every open source project was developed by those principles, all high and mighty web companies would collapse.

Good work is being done, but it's for free.

EDIT: You're right of course about the reality in the parasitic companies.

Re: How terrible code gets written by sane people

#54

Post by JustSomeNobody »

doggydogs94 wrote: post #49

The key word is "deadline". Horrible code that works beats beautiful code that has not been thoroughly tested.

Along those same thoughts, you put many developers in a room and they end up converging on "the one true architecture" and nothing ever ships but you have this monstrosity with some very beautiful code in it. Put few developers in a room and you get decent code and a solution to the problem that actually ships.

Re: How terrible code gets written by sane people

#55

Post by JustSomeNobody »

arcanus wrote: post #4

All good examples (such as excessive importance to deadlines, a big no-no). My question: can they be truly good programmers of they write bad code? Isn't the essential product of a programmer SLOC and functionality via software? And if they do that in a manner inferior to another dev, isn't that objectively a measure of inferiority in their craft? I've met far too many 'good' programmers who were a net detriment to a…

Even good developers have to initially poke at a problem to get it in their head. Once there, then they can write beautiful code to solve it. Therefore, if time is constrained, even good developers will have to ship ugly (but working) code.

Re: How terrible code gets written by sane people

#56

Post by SatvikBeri »

One thing I've been thinking about more and more is code that's easy to delete.

For example, we recently built a data pipeline that did a bunch of processing and wrote data to a SQL database at the end. For various reasons, there was an unscalable, quick way to implement the write, and a scalable, slow way to do it. We wanted to get the product to testing ASAP, so we chose the quick way initially.

In order to make sure that we could easily replace that code, we ended up creating a separate write function for each table, where the function did nothing else except the write. That involved a lot of duplication, but made it easy to move the tables over to a better method one by one later.

It seems like having functions with one purpose, pure if possible, is a pretty good way to ensure "upgradeable" code–even if the internals of the function are messy, you just have to write a new one that copies the same functionality. Furthermore, I've found single responsibility functions to be easier to enforce in code reviews than single responsibility classes.

Re: How terrible code gets written by sane people

#58

Post by dasil003 »

erikb wrote: post #38

Honestly, I think the best developers are not the ones that write beautiful code and put quality above everything else. The best ones are the ones that can push out a solution given too little time and given a (maybe self inflicted) bad code base. Because that's real life, and not the pony farm. Money trumps everything else in capitalism. Getting money means paying your bills today. And even more so than skill, quali…

I mostly agree with your top line. Code "beauty" and "quality" are not objective measures, and there are plenty of devs out there who are obsessed with their own interpretation of those ideals to the point that it inhibits their ability to ship.

However there is an existential danger for management to embrace this philosophy. The problem is the incentives are already naturally aligned to ship today, and problems discovered tomorrow are likely to fall on the shoulders of someone other than the original author. If there is no institutional value towards maintainability, then the code base will get worse and worse until it grows beyond the cognitive ability of anyone to ship anything without negative ROI. By the time that happens the cost to fix may be more than the company can afford.

Re: How terrible code gets written by sane people

#59

Post by busterarm »

JamesBarney wrote: post #40

I like the article but I found the implied solution a little humorous. Just hire devs who are great coders, great communicators, stubborn enough to push back against upper management, good hearted enough to sacrificed their own KPIs to focus on the success of their project, and massochistic enough to stick it out at an obviously poorly run project. Good luck Side note, for 15 years of experience the project doesn't s…

> Just hire devs who are great coders, great communicators, stubborn enough to push back against upper management, good hearted enough to sacrificed their own KPIs to focus on the success of their project, and masochistic enough to stick it out at an obviously poorly run project.

This is a pretty close description of the positions I find myself in as a dev and I don't think this combination of qualities makes me more hirable.

Re: How terrible code gets written by sane people

#60

Post by SatvikBeri »

dahart wrote: post #51

It feels like people are focusing on bad conditions and unreasonable deadlines, and not the idea that in the real world smart people under execellent conditions do this very, very frequently. I've worked for long periods of time in 3 codebases that were over 2 million loc in my career, all had great conditions, all had very smart people. Those are not huge codebases by any standard, and yet all 3 had people talking a…

> My theory is that all software eventually becomes difficult to maintain and full of warts, regardless of smartness, regardless of conditions.

I agree. I think there's a lot of emphasis on preventing bad code from existing. But if you believe some bad code is inevitable, then it's more important to make it easy to fix when it happens.

By default, good code tends to be modular and easy to replace, while bad code is excessively coupled and hard to get rid of. So bad code has a disproportionate impact on long-lived codebases.

I wonder if one way around this is to force modularity, even when it's unnatural. Functional programming seems to be one way of doing this, microservices are another. A related principle would be not to take DRY too seriously, favoring decoupling over deduplication.

Post reply on HN