Live data from Hacker News

Imaginary problems are the root of bad software

cerebralab.com

11–20 of 511 posts

Re: Imaginary problems are the root of bad software

#11
post #3

The author hits the nail on the head with his claim that imaginary problems are more fun than real ones. As developers and smart folks in general, we like complicated problems that are big and far away. How many times have I heard in a meeting, "Yeah, but when we have 1M users..." It's great fun to think your product will get to 1M users. It's also very unlikely. It's not nearly as fun to finish and ship and market a…

Reminds me of a PM I used to work with. "Will this work for 1000 simultaneous users?" After almost 2 months, we have less than 100 users total, maybe 5 of them log in a day, and maybe 1 will actually do anything of interest.

There is no technical problem. The problem is nobody worked on actually marketing the product. Build it and nobody shows up is the norm.

Re: Imaginary problems are the root of bad software

#12
post #6

Premature optimization is the root of all evil. Simple > Complex. It's amazing how many otherwise brilliant people dive headlong into project without considering these basic principals or even intentionally brush them aside.

I believe Saying simple > complex doesn’t actually mean anything because it’s effectively impossible to pin down definitions. They are totally in the eye of the beholder. Solutions that are simple in one axis almost always trade of complexity in other axes.

Re: Imaginary problems are the root of bad software

#13
Great advice, spot on

At work we have this terrible “Enterprise Architecture” team comprising of highly paid people who haven’t written a single line of code and who don’t know the intricacies of our business but keep proposing complicated “Event Driven Architectures” and “Micro this and Micro that” and just reciting the latest buzz words just to keep appearing cool.

It’s insane how much total cost they add to the organization, both directly and indirectly.

Re: Imaginary problems are the root of bad software

#14
Sort of related, but this is one reason I moved into “Frontend“ about 10 years ago. I started seeing over and over that when our (SaaS) projects didn’t start from what the customer sees, teams usually got distracted with imaginary or hypothetical design issues. It was a lot more effective to iterate from the visible features, and then let that drive much of the backend design, APIs, development timeline, etc.

This meant I needed to deal with more JavaScript than I originally intended with my career, and eyerolls from backend architect types, but projects go much smoother than in my past, that's for sure.

Re: Imaginary problems are the root of bad software

#15
post #4

The hard part here is telling the difference between a pure phantasm of an imaginary problem and innovation. Things that have never been done (or never really been done well) might look as far off as hypotheticals. I do think that “imaginary problem” is the answer most of the time though. Most things that look like unnecessary complexity or hobby horses really are.

And here am I struggling not to solve memory leaks or improve up the build time of or speed of our app because I am stuck implementing the most boring of the features already digested by a team of businesses analyst and a design team.

Sometimes boring is just pure torture.

Re: Imaginary problems are the root of bad software

#16

Great advice, spot on At work we have this terrible “Enterprise Architecture” team comprising of highly paid people who haven’t written a single line of code and who don’t know the intricacies of our business but keep proposing complicated “Event Driven Architectures” and “Micro this and Micro that” and just reciting the latest buzz words just to keep appearing cool. It’s insane how much total cost they add to the or…

I always find it bizarre how people like this can operate. After almost 20 years of software development, I've considered seeking some kind of an architect role, but I cannot, for the life of me, imagine operating as one without working closely and collaboratively with the development team on a solution, rather than just dictating how things should be done "from on high". But that may just be a personality thing, I don't know.

Re: Imaginary problems are the root of bad software

#17
I know it’s just an arbitrary number picked but this bit jumped out at me:

“You’ve just wasted $15,000 on two months work with a team of contractors”

The project may also have been doomed because $15k is not very much for something like they described.

But again, fully aware that they probably picked a random number. I’d have just added another zero to make it more realistic.

Re: Imaginary problems are the root of bad software

#18
post #3

The author hits the nail on the head with his claim that imaginary problems are more fun than real ones. As developers and smart folks in general, we like complicated problems that are big and far away. How many times have I heard in a meeting, "Yeah, but when we have 1M users..." It's great fun to think your product will get to 1M users. It's also very unlikely. It's not nearly as fun to finish and ship and market a…

And people underestimate how well some solid, dumb solutions can scale. Boring spring boot with a decent data model and a bit effort to stay stateless scales to the moon. Or, we're having a grand "data export" system customers use to collect data from us for their own DWHs. It has survived 2 attempts at replacement so far. At it's core, it's psql + rsync, or was recently migrated to psql + s3 when we decomissioned our FTP servers. And it's easy to extend and customers are happy because it integrates well.

Re: Imaginary problems are the root of bad software

#19
post #12
post #6

Premature optimization is the root of all evil. Simple > Complex. It's amazing how many otherwise brilliant people dive headlong into project without considering these basic principals or even intentionally brush them aside.

I believe Saying simple > complex doesn’t actually mean anything because it’s effectively impossible to pin down definitions. They are totally in the eye of the beholder. Solutions that are simple in one axis almost always trade of complexity in other axes.

As a good illustration, consider FEniCS[1], where you can write a few lines of Python code which looks almost exactly like the math you're trying to solve, and have it compute the answer. Very simple!

Except to make that work there's a lot of infrastructure, including runtime-generated-and-compiled C++ code that gets dynamically loaded by said Python code to perform the actual calculations. Quite complex!

The true skill comes in finding the right balance between simplicity and complexity for a given situation.

In the case of FEniCS, the complexity is worth it because it allows the system to be used by less skilled programmers (who might know more about the math and physics), and the complexity handled by experienced programmers.

For our codebase we've got junior programmers who might need to read and understand my code if I'm on vacation and shit hits the fan, so I err on the side of making it easy to read and reason about. Which might not be the "simplest" for some measures of simplicity (like fewer lines of code).

[1]: https://fenicsproject.org/

Re: Imaginary problems are the root of bad software

#20
This resonates and one way to describe it is an incentive problem. Someone whose incentives are tightly aligned with the business is going to solve the actual problem and simply and effectively as possible. Someone who is incentivized to build career capital and experience other than via impact (e.g. so they can get uplevelled, pass an external interview loop, etc) is much more likely to focus on unimportant hard problems and/or over engineer.
Post reply on HN