4 ms·

I think saying 'they're drowning' is still giving them too much credit. People who built terrible broken systems don't know they are bad at building things, an

I think saying 'they're drowning' is still giving them too much credit. People who built terrible broken systems don't know they are bad at building things, and they probably don't have a clear idea of what would be better or worse to begin with. They don't know it's better to have a system that can be debugged, they don't even know what the difference is. If you give them examples of good designs and bad designs, they can't tell you which is which. When they say 'this is good' or 'this is bad' they will astound you with the reasoning. Software is an industry with no standards for employment. All it takes to be a Software Engineer is for an incompetent manager to hire you. More than half the people I interview barely have a basic familiarity with writing software. These are people who have been employed as software engineers for years and will certainly find another job. They struggle to write a nested for loop. They write functions with thousands of lines. They just don't know what they are doing. The author here claims they don't want the visibility of the situation to increase, but I think they don't know it's a problem to begin with. Their stupid excuses for not moving forward are just their stupid thoughts said out loud.

vanniv 7y ago
My team has built garbage software at times. It isn't because we don't know how to build good software, and it isn't because we don't care, and it isn't because we don't want to build good software. It is usually because of a continuous sequence of emergencies to which we are forced to react. An emergency occurs, and we have requirements to do something in 1/3 the necessary time. We get 80% of the way though that and, before launch, there's a new emergency, and we have to rush to that. So we end up with crap software that looks like shit and only almost works. But it almost works enough to keep our very large business humming along. Sure, we hate it, and we're making more technical debt, and over time, we get less effective. But sometimes we go through cycles of a year or two when the business either can't afford to do it right or isn't willing to pay the price to do it right. Sometimes, they really are willing to accept paying 10x as much so long as they can pay in a year or two. (I hate it, but it is true)
- AstralStorm 7y ago
  Make it 100x as much with 5 times as many people in 10 times as long. Efficiency is never important when there is money to burn and it's not yours, and you won't be blamed when it breaks. It does not even take any emergency - often it is conscious or subconscious project management strategy. It's related to observations about Peter principle, Dilbert principle, Gervais principle and office politics and dynamics. Avoiding this tendency is essentially only possible with small teams with full ownership of the problem they're working on and direct stakes.
JohnBooty 7y ago
People who built terrible broken systems don't know they are bad at building things, and they probably don't have a clear idea of what would be better or worse to begin with. Sometimes this is true, sometimes not. The early days of a company (or product) can be full of existential threats and rapidly changing requirements. Resources are always limited and dev teams are always stretched beyond their limits. The crappy code you see may be there because it was a literal choice between that duct-tape solution you're looking at, and missing out on some major deal or perhaps even going out of business. Now, yes, the people who built such a rickety system can become obstacles to improvement. But, they are not necessarily incompetent. They may have been forced into making the least-bad decision out of several terrible options, over and over again. Sometimes they're just pretty bad developers though.

vanniv 7y ago

My team has built garbage software at times. It isn't because we don't know how to build good software, and it isn't because we don't care, and it isn't because we don't want to build good software. It is usually because of a continuous sequence of emergencies to which we are forced to react. An emergency occurs, and we have requirements to do something in 1/3 the necessary time. We get 80% of the way though that and, before launch, there's a new emergency, and we have to rush to that. So we end up with crap software that looks like shit and only almost works. But it almost works enough to keep our very large business humming along. Sure, we hate it, and we're making more technical debt, and over time, we get less effective. But sometimes we go through cycles of a year or two when the business either can't afford to do it right or isn't willing to pay the price to do it right. Sometimes, they really are willing to accept paying 10x as much so long as they can pay in a year or two. (I hate it, but it is true)

AstralStorm 7y ago
Make it 100x as much with 5 times as many people in 10 times as long. Efficiency is never important when there is money to burn and it's not yours, and you won't be blamed when it breaks. It does not even take any emergency - often it is conscious or subconscious project management strategy. It's related to observations about Peter principle, Dilbert principle, Gervais principle and office politics and dynamics. Avoiding this tendency is essentially only possible with small teams with full ownership of the problem they're working on and direct stakes.

JohnBooty 7y ago

People who built terrible broken systems don't know they are bad at building things, and they probably don't have a clear idea of what would be better or worse to begin with. Sometimes this is true, sometimes not. The early days of a company (or product) can be full of existential threats and rapidly changing requirements. Resources are always limited and dev teams are always stretched beyond their limits. The crappy code you see may be there because it was a literal choice between that duct-tape solution you're looking at, and missing out on some major deal or perhaps even going out of business. Now, yes, the people who built such a rickety system can become obstacles to improvement. But, they are not necessarily incompetent. They may have been forced into making the least-bad decision out of several terrible options, over and over again. Sometimes they're just pretty bad developers though.