36 ms·

Imaginary problems are the root of bad software

• simplicity34 3y ago
  [flagged]
• binnaclegrade 3y ago
  [flagged]
• socketestimate 3y ago
  [dead]
• ebaycheck 3y ago
  [dead]
• mlhpdx 3y ago
  > They might realize Debra has been sitting in that corner, staring at uptime graphs of the internal server farm for 10 years, despite the fact that the company moved to AWS five years ago. Ouch. The tone of the article is a little harsh, and I’m not sure if snippets like the above are intentionally hyperbolic, but there is a fair amount of truth in it. Most of my career has involved convincing peers to do less, and solve simpler problems with simpler solutions.
• sychou 3y ago
  Well said. It's a relative of the premature optimization problem. I often think of them as unearned problems.
  • myself248 3y ago
    Alternately, it's more fun to write sci-fi than to deal with today's reality. And the gap is widening...
• dtagames 3y ago
  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 and monetize the half-broken thing the team is working on now. Yet that's the only way out and the only way anyone gets to 1M users to begin with.
  • icedchai 3y ago
    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.
    • mnd999 3y ago
      I’ve worked somewhere like that. Our baseline requirements for concurrent users were based on the numbers required for the product launch team to maximise their bonus. We never saw anywhere near those numbers in production, but I don’t really blame them - it was a big company and you do what you can to get ahead. A lot of money was spent on infrastructure that wasn’t needed but nobody seemed to care.
    • codegeek 3y ago
      ""Will this work for 1000 simultaneous users?"" Whenever someone asks me this question, I reply with a question "How many simultaneous users do you/we have today and what is our projection say for 12-18 months from now ?". If the answer is not clear, I tell them not to worry yet. If the answer is very clear but numbers are much smaller today (say 5-10), then I challenge them on where they think they/we could be in 12-18 months. A lot of times, it helps the other side see that they are mostly asking "How long is a piece of string".
    • TuringNYC 3y ago
• api 3y ago
  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.
  • seviu 3y ago
    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.
• Aperocky 3y ago
  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.
  • klysm 3y ago
    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.
    • magicalhippo 3y ago
      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/ https://fenicsproject.org/
      • physicsguy 3y ago
        I’d argue that FEniCs was a prime example of this in some ways, at least earlier in it’s history. I started using it in about 2014. It was not exactly what I would call a simple project. It used to be an ordeal to build, could only easily be used via Docker, ported to Python 3 a long long time after most of it’s dependencies did, had an unstable C++ API that changes were not documented for but nonetheless you were required to use if you wanted for reasonable performance for some calculations, etc. The national supercomputing centre in my country managed to only get one version to build because it was so poorly specified at the time and basically only supported Ubuntu! FEniCsX is considerably better usability wise, but that’s the result of hard lessons learnt.
• swader999 3y ago
  Imaginary problems aka gold plating and yagni.
• bsaul 3y ago
  this is definitely one of the advice i give to senior dev i work with: if you're proud of how smart your solution is, there's a high chance you overengineered and made a mess of a simple problem. i now take great pride when my code looks boringly obvious.
  • MajimasEyepatch 3y ago
    Related: my favorite pull requests are the ones that remove more lines of code than they add. People think you need to hoard old code that’s not used anymore like it’s made of gold. It’s not. You aren’t gonna need it, and if you do, you can find it in the git history.
    • sopooneo 3y ago
      I push that so hard. Put the removal in an isolated, clearly named commit that will be easy to search later, tag that commit so it never gets garbage collected, then take a deep breath and say goodbye. You'll be better off without it and 99.9% of the time you won't have to retrieve it later anyway.
    • Daniel_sk 3y ago
      Antoine de Saint-Exupéry — 'Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.'
  • deleted 3y ago
    [deleted]
• victor106 3y ago
  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.
  • basilgohar 3y ago
    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.
    • t43562 3y ago
      "real architects" write code and simply hop from one team to the other so that they have a reasonable picture of the overall system and can try to guide all the teams to make harmonious choices and possibly even reach some goal. 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".
      • pydry 3y ago
        I haven't ever seen one of them. IME architects tend to be people who tell your team that you should be using Azure Cosmos after a Microsoft salesman takes them out to lunch. They last coded 5 years ago.
        • jbmsf 3y ago
          They exist - I am one - but it doesn't work unless your leadership wants someone who doesn't fit in existing hierarchies. I tend to consult and if I go somewhere where I have prior relationships with leadership, it works. If not, I get treated as part of someone's narrow reporting chain and all the incentives are wrong.
• gedy 3y ago
  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.
• dagmx 3y ago
  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.
  • casperb 3y ago
    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.
    • golergka 3y ago
      Where are your developers located and what what are their salaries?
      • casperb 3y ago
        In the Netherlands, Europe. We had a small agency with 3 friends. We did around 250k a year in revenue. Exactly the type of team that is super productive for these kinds of job imo.
    • nXqd 3y ago
      I totally agree with this, normally it should be the cost of any content website for clients. The site is fast, and we just need to deploy on one dedicated server or for free with simple maintenance cost per month these days. We still do the same for small clients, with application building with us and want a content page for their blogs.
  • TrackerFF 3y ago
    In the world of entrepreneurship, you mostly find the extremes. Either you have the bootstrap founders that will trawl through fiverr to find the cheapest labor (the same types that will scoff and get insulted at anything over $10k), or you have the well-funded founders that will pay whatever it takes. From experience: Cheapskates and low-ballers will never be happy. They always want something free, more haggle room, more discounts, and always have high demands and expectations. The best thing one can do is to price yourself away from them.
