Hacker News Reader

Comment by kjgkjhfkjf | Hacker News Reader

Software doesn't live forever. Good enough and soon enough is enough.

For years I've been mystified how certain people who make bad software engineering decisions over and over --but do so quickly and with commitment-- rise up in the leadership ranks. I'm talking about people who join projects like a hurricane, don't pull in all the relevant data before making a technical call, and their work /always/ has to be replaced or cleaned up 6 months later.

I finally realized that there's usually not a "perfect" engineering solution, and you can spend weeks or months going back and forth on a plan. So the people that just plow ahead --even if not great-- wind up delivering "something", which is better than nothing. And put another way, they land 2 failures and one moderate success in the same amount of time the rest of us are busy landing our one single success... which also winds up being only a moderate success at best because writing good software systems is hard!

Look up "satisficing". It's a wonderful concept.

Sometimes even a wrong decision is better than no decision, and that is so antithetical to how I want things to be it took a lot of pain events to beat that through my skull. But it is true nonetheless.

Often the decisions aren't wrong, but they are sub-optimal decisions. That's what I've found at least.

Sub optimal can move the needle and that's what a lot of people are looking for.

There the tragedy of the commons. You see it in software, where individual teams or people can make decisions that seem overall correct for them but have an overall negative result overall. I've seen this when you have shared components that require core platform updates. One group working for one customer needs a new features without considering the other customer that uses the same platform or may want the same feature but with a slightly different configuration or interface. It adds to technical debt and reduces overall productivity in the long run.

You see this in open source projects too where code gets forked and then it becomes difficult to adopt features from mainline or the other forks etc...

I find that to be almost entirely untrue. I am far more amazed by how long things I have written stay around. Websites I helped create in 2005, integrations that just hummed along without anyone paying attention to them for over 10 years, and tiny utility desktop apps that people just keep using 'cause they do the job. I've definitely decided that I'd better put some spit and polish on things because it almost certainly is going to last longer than I expect.

There's a really big power law for this though. Some of my code has been running for close to 15 years now and I fully expect it to run at least that long into the future. At the same time I also have written software that got decommissioned after a year because the business division was spun down.

The highest value code I ever wrote was probably a 50-100 line script that collected some data requested for due diligence and which eventually clinched a >200 million USD investment round for the company. That script was never used again after that.

Hah. Same experience here. When I get asked at interviews "what is your recent work you are most proud of?" and I can't bring myself to cite my Elixir or Rust work (even if I did some pretty solid work there in the last years) and the first thing that immediately springs to mind is how I actually invested two days in a shell script that did a job (making PDF invoices in a system that wasn't meant for that but the data was in the DB) that the management thought is going to take 3 months.

Since then I changed my LinkedIn headline to: "Solving problems with technology".

That's what people care about. Not which language we use.

Probably depends on where you work? I've worked in startups for most of my career (15 years) and I find the GP's comment more true. 2 companies I've worked for no longer exist (including my own startup), and 1 company I worked for turned into a unicorn -- I left that co 7 years ago and I'm fairly certain none of the code I wrote during my 6 years of work there is still operating anymore now.

With experience, you realize that minimum effort in the key places that bring maximum result is the name of the game.

Obviously "minimum" differs from situation to situation. Just enough effort, but not more than needed, but not too little either.

which is fine if there's not competition (e.g. internal software).

Add competition to the mix and "good enough" might put you in the ground.

Interactions are more than just about the software. It what separates Disney parks from Six Flags.

Reply on news.ycombinator.com