21–30 of 511 posts
But the main argument is off - What some classify as imaginary problems is actually building in the wrong types of affordances. The only way to know the difference is by knowing your tools and the problem domain.
The root of bad software is leaders lacking practiced learning.
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…
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.
There's always going to be a minimum level of complexity. Sometimes that minimal level calls for throwing a PHP script up on some shared hosting provider somewhere. Sometimes that minimal level calls for an Enterprise-level design with ten layers of abstraction because you need to be able to individually unit test every aspect.
Being aware of where and when to introduce complexity is half the battle.
Replace those devs with ones who are focused on the right things? Great, but you still have the other problems to deal with (scope creep, uninformed clients), not to mention a host of other things that can derail a project, such as poor communication.
tl;dr Most projects are poorly managed. Poorly managed projects tend to fail.
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.
Maybe optimal performance is a feature? Feature worth working on from start?
This mentality is often taken way too far. I had an old boss who wouldn’t allow me to write unit tests citing this thought process.
Even at places with decent engineering practices, I’ve seen so many examples of software where you’re limited to a one to many relationship for something that could and easily should have been implemented as many to many, rendering the product useless to many because a product person couldn’t stand to think a couple months ahead.
Some people seem to take this idea too far and basically assume that if a problem is interesting or takes away a tedious task, it must be overengineering, premature optimization, or an imaginary problem.
Perhaps a better way to phrase the issue would be “artificial constraints”, which would encompass the flip side too.
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 ou…
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.
I don't know anything about banking software, but I have a hunch the author underestimates the complexity (as is typical for HN). The Efficient Markets Hypothesis would suggest that if it were so simple to make banking software, then someone would do it.