• stevehind 3y ago
  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.
  • wfhBrian 3y ago
    And thus we will see the rise of the software solopreneur.
    • Gareth321 3y ago
      That's been a thing for 30 years. Entrepreneurship is HARD, and tech salaries are fat right now. I think we'll see a lot more software entrepreneurship when there's another recession.
      • UweSchmidt 3y ago
        Makes you wonder what the actual state of the industry is right now with thousands of layoffs, but then comments like this one. Probably it's a bifurcation and an uneven distribution of reality.
        • Gareth321 3y ago
          There were layoffs in the big tech companies, but the sector itself is strong. Still very low unemployment. They over-hired. It happens. It's been a relative minor correction.
  • David_SQOX 3y ago
    You hit the nail on the head. There are different motivations for different roles within the same company, sometimes those motivations clash internally, all the while each individual IS acting completely logically from their own unique perspectives.
• arpinum 3y ago
  Author gets it half right. Too many developers trying to have fun by doing new things. Affordable initial software development tends to come from places that have boring templated solutions using 1-2 tools. 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.
• HellDunkel 3y ago
  In the imaginary case of the merch selling android app i dont think it is justified to solely blame the developers for the bad product. The root cause for a bad outcome lies in the simple fact that nobody wanted to tell the client that there was already a solution for 20 bucks and absolutely no need for something custom built. NOBODY except the business owner gains anything in this and the client deserves the ripoff too. It comes as no surprise that developers look for interesting challenges without appearing too distracted by the stupid and boring bs work they are stuck with.
  • golergka 3y ago
    Good reputation?
    • HellDunkel 3y ago
      Pure luxury if you live from hand to mouth.
      • Wowfunhappy 3y ago
        Reputation is what gets you more business in the future. You can expand your business or raise rates, or both. Yes, this won't help if you're literally in danger of not meeting payroll next week, but I would hope most businesses don't operate so close to the edge.
• kmoser 3y ago
  The 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 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.
  • steveBK123 3y ago
    I think the move from project management to "product management" really exacerbated this. The type of people that gravitate towards "product" vs "project" management is one thing. Further, project managers tend to focus on delivering the product stakeholders have asked for on time and on budget. Product managers however I find are frequently searching for a new expanded scope of stakeholders to brag they're solutioneering to. I find them more often in the "solutions looking for problems" business than I find developers, or at least developers are only doing it on a micro-scale, while product managers will take an entire team/org on 6 month fruitless missions to build software destined for the dustbin.
  • mordae 3y ago
    The moment project manager stops taking care of minutes, meeting agenda, getting all the stakeholders in the same meeting and ensuring all issues have an assignee and instead starts taking interest in the specifics of the project, I bail.
• davidmnoll 3y ago
  I agree with this to some extent. but there’s a flip side too. 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.
  • pydry 3y ago
    Ive seen a lot of engineers complain about YAGNI being taken too far but none who have seen their concerns validated by reality.
    • davidmnoll 3y ago
      I have seen it validated by reality several times… more times than the opposite. I had a boss refuse to let me do a refactor that changed these sketchy dynamic field tables into json columns because “it’s not customer facing.” They were unable to show off features in an important demo because the endpoints were timing out despite putting 2 other people on it for 2 weeks to find code-based optimizations. 3 days later I deployed my “nice to have” fix and the performance issues disappeared. I’ve also seen a company stall out scaling for years and lose multiple million-dollar customers despite having a novel in-demand, market leading product because they refused to do anything to clean up their infrastructure.
      • pydry 3y ago
        >I had a boss refuse to let me do a refactor that changed these sketchy dynamic field tables into json columns because “it’s not customer facing YAGNI isnt about not refactoring existing technical debt. It's about not trying to pre-empt future requirements. If youre refactoring in anticipation of as yet unmaterialized requirements then YAGNI applies - e.g. generalizing code when when today there is 1 specific use case because tomorrow you think there will be 3+. If youre cleaning up existing code while working on it and the boss stops you because "it's not customer facing" then he's just asking you to violate the boy scout rule.
• spencerchubb 3y ago
  > secure online banking is actually quite an easy problem to solve . . . The storage and transfer of numbers is not a particularly hard problem. 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.
  • jodrellblank 3y ago
    The shareprice of META fell by 75% from August 2021 to August 2022, wiping about three quarters of a trillion dollars off its market cap. From October 2022 to now the shareprice tripled, adding half a trillion dollars to its market cap. Explain that in terms of the Efficent Markets Hypothesis? "share prices reflect all information" - what half trillion worth of information change came out in 2022? and what in 2023? What about insider trading laws? How can we say "share prices reflect all information" when we know there are people who have more information which would give them an unfair advantage, which means the current shareprice cannot be reflecting the information they have?
    • spencerchubb 3y ago
      1. Apple made iPhones more private so Meta can't target ads as efficiently 2. Interest rates affected the entire market
    • laeri 3y ago
      Not to disagree with you but if there are people with insider knowledge they will either dump a massive amount of stock or buy it up changing the stock price. So the insider knowledge should be priced in quite fast thanks to their greed.
  • elcritch 3y ago
    Easy, banking and especially banking software is not an efficient market.
