There are also lots of problems that we are just not interested in solving. A lot of convoluted business logic that any sane person would just not want to muddy themselves with. It may be difficult, but it doesn't feel worth it.
This seems an apropos place to recycle a rant from Reddit:
[...] This happens when the managers/executives try to push the problem onto IT/engineering, blithely assuring everyone that "The New System" will somehow paper over and solve their org/process inconsistencies.
This means that the engineering teams gets requirements for one tool to handle the multiple teams' workflows and business-logic, stuff which nobody seems truly interested in harmonizing long-term. Thus your tool needs a fuckton of special-case logic and workarounds, leading it to become a monolith of spaghetti. Even if it started as a bunch of separate systems, they become slowly woven and pulled together by all special-case webservice calls and database state-sharing.
Then, after release, some people in suits spend a while patting each-other on the back, claiming to have materially improved "how we do things"... up until somebody wants to make a seemingly-simple change that conflicts with all of the other pick-up sticks.
P.S.: In a weird way, the implication that the programmers can fix those big issues is flattering, but it fades quickly as you realize:
1. You probably aren't actually being given the freedom/power to solve the real problem.
2. If you were to solve the real problem, the company would be underpaying you.
3. Even if the first two things cancel-out, the end-result is a PITA.
Comments
There are also lots of problems that we are just not interested in solving. A lot of convoluted business logic that any sane person would just not want to muddy themselves with. It may be difficult, but it doesn't feel worth it.
This seems an apropos place to recycle a rant from Reddit:
[...] This happens when the managers/executives try to push the problem onto IT/engineering, blithely assuring everyone that "The New System" will somehow paper over and solve their org/process inconsistencies.
This means that the engineering teams gets requirements for one tool to handle the multiple teams' workflows and business-logic, stuff which nobody seems truly interested in harmonizing long-term. Thus your tool needs a fuckton of special-case logic and workarounds, leading it to become a monolith of spaghetti. Even if it started as a bunch of separate systems, they become slowly woven and pulled together by all special-case webservice calls and database state-sharing.
Then, after release, some people in suits spend a while patting each-other on the back, claiming to have materially improved "how we do things"... up until somebody wants to make a seemingly-simple change that conflicts with all of the other pick-up sticks.
P.S.: In a weird way, the implication that the programmers can fix those big issues is flattering, but it fades quickly as you realize:
1. You probably aren't actually being given the freedom/power to solve the real problem.
2. If you were to solve the real problem, the company would be underpaying you.
3. Even if the first two things cancel-out, the end-result is a PITA.
Worse is that a lot of that logic is just silly. There's no reason for it--this gets worse as you get closer to, say, regulatory issues.
Usually we end up paying the logistical debt racked up by some clever suit months or years prior.