4 ms·

I'm not really sure how the title relates at all to the rambling article contained within outside of it somehow being a 'generational issue' with examples of ba

I'm not really sure how the title relates at all to the rambling article contained within outside of it somehow being a 'generational issue' with examples of bad UI design in large systems. The reality is that it has nothing to do with the developers I can guarantee. These bugs are likely well-documented in whatever choice of shitty issue tracking system the management has decided to saddle the developers with, and promptly buried underneath other concerns which have been prioritized as being more valuable (see: management thinks it'll earn more money). The issue has nothing to do with the developers or the generations thereof, it has to do with the constant firefighting we have to do and the constant demand for new things now. Broken, buggy software has to be pushed out in tight deadlines because They Demand It and often there's no time devoted to polishing passes. And not even considering if the development team has access to a robust QA team dedicated to finding these issues and maintaining the quality bar.

taneq 7y ago
This sounds like the kind of rant I would have written before I had to make those kinds of decisions. - What bug tracking software do we use? You have two hours to research and pick one, and someone's gonna hate it no matter what you do. - Do we focus on fixing a niche bug which affects one customer, or on adding a feature that all of our biggest customers have been screaming for? - Do we get the new feature in for our next release or make everyone wait another three months because one dev is anxious? - Do we build out our QA team ("nobody cares that us devs are overworked and drowning") or do we reinforce the dev team ("cheap bastards won't even give us QA")? Once you have to think about keeping the lights on for a business as a whole, you realise that all of the choices that seemed so huge and obvious as devs are small tradeoffs in a much bigger picture.
Diggsey 7y ago
As bad as management can be, you can't entirely shift the blame from the developers. Having a good issue tracking system is addressing the symptom, not the cause. If the developers are writing software with these kinds of fundamental bugs, then there will simply be too many issues in the issue tracker, and management will have no choice but to prioritise other things because fixing all the issues would take too much time. It's very easy to get into "bug whack-a-mole" where you just add more and more code to address problems without ever fixing the root cause. The article says this is because there are too many abstractions. I think that's sort-of right but could give the wrong idea. Abstractions are a good thing: they are the only way to contain complexity. The problem is when the abstractions are poor, when the implementation fails to match the intended abstraction or when there are no abstractions at all and you simply have an unworkable mess of spaghetti code. The reason things are worse now than they once were is that the environment in which code is running is infinitely more complicated than it used to be. More layers of abstraction are required for the program to understand its environment, and as a result, there is a higher chance that one of those abstractions is problematic. The solution is not always to reduce the number of layers of abstraction, because it's a really good thing that our programs can understand complex environments - it's what makes those programs more accessible, portable, etc. The solution is to always be looking to refactor and/or strengthen the foundations on which we build, and to be better at picking robust foundations to use in our own projects so that good abstractions gain the success they deserve, and bad abstractions are replaced quickly. Unfortunately, those skills are very hard to teach and to learn, and now developers without those skills can do a lot more long-lasting damage than they would have been able to before.

taneq 7y ago

This sounds like the kind of rant I would have written before I had to make those kinds of decisions. - What bug tracking software do we use? You have two hours to research and pick one, and someone's gonna hate it no matter what you do. - Do we focus on fixing a niche bug which affects one customer, or on adding a feature that all of our biggest customers have been screaming for? - Do we get the new feature in for our next release or make everyone wait another three months because one dev is anxious? - Do we build out our QA team ("nobody cares that us devs are overworked and drowning") or do we reinforce the dev team ("cheap bastards won't even give us QA")? Once you have to think about keeping the lights on for a business as a whole, you realise that all of the choices that seemed so huge and obvious as devs are small tradeoffs in a much bigger picture.

Diggsey 7y ago

As bad as management can be, you can't entirely shift the blame from the developers. Having a good issue tracking system is addressing the symptom, not the cause. If the developers are writing software with these kinds of fundamental bugs, then there will simply be too many issues in the issue tracker, and management will have no choice but to prioritise other things because fixing all the issues would take too much time. It's very easy to get into "bug whack-a-mole" where you just add more and more code to address problems without ever fixing the root cause. The article says this is because there are too many abstractions. I think that's sort-of right but could give the wrong idea. Abstractions are a good thing: they are the only way to contain complexity. The problem is when the abstractions are poor, when the implementation fails to match the intended abstraction or when there are no abstractions at all and you simply have an unworkable mess of spaghetti code. The reason things are worse now than they once were is that the environment in which code is running is infinitely more complicated than it used to be. More layers of abstraction are required for the program to understand its environment, and as a result, there is a higher chance that one of those abstractions is problematic. The solution is not always to reduce the number of layers of abstraction, because it's a really good thing that our programs can understand complex environments - it's what makes those programs more accessible, portable, etc. The solution is to always be looking to refactor and/or strengthen the foundations on which we build, and to be better at picking robust foundations to use in our own projects so that good abstractions gain the success they deserve, and bad abstractions are replaced quickly. Unfortunately, those skills are very hard to teach and to learn, and now developers without those skills can do a lot more long-lasting damage than they would have been able to before.