• duxup 3y ago
  > It should be noted that this issue isn’t unique to developers. Management, sales, HR, support, legal, and even accounting departments have their own unique ways of creating imaginary problems. They try to involve themselves too much in a decision, when their presence at a meeting is just a formality or wasn’t requested at all. They overemphasize a minute problem that is related to their role, or hire teams much larger than necessary to illustrate their importance. I run into this more often than problems I imagine. A whole series of what ifs and folks imagining things. The worst part is the fixes to their imaginary problem are usually not well thought out and drive things towards worse choices. I’m a big believer in getting version 1 out the door as problems people imagine often… are never relayed by the actual customer. I often work with some routing software (let’s say routing packages). There is a simple mode that works great. Anyone can use it. The issue is people want to establish say 20 rules about how / when / what is routed. Business folks insist that it be “easy” for “anyone to use” just like the existing easy mode. This is doomed from the start. We can make it easier for sure, but if you have 20 rules with different weighted priorities: 1. It is complex for most people to think of. It will look complex because it is complex. 2. That’s ok because the guy with 20 rules probably has thought about them and understand they have 20 rules. Then we give them UI to visualize it all and customer is happy. But the business folks are upset because the visualization is complex… and there we are again. For the record I usually get through this slog and everyone is happy in the end, but it is a slog due to imaginary problems.
• rco8786 3y ago
  I frequently refer to this as “It would be cool if” driven development. Crucial to fight against this kind of stuff.
• adamnemecek 3y ago
  This sentiment get repeated a bunch but I doubt it's really true. Bad languages and tooling is the root of bad software.
• Wowfunhappy 3y ago
  Isn't this why companies have employees with different levels of experience? Need 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.
  • sigstoat 3y ago
    > Isn't this why companies have employees with different levels of experience? this runs into another common mistake businesses make: putting people onto a task because they're available, not because they're suited to it (in any sense). the junior person (+ a little mentorship) would be great for the job, but they're mired in some big project. but hey, you've got this super senior fellow sitting around waiting for work, and we can bill the customer more for them, anyways.
• brigadier132 3y ago
  It seems like the fundamental problem for the scenario presented in the article was an inability of the customer to communicate their strategy and a completely hands off approach during implementation when they should have had at the very least biweekly checkins with developers with pre-negotiated milestones.
  • dagmx 3y ago
    Yes, I agree. This is fundamentally a communication issue not a “developers run amok” issue to me. They shouldn’t be checking in after two months. They should have regular check ins. They shouldn’t have had such a vague brief. They should have discussed a wide range of off the shelf options from the get go to see if they needed something bespoke or not.
  • roncesvalles 3y ago
    The fundamental problem is that a non-technical person has specced out a technical product without input from technical people. A restauranteur wouldn't develop a menu without input from a chef or prior experience as one. A layperson wouldn't design a real building without input from an architect or engineer. Yet for some reason a myriad of non-technical people (read: laypeople) feel empowered to design, spec, and strategize about software. It still boggles my mind that "product management" is a real profession.
• suid 3y ago
  A long article that can be succinctly expressed by the many variations of this cartoon: https://softwarehamilton.com/wp-content/uploads/2013/02/swing-1024x997.gif https://softwarehamilton.com/wp-content/uploads/2013/02/swin...
• allenu 3y ago
  I absolutely agree with the premise. People just love building things even when they're not needed. After a while, your ego gets attached to whatever it is you've built and you can't let it go. I remember working at one place where somebody built a new framework to solve a common problem we all had. He pitched it to all the other devs in a meeting and I remember being confused about it because there was a standard framework that solved the problem already and did it in much simpler and more elegant way. (To be fair to him, this standard functionality was only recently introduced.) During his presentation, I asked why the standard solution wouldn't work for him. It turns out he wasn't familiar with it. Fair enough, so later I messaged him and showed him the standard way to do it and how much simpler it was. He couldn't be swayed. He just couldn't accept that his complicated solution wasn't necessary. He constructed scenarios where his idea was needed, even though I saw solutions to those scenarios using the standard framework. Interestingly enough, one of the scenarios where his custom thing was needed was in some tests he had written where he did some complicated things to set things up. I looked at the tests and even there saw those complicated things weren't necessary! There were ways to simplify what he was doing so that the tests were better written and didn't need his custom tool. Anyway, he wouldn't be convinced. And because he couldn't be convinced, we got stuck with his solution and saw people continue to work on it, add more functionality to it, fix bugs, etc. All of that work was just a waste of time when we could've relied on a standard solution, which was way more mature and way simpler. All of this drove me crazy, but I realized that sometimes people are just unable to see simple solutions to problems. Worse, having one complex solution begets more complex solutions elsewhere.
  • pydry 3y ago
    Your guy clearly had an emotional attachment to his work not an inexplicable intellectual attachment. It's hard to admit that your baby is ugly.
    • allenu 3y ago
      You're right. It's a good lesson to take away when it isn't you because when you're that guy, it's so hard to separate yourself from your work.
    • 3y ago
• vinyl7 3y ago
  Developers have a lot in common with Rube Goldberg
