Crucial to fight against this kind of stuff.
Imaginary problems are the root of bad software
41–50 of 511 posts
Re: Imaginary problems are the root of bad software
#42Bad languages and tooling is the root of bad software.
Re: Imaginary problems are the root of bad software
#43I 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.
In our agency 10 years ago we build such websites, it would cost 3000-5000 dollars max. Just with PHP and a simple self build CMS. Including a simple responsive design. We also hosted around 250 of such websites on a single dedicated server. It was very very fast.
Re: Imaginary problems are the root of bad software
#44Earlier quoted context omitted.
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…
Yep. Facebook got pretty far down the road with PHP, MySQL, memcached, etc.
Re: Imaginary problems are the root of bad software
#45The author is right, but doesn't seem to mention that this could be solved, at least in theory, with better project management. Devs focusing on the wrong thing? Project manager should be on it. Scope creep? Project manager should be on it. Client asking for irrelevant features? Project manager should be on it. Replace those devs with ones who are focused on the right things? Great, but you still have the other probl…
Re: Imaginary problems are the root of bad software
#46Great 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 d…
This still results in a lot of compromises and problems. Anyhow they should be there talking to the developers in a 2-way fashion so that then end result is not entirely "from on high".
Re: Imaginary problems are the root of bad software
#47Re: Imaginary problems are the root of bad software
#48The 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…
Reddit has 1M users and is half-broken, yet monetization is still a problem.
https://thehill.com/business/despite-widespread-protest-redd...
https://en.wikipedia.org/wiki/Reddit
https://backlinko.com/reddit-users
Re: Imaginary problems are the root of bad software
#49Need a bog standard app to stream audio files? Give it to the person you hired right out of college, or maybe even the summer intern. She's never built something like this before, so to her it will be a challenging novel problem. A (somewhat) more experienced developer may need to provide initial guidance and review code, but that's a comparatively minor time investment, and besides, the act of mentoring someone else should keep it interesting.