←back to thread

1455 points nromiun | 6 comments | | HN request time: 1.366s | source | bottom
Show context
Buttons840 ◴[] No.45074873[source]
I'm probably one of the "smart developers" with quirks. I try to build abstractions.

I'm both bothered and intrigued by the industry returning to, what I call, "pile-of-if-statements architecture". It's really easy to think it's simple, and it's really easy to think you understand, and it's really easy to close your assigned Jira tickets; so I understand why people like it.

People get assigned a task, they look around and find a few places they think are related, then add some if-statements to the pile. Then they test; if the tests fail they add a few more if-statements. Eventually they send it to QA; if QA finds a problem, another quick if-statement will solve the problem. It's released to production, and it works for a high enough percentage of cases that the failure cases don't come to your attention. There's approximately 0% chance the code is actually correct. You just add if-statements until you asymptotically approach correctness. If you accidentally leak the personal data of millions of people, you wont be held responsible, and the cognitive load is always low.

But the thing is... I'm not sure there's a better alternative.

You can create a fancy abstraction and use a fancy architecture, but I'm not sure this actually increases the odds of the code being correct.

Especially in corporate environments--you cannot build a beautiful abstraction in most corporate environments because the owners of the business logic do not treat the business logic with enough care.

"A single order ships to a single address, keep it simple, build it, oh actually, a salesman promised a big customer, so now we need to make it so a single order can ship to multiple addresses"--you've heard something like this before, haven't you?

You can't build careful bug-free abstractions in corporate environments.

So, is pile-of-if-statements the best we can do for business software?

replies(23): >>45074916 #>>45074936 #>>45074945 #>>45075059 #>>45075089 #>>45075095 #>>45075106 #>>45075135 #>>45075188 #>>45075195 #>>45075392 #>>45075443 #>>45075463 #>>45075515 #>>45075547 #>>45075846 #>>45076426 #>>45077189 #>>45077500 #>>45077548 #>>45078893 #>>45079553 #>>45080494 #
1. atomicnumber3 ◴[] No.45075188[source]
"the owners of the business logic do not treat the business logic with enough care."

Certainly, there are such people who simply don't care.

However I would also say that corporations categorically create an environment where you are unable to care - consider how short software engineer tenures are! Any even somewhat stable business will likely have had 3+ generations of owner by the time you get to them. Owner 1 is the guy who wrote 80% of the code in the early days, fast and loose, and got the company to make payroll. Owner 2 was the lead of a team set up to own that service plus 8 others. Owner 3 was a lead of a sub-team that split off from that team and owns that service plus 1 other related service.

Each of these people will have different styles - owner 1 hated polymorphism and everything is component-based, owner 2 wrapped all existing logic into a state machine, owner 3 realized both were leaky abstractions and difficult to work with, so they tried to bring some semblance of a sustainable path forward to the system, but were busy with feature work. And owner 3 did not get any Handoff from person 2 because person 2 ragequit the second enough of their equity vested. And now there's you. You started about 9 months ago and know some of the jargon and where some bodies are buried. You're accountable for some amount of business impact, and generally can't just go rewrite stuff. You also have 6 other people on call for this service with you who have varying levels of familiarity with the current code. You have 2.25 years left. Good luck.

Meanwhile I've seen codebases owned by the same 2 people for over 10 years. It's night and day.

replies(2): >>45075228 #>>45075550 #
2. eastbound ◴[] No.45075228[source]
> consider how short software engineer tenures are!

Employees aren’t fired. They leave for a 10% increase. Employees are the ones who seek always more in a short-termist way.

replies(2): >>45075329 #>>45075344 #
3. martin-t ◴[] No.45075329[source]
It would be short-termist if they had actual gains from their work other that salary. They don't.

They are acting rationally given companies don't seem to value long term expertise.

Now, if it was a worker- owned cooperative, that would be a different thing.

4. kibwen ◴[] No.45075344[source]
At the same time, the reason that employees leave on such a regular cadence is precisely because the companies they work for refuse to give them the salary increase that they could get by going elsewhere. Companies could solve this by giving commensurate raises.
replies(1): >>45077870 #
5. Buttons840 ◴[] No.45075550[source]
What you say is true, but I meant the product owners are the one who don't fully weigh the cost of their decisions.

I once tried to explain to a product owner that we should be careful to document what assumptions are being made in the code, and make sure the company was okay committing to those assumptions. Things like "a single order ships to a single address" are early assumptions that can get baked into the system and can be really hard to change later, so the company should take care and make sure the assumptions the programmers are baking into the system are assumptions the company is willing to commit to.

Anyway, I tried to explain all this to the product owner, and their response was "don't assume anything". Brillant decisions like that are why they earned the big bucks.

6. whstl ◴[] No.45077870{3}[source]
They would rather give a 10% increase to the guy replacing you.