• t43562 3y ago
  On one project I did it was essential to be able to record how much a tool was used so that we could charge for it. The tool ran locally on the customers' machine and reported to our service. The overall mechanism that sent and received this information had to be reliable or we'd lose money but even worse would be to in some way overcharge customers. Lots of aspects of the design were complicated by this concern. Then we ended up deciding not to make money out of it that way. So we burned enormous effort and created a horrible design for no reason. So IMO the problem is usually with the way requirements are not usually well understood even by the people asking for them. Later on it becomes clearer what is needed but you're stuck with false assumptions baked into your design in a way that you never have bandwidth to remove because you need so much bandwidth just to do normal work....because of those assumptions.
  • drc500free 3y ago
    I think the most important function of a good Product Management team is to understand what parts of the go-to-market impact tech decisions and spend 80% of their energy into pinning those down as firmly as possible. There is a happy medium between JIT delivery of specs for random features and a hard two-year roadmap that can't react to business changes. YNGNA is generally true, but Product's should have a very clear vision of what kinds of entities the system is going to handle over then next 36 months before they start asking for specific functionality. I've seen extra shit get built, but I've also seen e.g. a travel booking system that was built without a "flight" being a first class entity. Flights were deduced on the front end from attributes attached to seats... which worked well until a PM asked for the UI to show fully-booked flights, which HAVE no available seats that make it to the front end. Same product couldn't handle the booker and traveler being different people, when they knew from day 1 that it would be a necessary feature. It would have been little extra work to incorporate into the data model from the beginning, even if the two values were always the same for a while. I think the majority of the technical debt I've seen that isn't ci/cd related is disconnect between the domain model the product team is working in and the data model the engineering team is working with. Formalizing that domain model is now one of the first things I do when joining a team, so everyone agrees on precisely what the major nouns and verbs are and how they interact. Not just for the current system, for where we think we will be in 2-3 years. With everyone doing agile, it's amazing how many incompatible, un-written assumptions you discover that hadn't been ironed out.
• AmenBreak 3y ago
  [dead]
• esbeeb 3y ago
  So very funny! In a highly cynical way.
• lewisjoe 3y ago
  If anything it's the incentive system in software industry, which is at fault. 1. No designer is given promotion for sticking to conventional designs. It's their creative & clever designs that get them attention and career incentives. 2. No engineer is paid extra for keeping the codebase without growing too much. It's re-writes and the effort he puts in to churn out more solutions (than there are problems) that offers him a chance to climb the ladder. 3. No product manager can put "Made the product more stable and usable" in their resume. It's all the new extra features that they thought out, which will earn them reputation. 4. No manager is rewarded for how lean a team they manage and how they get things done with a tiny & flat team. Managers pride themselves with how many people work under them and how tall in the hierarchy they are. Our industry thrives on producing more solutions than needed. Efforts are rewarded based on conventional measurements, without thinking through- in what directions were the efforts pointed at. Unless the incentives of everyone involved are aligned with what's actually needed, we'll continue solving imaginary problems, I guess.
  • morning-coffee 3y ago
    ^ this ^ Until we figure out a nice metric for "removing complexity" and then rewarding for it, it's not likely to change, IMO.
  • ronnier 3y ago
    I really think we have too many people working at most companies. It pushes people to the extremes and edges just to have something to work on. Managers need more people under them to get promotions. And managers want to manage managers to keep moving up. They fill teams of people on products that could really be ran by a fraction of the engineers. But that’s not where we are, we are on large teams working on small areas of the product inventing areas to build in and often ruining the product as a result. We also get slower with so many people. The coordination overhead is killer and losing context as the product is sliced up into small parts that move on without you
    • sanderjd 3y ago
      Yeah I dunno, I hear this a lot, but there has universally been way more work to do than people to do it at every company I've worked for. But that doesn't mean the right things are being prioritized.
