Hacker News Reader

Comment by rkwz | Hacker News Reader

We can adapt the Gresham’s Law for Software Development:

Project [A] is built within "x" months with lot of tech debt, crunch time and stressed out employees

Project [B] is built within "x+y" months with sane architecture and healthy working hours

If management doesn't understand the benefits of good architecture and employee well being, [A] will become the baseline against which all future projects get measured.

The software system gets messier and messier => resulting in more bugs => resulting in working weekends and late nights => employees make poor decisions because of mental fatigue => resulting in more bugs => ...

View on HN

I think you're dead right but it goes even deeper. With more bugs the company starts evaluating devs on their ability to fix bugs and put out fires. Eventually the devs who can build a sane product are squeezed out and all the devs are good at is fixing bugs rather than introducing fewer bugs in the first place.

I noticed this when working as a dev in the finance industry. The devs who put out the most fires got the biggest bonuses and float to the top so they have a say in hiring and hire more people like themselves. A textbook case of Gresham's Law.

Or basic Darwinism, which says that the fittest for their niche survive and reproduce. Fittest is relative to current circumstances, so each generation can modify the niche that others find themselves in.

Was at a job once where a dev shipped a bug on a Friday, spent the weekend fixing it, then got a bonus for it because he worked hard over the weekend and "got it done".

but why does the effect only happen in software engineering, but not physical engineering?

You don't see buildings that are near collapse and require constant repair and redesign. You don't see construction contracts awarded to companies that build poor buildings. In fact, most buildings work fine, and even tho most also have some defects, those defects tend to be minor and can often be overlooked.

So what makes software engineering different?

Software engineering isn't special in this regard. It happens in a lot of other domains. Software often doesn't have a lot of the constraints of other disciplines so effects like these are more pronounced.

I would characterize all the statements you made as false. Though it does depend on what your standards are.

Most of the critical things are done well enough, but that is a pretty low bar.

My guess is a lower barrier to entry and lack of enforced building standards.

You don't see buildings that are near collapse and require constant repair and redesign.

When the covid thing is over, have a trip to Sydney Australia. There;s lots of cheaply done buildings here in all states of disrepair. People cheap out on the invisible stuff like correct wiring, correct plumbing and correct foundations.

And in software people cheap out on those same things because they can take the money and run.

You could fix this by making payment for software as 25% upfront with 20% on deliver and then 50% on 18 months of as advertised use.

But no one would ever do that. When Azzure or GC or AWS goes down every 5 years or so for a few hours, everyone gets server credits back for teh interruption and revenue loss. No liability as assumed.

You can add Canberra to that list. I know several apartment blocks that are close to collapse, one Owners' Corporation is currently suing the builder (and the local government authority) in a case before the Supreme Court.

The rest of engineering isn't immune to this, but it's most prevalent in software because of it being soft. Just about everything you can imagine can be done.

This tends to pile requirements on, and you end up in a bad place.

You don't often get "I want a building just like that one" becoming "except make it out of glass", then "actually add a floor or two".

But I've come across exactly this in software. Someone I know asked a friend to make a copy of a well known auction site. Then he had to change the whole backend and add a load of features. Needless to say, it ended badly.

False premise. Building failures occur all the time.

By relative frequency, not so often: physical structures are simpler, tangible, better understood.

But they still fail often.

https://youtube.com/results?search_query=building+collapse

https://youtube.com/watch?v=d8u83VY59Ww

https://youtube.com/watch?v=5PZyXvp1mLw

In 1st-world countries as well:

https://youtube.com/watch?v=dfYLk9dktAY

https://youtube.com/watch?v=EMpQxLfqNNs

https://youtube.com/watch?v=VnvGwFegbC8

that's one way to look at it, but it's rarely this clear cut. usually the system is initially built from P1+P2+P3+...PN that are wired together in a somewhat sane manner and do the job.

enter joe, that thinks P2 is over-engineered and thinks he can do a a better job without understanding why P2 is the way it is or why it was even built like this.

joe proceeds to replace P2 with P2'+P2a+P2b that kind-of get the job done but make the system a little bit more complicated. Joe gets a promotion for being a doer and improving "complicated shit".

Now, imagine armies of Joes picking up the least complicated part of the system and making their contribution. The initially sane and straightforward components get replaced with increasingly more complicated ones.

In the end, everything is so complex that no progress can be made.

Microservices

https://www.youtube.com/watch?v=y8OnoxKotPQ

That channel is legit underrated

Technical debt, risk, maintainability, and long-term resilience are all elements that don't get fully accounted for.

This joins a few related concepts: "manifestation" (or: cognizability, perceptibility, tangibility), risk (effectively a measure of probabalistic fiture cost), and resilience, which often contrasts strongly with efficiency.

Sociologist Robert K. Merton pioneered many. of the concepts around manifest vs. covert functions, usually of social institutions or behaviours.

This rather sounds like short term vs. long term decision making, or accumulating debt. What are the "coins" of Greshams's law in your example?

Short-term consequences (positive or negative) are far mor cognizable than long-term, both to individuals and organisations. Cognizability is, then, the market for exchange and evaluation.

Options with short-term benefit but long-term harm, are excessively adopted.

Options with short-term harm or cost, but long-term benefit, are excessively rejected.

Put another way, markets consistently under-rate risks, and more complex ones to a greater extent. But they also under-value long-term. positive benefits. Markets operate in the now.

Related is Robert K. Merton's work in manifest vs. latent functions, from sociology.

We might also consider that if x is larger than a few weeks y might well be negative.....

Reply on news.ycombinator.com