Comment by ams6110 | Hacker News Reader

Comment by ams6110 | Hacker News Reader

Parent Full thread

Yes, it can be, but that has not been the only reason in my experience. Smart developers can see the abstractions and organize their code accordingly.

Mediocre/poor developers just think about what needs to get done. They will copy code that seems to do something similar and hack on it until it works.

I saw this a lot with asp pages back in the day. An entire application, that actually worked and was well liked by its users, was implemented as hundreds of totally stand-alone .asp files. When a new page was needed, the developer copied an old one and modified it. That made it pretty easy to add new features without breaking old ones, but made it very difficult to make cross-cutting changes such as changing the name or type of a field on multiple pages, changing page headers, changing database connections (yes, they were also duplicated in every file) etc.

This is also how you end up with a "20k line VB.Net disaster." They are created by developers who know just enough to make something work, but don't know about abstraction and modularization or aren't smart enough or experienced enough to see the abstractions and to keep track of what's going on when the code is split out over a dozen files or modules. Or possibly, just don't care.

Abstraction isn't free, either. The more you build, the more you're gambling that it abstracts over all future requirements.

When you're eventually wrong, someone must pay the incredibly expensive price of deabstraction. Which can become so untenable that it makes more sense to escape-latch out of it for a new business requirement. If you disagree, then shrink the deadline until you do.

What happens with technical debt is that every new/changed feature incurs disproportional costs. And all costs, at the end of the day, boil down into time. Even the best developer has the same finite resource of time as everyone else, and they are stuck choosing between the best of suboptimal solutions once bounded by deadlines.

This is why, when encountering a mess of a codebase, it's naive to conclude "wow, what a bunch of amateurs." And that's exactly what I thought at my first job out of university. Eventually I realized that software is just hard and there is never enough time. The more experienced you get, the better you are at writing code that can be changed or thrown away. But you're still only minimizing the bad, not eliminating the bad, so on a long enough time scale with enough monkey wrenches of time constraints and requirement churn, technical debt is inevitable.

Absolutely, you can go too far; sometimes the "naive" approach is the best.

While there are lots of examples out in the wild of people making a mess of things due to lack of experience, hastiness, and not thinking long term, there is a two way street there. Experienced developers sometimes apply too many rules and too rigidly to deliver elegant, well-performing, timely solutions. I see people abstracting and decoupling things, applying highly generalized pessimistic patterns, bickering about how to name things that probably shouldn't even exist, let alone have explicit names.

Experience is obviously good but people tend to get inflexible and dogmatic, too.

Perhaps a lot of bad code comes from strict time requirements, loose specs, and employee churn. Your customers and your manager/supervisor couldn’t care less about how neat your code is, so I understand the logic to push out something that works ASAP. I personally try my best to write clean code, but I don’t call other developers ‘stupid’ given the reality of ridiculous timelines and low job security.

I agree with you but would just add one more nuance: there's a critical minimum of "so-so-okay-ish code" that we should never go below of. The problem with untouchable huge turd piles is borne out of going below that bar.

I totally get the low job security and low payment and the "I don't care" parts and have written bad code because of all of those. Still, if you put even a minimal effort, it pays off.

Reply on news.ycombinator.com