• vbezhenar 3y ago
  How do you manage boring part though? Going mad because of boredom is a real thing. I definitely agree that some of my job is caused exclusively by my need to keep myself entertained. But what's the solution? Another factor is resume driven development. Yes, you can frown upon it all the day, but in the end I'll switch company and I'll need to find a new job. And, like it or not, but everyone these days wants a lot of experience from their workers. I'd love to write C89 in the dark corner for the rest of my days for reasonable compensation, but I don't see those jobs, what I see is billion keywords k8s spring boot react query metrics jaeger aws yada-yada.
  • morning-coffee 3y ago
    Try to find other real problems to work on that are different from your current boring parts? The new problems might eventually become boring as well, but often the change and fresh perspective is enough to pique your interest in a motivational and productive way.
  • notatoad 3y ago
    i think it's important to acknowledge when you're working and when you're playing. working on fun things isn't inherently bad, and can lead to actual productivity when the things you learn during your fun geeky tangents turn out to be useful to the actual work. but if you start convincing yourself that the fun distraction is the actual work you need to be getting done, then you might have a problem. (not to say that actual work can't be fun too. jut saying make sure you know which is which)
  • balder1991 3y ago
    I do it by building side projects. As they’re purely experimental, I can use whatever I want and learn a ton.
  • mattkenefick 3y ago
    Try to make it not about the job itself. Reward yourself with other things that are non-code related. "If I get 5-10 of these done today, I'll reward myself with..." Or use your imagination in someway like kids do with action figures. It can seem strange but there's ways it less mundane indirectly.
• dan-robertson 3y ago
  I don’t know what is going on with this article. The first half is a maybe reasonable description of a common way for certain kinds of contracts to go wrong. But obviously lots of software doesn’t get developed in this sort of arms-length way. I would say that imaginary problems (as the author defines them) cause failed projects by consultants/contractors. I find the rest of the article to be bizarre. The discussion around retail banking software seems unacceptably incurious and a very likely incorrect diagnosis of the cause of the problems (it basically stoops to an ‘I could do that in a weekend’ level of criticism[1]). It then transitions to a screed about Goldman Sachs which is, as far as I can tell irrelevant (Goldman do very little retail banking; their software development will be quite different to that done for retail banking), and then some description of how the author thinks (all?) large companies are (mis)run. I don’t know if Goldman was meant to be a prototype for this model of company management but it seems like a particularly strange example (in particular, they still will have some remnants from the culture of being a partnership, so they’ll be run somewhat differently from other big investment banks). I found the second half did not ring true. I’m sure software projects fail at big companies (including retail banks, Goldman Sachs, other investment banks, tech companies, and so on) but I don’t find the reasons given in the article convincing to the extent that I think that section could have been written by someone who had only ever worked at very small companies. But maybe it’s just me and most companies are so obviously terribly wrong in these ways that no one even bothers to write about them and so I only see subtle ways they go wrong like projects dying off due to management acting in bad-faith ways or rewarding people for things that aren’t actually so good for the company or whatever. If you’re interested in better discourse around certain kinds of bureaucracy, look into moral mazes. [1] generally ‘I could do that in a weekend’ is code for ‘I could do some minimum thing that doesn’t actually solve whatever the important problems are in a weekend’
  • mlhpdx 3y ago
    The second part might be summarized as “when technology starts to diverge from the business model, or vice versa, both become messy.”
  • chrisco255 3y ago
    Yeah I agree the author got a bit dismissive about the inherent complexity of solving business problems on an ongoing basis. He even links to a Wikipedia article about Google and offhandedly claims that the problem of indexing the whole web was solved by a couple of guys. We all know Sergey and Larry created the original Pagerank algorithm, but it's farcical to believe that their original algorithm would have stood the test of time without input from hundreds of engineers who had to deal with the rapidly evolving web and all the ensuing SEO spam, ad scams, revenge porn, illegal content, international firewalls, international regulations, scaling their infrastructure to handle billions of requests, creating an ad network to support the endeavor, etc etc. That all cannot be done by two guys in a dorm room. I'm sure Google as an org has accrued plenty of staff that are working on mild to non important tasks over the years, and I get where he's coming from, but reality is far more nuanced.
• nico 3y ago
  Imaginary problems are the root of all problems Maybe a Buddhist could say
• avgcorrection 3y ago
  I gave up on this article when I found out that the first hypothetical scenario has no relation to reality. Implementing something else “because if they implemented the real spec they would get bored” is too much psychology.
  • pilgrim0 3y ago
    The author seem to infer whatever he needs to affirm his opinions, examples are poor and the whole thing is just a rant disguised as reasoning.
• sam_lowry_ 3y ago
  "Premature optimization is the root of all evil".
• ozim 3y ago
  We have beef with AI hallucinating - get 5 people to work on a problem and measure how much stuff they will make up from thin air.
• g9yuayon 3y ago
  This is such a great article. Amazon tackles this problem by emphasizing "working backwards", but it ultimately depends on the people who enforces such cultural value. I remember in one of the Uber all-hands meetings, an engineer asked the CTO whether Uber engineers should always make sure their systems can handle at least a million requests per second. To Thuan's credit, he unequivocally said no.
• honkycat 3y ago
  --- They’ve put their heart and soul into creating this app, and it has some amazing features: A state of the art recommendation system An algorithm generating the transcript of all your streams, in real time Your front page loads in sub 200ms times all over the world A streaming protocol and client build almost from scratch, in case you don’t want to rely on Facebook live A service that allows you to easily integrate over 20 ad exchanges --- What a dumb article. This is just made up. If you hired consultants and they pulled this lawyers would be involved. I stopped reading here. Why continue reading something based on a fake premise.
• hinkley 3y ago
  I spend a lot of time saying “I told you so” to people who were sure my problems were imaginary. When you don’t stay somewhere long or you have a short time horizon it’s hard to connect cause and effect. Also pretending uncomfortable things don’t exist is a very popular character trait. It’s not impossible that some of the problems I see others manufacture have a genesis in past traumas they are trying to avoid (some coping mechanisms are healthier than others).
• hinkley 3y ago
  My venom for design patterns has risen over the years, and I think the reason is that Patterns always represent concrete architecture changes long before the last responsible moment. In my code I tend to leave negative space. A spot where a feature could logically fit, without having to really design that feature before we need it. And as my comfort with compound refactoring has improved, some code smells have fallen off of my veto list. If we need to do X then this solution will stand in our way, but we can alter it here and here if that becomes a problem. It works well for a team of one, but it can be difficult to express in a code review, when someone is adding the fourth bad thing to the same block of code and now I’m pushing back for odd sounding reasons because my spidey sense is tingling about bridges too far.
• Nevermark 3y ago
  OMG, never has truth been so funny and yet so tragic. This article, its art and its font choice, shall be preserved forever in the archive of Historical Documents. Our eternal response to unnecessary complexity? "Never give up! Never surrender!" -- ADDENDUM: The article makes a good case for formally adding "manufactured complexity" and "miscommunication complexity" to "accidental complexity" and "necessary complexity". They are quite common distinct causes.
• Aerbil313 3y ago
  Ted Kaczynski’s “surrogate activities” term is very relevant here.
• ano-ther 3y ago
  Ah yes. This explains very well why, when I ask our corporate IT for a static website with essentially text + some PDF downloads, I keep ending up in a “web platform” project based on a fiendishly complex CMS that is made for running large-scale e-commerce sites — of course delivered after ages and requiring multiple rounds with the CFO to justify the increased budget. Been through that at several companies now.
• legulere 3y ago
  The article rests on the idea that the management knows what needs to get built, but my experience so far was that they are usually even worse at that.
• varelse 3y ago
  [dead]
• eternityforest 3y ago
  The main imaginary problems I commonly see are wheel reinventions. For the most part, the software I see works well for what it does, and either has far too few features, or else all the extra stuff they added is stuff that people actually use. On social media things are different, that's been bad and unsalvageable from the moment endless scrolling made it into something people spend significant time on.
  • vinyl7 3y ago
    I'd prefer see wheel reinvention because it leads to better software. 1) it's debuggable 2) it's fixable 3) it does exactly what you need to do how you want to do it without any extra cruft and nonsense. Libraries or game engines are too generic to be fast and easy to use because they need to solve for every possible use case. And even then, there are still edge cases where what you want to do cannot be done because of the architecture of the thing and so you're stuck with a slow weird ducktape solution to get around the 3rd party code's limitations.
    • eternityforest 3y ago
      Games already cost an insane amount to develop. I would imagine that they would either have to have less content or less realism or cost more. Plus, there's a limited pool of devs who can do 3D game engines(I sure can't!), the more wheel reinvention, the less available resources to do new things. And then wheel reinvention also leads to incompatibility. For some reason it's fashionable for formats and protocols to include optional features instead of making everything mandatory. The big ones support all common ones, the DIY ones usually just support the options they need, and exporting from one and importing to another might do something weird, it takes a lot of work to support the de facto undocumented standard that emerges from sets of optional features with a few popular implementations. Large libraries are debuggable too, because the reuse lets devs throw insane amounts of resources at debugging them even if it's really hard. And for the same reason, they can often be pretty well optimized. Modern software seems to be pretty fast now that Moore's law slowed a bit.. In theory, it's really cool that smaller solutions are fixable, but I'm just not sure we could actually have all this software everywhere running the whole world with small and simple in house code.... I mean, that's kind of what we had in the early 2000s, and while most things in general seemed better and people were happier.... everything that ran on a PC from the Win95 to the Win11 era seemed pretty insecure and unreliable.
