Comment by ryandrake
15 hours ago
Most places I've worked have been infuriatingly uninterested in fixing bugs, and would release software with major known bugs and a vague plan to fix them later. Of course, when "later" came, there were more features to cram. No time to fix those bugs.
I'm hoping one of the unintended side effect of it being essentially free to find and exploit (and fix) software bugs is that companies become less cavalier about shipping bugs in their software. Unlike most of the industry I don't believe "bugs are inevitable." Bugs are a choice developers make when they're rushing and careless and when all of their incentives are to ship quickly. You can ship bug-free software but it takes (or used to take) a really long time and a lot of care, care that commercial software developers just don't ever seem to muster.
Maybe when their software is getting 0wned over and over and 30 security issues are published a day, they'll start caring and taking their time.
Bugs are a choice by managers, not developers.
I disagree, a bit. There should always be some contention between manager and developer. It's healthy. But I think many developers just remain silent and are afraid to speak up. They are afraid of losing their jobs, or worse, getting kicked out of the country. It's reasonable, but it is one of many factors that contribute to the negative feedback loop of myopic management.
We've all seen developers who game the system. They hide the bugs just enough so checked out management doesn't see them. They convince themselves that those bugs don't matter, even when they trip over them later. They get rewarded because they appear to move fast, eventually become management, and the whole thing gets worse as time goes on.
It's a structural problem. Yes, the level of influence is higher the higher up in the org chart you go, but there is still "power" at every level. Even the most junior developer has power. The worst thing we can do is become apathetic, shrugging it off, saying "well what can we do?" That attitude is one of many factors that got us to this point. Importantly, it is a factor we actually can influence.
That's why I object to it. Not because I think it is going to solve the problem overnight, but because it is a thing we have some power over. And it is a very different situation when one engineer in a team is vocalizing "our software has issues" while most of the team silently agrees vs several members of the team simply vocalizing agreement. There's no magic single variable fix to problems like these, but we got here because a bunch of little problems added up. Unfortunately, or fortunately, the way to solve it is through solving a bunch of little problems. Each seems insignificant in isolation, but they accumulate
You probably never had developers working for you. First, if you don’t give them a deadline they will work on it for months trying to get it perfect, but it will still be buggy and do the wrong thing unless you keep very close attention. Second, because you must give deadlines due to the previous point, the result will be buggier still, as they will spend most of their times on what to name variables and how to structure the packages and modules. Their testing will cover their mocks and when put together in the real thing most functionality will just not work at all. I’ve seen this happen even with senior developers. With juniors it’s guaranteed to happen without a very good tutor. Take some fucking responsibility. If you deliver software, make sure it’s in a working state. Don’t blame your manager for everything, they did not force you to write shitty code, if you think they can do that you are not ready to work as a professional developer, you are just a code monkey.