• deleted 3y ago
  [deleted]
• danielovichdk 3y ago
  I dont want to get paid and have fun. I want to get paid to solve real fucking problems which has a factual validated need from real people. Most people are terrible professionals. Writes code to have fun and expects to be paid too. And even blogs about it too. I want to be in the trenches. Hard work. Real work. Not some glamorous bullshit that lasts nowhere. Quality long lived treasure is what I strive for. And I dont want to progress by applying popculture technologies because some punks subjective opinion wants to have fun. One has to be a prick and tell these people off because they shovel shit and pad their own backs when the re-shovels it with a new fad. I want to progress by making slow surgery like precision work. I want to make sure that what I do sticks and is sound quality, no code is written for fun. Code is a fucking liability. Between the scams and the hustle, the number runners and the pick pockets, real people with real quality minds do real good work. Those are the only programmers worth being around and hire. Everything else is just a waste of time and mental capacity. So many morons in this business. It's really too much.
• daguar 3y ago
  This is why I truly love support-driven development. While it’s possible to prioritize problems that don’t affect most people (squeaky wheels) it’s a hell of a lot more effective than most of the methods I know to have a very low barrier to contacting you for users, and fixing the things that come up.
• emodendroket 3y ago
  It’s impossible for a large organization to operate as efficiently as a tiny one but I also don’t really believe the article’s implied claim that “a couple smart guys” could solve essentially any given problem to clients’ satisfaction within a reasonable timeframe.
• jameshart 3y ago
  This had good points up until the point where it conflated banking software with ‘moving a few numbers around’. There are vast differences between the pathologies that affect small scale contract web app development as detailed at the start of the article, and those that affect global enterprise development such as is required to build large scale online banking systems. The biggest difference being that many of the things which are ‘imaginary problems’ for the small time web app are very much ‘real problems’ for a publicly traded company with responsibilities to several government regulatory agencies. And sure, these institutions are just as prone to conjuring imaginary requirements, but it requires considerably more sophistication to tell the difference between ‘something someone in the German compliance office dreamed up to make themselves seem important’ and ‘something that if we get it wrong will result in billion euro fines’ when you’re building a banking system rather than a podcast website.
• kurosawa 3y ago
  It might be more general than that: imaginary problems are at the root of bad___ Where ___ could be something produced like software (or furniture, etc.), or theorised such as scientific theorems (as even though thought experiments are useful, if we don’t go beyond them, we are often lead to bad science), etc.
• donutshop 3y ago
  So it's resume driven development that's causing issues?
• austin-cheney 3y ago
  > Most complicated or broken software is not designed to be overly complex or dysfunctional. I beg to differ. This might have once been true, but no longer. Now developers demand a massive arsenal of dependencies before they are even willing to start on any project. You say you need a web page and a few events? No problem. I will just sprinkle in some React, Redux, Grunt, GraphQL, PM2, and a plethora of plugins for each with a cascading list of dependencies for all those plugins. We absolutely cannot do less, because the risk of writing original code is too costly and we value retaining employment (blaming someone nameless outside the company).
• Aeolun 3y ago
  This is a good addentum to the Bullshit Jobs thing that was posted a few days ago.
• greentext 3y ago
  What's a "real" problem, though?
• VirusNewbie 3y ago
  Imagine someone writing small webapps for small companies and extrapolating to assume this is applicable for extremely large scale software design…
• goodtrip 3y ago
  My favorite example of this is the grocery store checkout kiosks that make you weigh each item. So much wasted effort both to produce and use those machines.
• jxramos 3y ago
  I really like this quantification of crash rate and being so up front about it and what’s acceptable. Spending such a long part of my career being in the critical software space it’s kind of refreshing to imagine a more lax world out there.
• valboa 3y ago
  Engineers are terrible prophets. We should focus on the problems of "now". The future will catch up.
• revskill 3y ago
  "Rule Eight: Don’t try to create and analyze at the same time. They are two different processes." — Today You Need a Rule Book, 1973.
• ArunRaja 3y ago
  Summing it up: * Communicate effectively - avoid middle layers * avoid over imagination / premature optimization * Incentivise for organisational efficiency
• daniel-cussen 3y ago
  [dead]
• Hardliner66 3y ago
  Even tho I'll get flak for it, I'll call bs on the article. It's the same as the phrase "(premature) optimization is the root of all evil". Does it mean you should never optimize? No. Does it mean you should always optimize as a last step? Also no. Here's the full quote: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." It's way more nuanced and basically says: "Stop wasting time on optimizations with little gain, but still do them where they are useful/necessary." Right now I'm working on an embedded device running a small Linux. Our resource usage is well within the bounds, so thinking about better architectures or optimizations is an imaginary problem. Right? No. Not at all. Making our software smaller and/or faster doesn't only mean we can put on more software, it also means we could produce cheaper because we need less resources. Thinking about and experimenting with different architectures or newer technologies also seems like imaginary problem solving at first, but there is a good possibility that you improve your system as well. A better architecture could make your software more maintainable or give you the flexibility to implement new features in a way, that was really cumbersome with the old code. So while I agree with the sentiment that you should not implement things you don't need, I also think that there should be room for people to experiment and try out different things. Because sometimes, the people working with the code the longest are blind to it's many shortcomings. Because it's normal for them to just work around them. But getting rid of those shortcomings can save you hundreds of man hours of work in the long run. To cut a long story short: Do experiment. Do think about problems you might have in the future. Do the mental exercise and think about how to improve your current code and architecture. But don't blindly implement it Always evaluate what your trying to do. Check if it improves the things it's supposed to improve and also check if it doesn't make matters worse elsewhere. Get to know the tradeoffs and make informed decisions if changing something that works to something that's better is worth it to you.
• welloffaffair 3y ago
  [flagged]
• deleted 3y ago
  [deleted]
• zimpenfish 3y ago
  A drop of anecdata: Once had a several-days argument about deploying a fix involving an SQL query analysing information from our deployed devices because the other developers were convinced it wouldn't work efficiently for 1000+ devices. Client was threatening to withdraw their money and support -- which would have killed the company I was working for -- if we didn't make things work RIGHT DAMN NOW. Reader, we had 25 devices.
  • alecco 3y ago
    L'Enfer c'est les autres programmeurs.
    • lioeters 3y ago
      Hell is other programmers: Existential programming and the perpetual ontological struggle of solving imaginary problems together.
• mjan22640 3y ago
  that implies: bad software = -1 problems
• temikus 3y ago
  I do agree with the general premise but there are a lot of passages that kinda trivialise a lot of complicated phenomena, e.g.: > Much like victims of childhood hardship or abuse can find escape in fantasy books, victims of enterprise programming or freelance web development can find their escape in solving imaginary problems.
• ctenb 3y ago
  What does ICO stand for? Or ICO-ed, as it is used in the article
  • greenpeas 3y ago
    Initial Coin Offering
• shp0ngle 3y ago
  I like the first part of the article, but then he wents off to some weird rant about banking software that gets old quickly
• ctenb 3y ago
  If the company structure is too complex or too big and your actual impact is either hard to measure or is held back by the system or by colleagues, you have to find a way to stay sane and find a tangential meaning in work. Funnily enough, this doesn't mean it is wasteful. It could turn out that it makes you put more energy in honing your skills, or perhaps you find a way to contribute to open source within your job. Neither are bad things. So I don't completely share the pessimistic outlook of the article.
• strken 3y ago
  Rollbacks of an integrated financial system, live and mid-collapse, built with a shockingly complex set of integrations and features on top of a series of underprovisioned distributed databases and queues, probably aren't as simple as the author believes. Yes, they should have planned to be able to roll back, but it wouldn't have been simple. It would have been very difficult, and if they were fastidious enough to plan for a rollback they presumably would have done the development and migration in stages and performed parallel testing on the old and new systems, which would have removed the need for the rollback in the first place.
• civilized 3y ago
  The species of this I most commonly encounter, and IMO the most illuminating of the issue, is Solution in Search of a Problem. People love having a solution to a problem so much, they will hallucinate the existence of the problem the solution is for. Especially when social approval has replaced any actual mission of the org. In other words, when you have a hammer, everything looks like a nail.
• gnubison 3y ago
  “Imaginary problems are the roots of negative developments”
• creepydancer 3y ago
  [flagged]
• creepydancer 3y ago
  [flagged]
• funny921 3y ago
  [dead]
• binnaclegrade 3y ago
  [flagged]
• funny921 3y ago
  [dead]
• throughchanging 3y ago
  [dead]
• throughchanging 3y ago
  [flagged]
• straymedal 3y ago
  [flagged]
• straymedal 3y ago
  [flagged]
• straymedal 3y ago
  [flagged]
• failbank 3y ago
  [flagged]
• failbank 3y ago
  [flagged]
• singhas 3y ago
  [dead]
• singhas 3y ago
  [dead]
• elevator1 3y ago
  [dead]
• elevator1 3y ago
  [dead]
• sproutscentral 3y ago
  [flagged]
• sproutscentral 3y ago
  [dead]
• tritebiohazard 3y ago
  [dead]
• tritebiohazard 3y ago
  [flagged]
• adultfungus 3y ago
  [dead]
• adultfungus 3y ago
  [dead]
• doppingwindlass 3y ago
  [dead]
• doppingwindlass 3y ago
  [dead]
• tablewomanly 3y ago
  [flagged]
• tablewomanly 3y ago
  [flagged]
• mouthguard 3y ago
  [dead]
• mouthguard 3y ago
  [flagged]
• accurate12 3y ago
  [flagged]
• accurate12 3y ago
  [flagged]
• hootzebra 3y ago
  [dead]
• hootzebra 3y ago
  [dead]
• worried46 3y ago
  [dead]
• worried46 3y ago
  [dead]
• partyflotilla 3y ago
  [dead]
• partyflotilla 3y ago
  [dead]
• deardvd 3y ago
  [flagged]
• deardvd 3y ago
  [flagged]
• perceivestark 3y ago
  [flagged]
• perceivestark 3y ago
  [flagged]
• socketestimate 3y ago
  [dead]
• ebaycheck 3y ago
  [dead]
• priestlifestyle 3y ago
  [dead]
• priestlifestyle 3y ago
  [dead]
• toyotaraccoon 3y ago
  [dead]
• toyotaraccoon 3y ago
  [dead]
• sprite343 3y ago
  [dead]
• sprite343 3y ago
  [dead]
• drillcringle 3y ago
  [dead]
• drillcringle 3y ago
  [flagged]
• hugtinkle 3y ago
  [flagged]
• reallynatural 3y ago
  [dead]
• reallynatural 3y ago
  [flagged]
• hugtinkle 3y ago
  [flagged]
• oilsweet 3y ago
  [flagged]
• oilsweet 3y ago
  [flagged]
• occipital46 3y ago
  [flagged]
• occipital46 3y ago
  [flagged]
• welloffaffair 3y ago
  [flagged]
• simplicity34 3y ago
  [flagged]
• likeable53 3y ago
  [dead]
• likeable53 3y ago
  [flagged]
• noneadventure 3y ago
  [dead]
• noneadventure 3y ago
  [dead]
• nagplatform 3y ago
  [flagged]
• nagplatform 3y ago
  [flagged]
• scarfhockey 3y ago
  [dead]
• scarfhockey 3y ago
  [dead]
• exactlyponie 3y ago
  [flagged]
• exactlyponie 3y ago
  [flagged]
• original453 3y ago
  [flagged]
• original453 3y ago
  [flagged]
• quirkyfalse 3y ago
  [flagged]
• quirkyfalse 3y ago
  [flagged]
• second435 3y ago
  [flagged]
• second435 3y ago
  [flagged]
• salesunbonnet 3y ago
  [dead]
• salesunbonnet 3y ago
  [flagged]
• tearful34 3y ago
  [flagged]
• tearful34 3y ago
  [flagged]
• thrusheentry 3y ago
  [flagged]
• thrusheentry 3y ago
  [flagged]
• fiery675 3y ago
  [flagged]
• fiery675 3y ago
  [flagged]
• staleleotard 3y ago
  [flagged]
• staleleotard 3y ago
  [flagged]
• wrenfreeboard 3y ago
  [dead]
• wrenfreeboard 3y ago
  [dead]
• motorcycle3 3y ago
  [flagged]
• motorcycle3 3y ago
  [flagged]
• momentous13 3y ago
  [flagged]
• momentous13 3y ago
  [flagged]
• caughtenemy 3y ago
  [flagged]
• caughtenemy 3y ago
  [flagged]
• skatingcrackle 3y ago
  [flagged]
• skatingcrackle 3y ago
  [flagged]
• podmazipan 3y ago
  [flagged]
• podmazipan 3y ago
  [flagged]
• nvarsj 3y ago
  Big tech internal incentives really exacerbates this. The entire performance system incentivizes engineers to create imaginary problems and solve them. Honestly, I think a good chunk of engineering activity are along these lines. Literally just imaginary problems being created which compound into more imaginary problems, all which are used by engineers to justify their existence.
• say_it_as_it_is 3y ago
  If you only paid $15,000 for all of that technology after only two months and you're salty about not having automatons carrying out your commands, you probably should just stick to your podcast show and thank everyone for delivering something, even if it's a few shades different than what you asked for. These aren't imaginary problems but interesting solutions. I'd bet that card punching programmers working on the first computers were the first to build interesting solutions along with addressing requirements. Look at how far managers have evolved since then.
• black_13 3y ago
  [dead]