Software should really only be measured by the value it provides. If a terribly buggy piece of poorly written code still saves hundreds of man hours a week, it's a win. (Unit tests be damned)
If that big ball of mud that's using 20 year old technology still prints a billion dollars a year - that's a win. (Microservices be damned)
If some slapdash jquery-and-duct-tape web app still solves a specific problem I have, that's a win. (React SPAs be damned)
Does crappy software flourish while beautiful software dies? Sometimes. But usually code hygiene, security, bug counts and crashes are not what makes or breaks the success of a piece of software. Developers often think their work is the most important, when in actuality it is usually not. Sometimes you really just are a cog in the machine.
This mentality is the reason why sometimes -- but not always! -- my phone won't play music in my car until I restart the _car_.
This mentality is why game development companies get away with charging full price for unfinished, bug-ridden games with crippled features and missing content.
This mentality is the reason why I couldn't see my credit card in the list of my accounts on my credit union's online banking site for several days.
This mentality is why Experian and Equifax don't report the same credit score for me.
This mentality is why I feel ashamed every time a receptionist apologizes for the wait, because they "have been having problems with the system."
Most importantly, this mentality is why I have to worry about whether someone will steal my identity because people keep writing shitty code on top of shitty code and my personal information keeps getting leaked.
When I'm so disgusted by my own profession, no wonder I ended up burned out.
We want everything fast! Nobody is willing to put in the work and get the reward after a longer period of time... No! We want results now! We don't want to wait for the food to be properly cooked, we want it now, so we go for fast food. We don't want to put in 1 year of work to learn something new so we can feel that we achieved something, we want it now, so we play a game where we can 'win' in 30 minutes. We don't want to build a relationship and eventually end up being intimate, we want it now, so we go for 'one night stands'.
Then you ask yourself... is it weird that the economic system works the same? That the software industry works the same? :/
> We don't want to wait for the food to be properly cooked, we want it now, so we go for fast food.
We go for fast food because it saves time. When I opt to order in instead of going out for lunch, or grab a burger from McDonald's en route, I do that because eating is mostly instrumental. I don't want to eat at that point, I have to, and the sooner I can fill myself up, the sooner I can get back to doing the things I actually care about.
Fast food, and food delivery services, allow people to choose to spend more time on other things, when those other things are more important to them. The same people will enjoy a finely cooked meal on a different occasion, when they prioritize it.
> We don't want to put in 1 year of work to learn something new so we can feel that we achieved something, we want it now, so we play a game where we can 'win' in 30 minutes.
Spending a year on learning something to just get a quick feeling of achievement is a very stupid way to go about it. Videogames are better for that. Learning is better for getting long-term feelings of achievement, and to actually gain knowledge/skills that you can use for something. And again, it's not something new - our generation wastes time on videogames, previous generations wasted time playing soccer, cards, darts, and doing tons of other quick-reward activities.
> We don't want to build a relationship and eventually end up being intimate, we want it now, so we go for 'one night stands'.
One-night stands exist for as long as humans are humans. Nothing fundamental changed, only the hookup methods evolved with population density and available communication tools.
--
> Then you ask yourself... is it weird that the economic system works the same? That the software industry works the same?
Nah, they don't work the same. In them, the actors are not driven internally, they're driven externally. People write shitty software, or sell shitty products, not because of their need for instant gratification, but because of market pressures. A fast hack sold by your marketing team can be a difference between you getting $100M contract versus not getting it, or getting your product on the market first versus a week after your competitor. Market economy, because of all its efficiency, is what creates the culture of suck.
It's so obvious. But until you realllllly sit down and internalize it... then you can be at peace with the shitty service of Comcast, etc.
In other words: Don't hate the player, hate the game.
Ha ha, maybe this is why they don't want older engineers. They're wise, cynical, bitter, skeptical and not likely to suffer bullshit management.
You just have realize that most software buildings are tents, and there are a few buildings that you can use out there.
I don't know if the world is getting a shittier place. But it surely is getting less reliable.
It is, because everything is being optimized into literal minimum viable products. That's how competitive markets work - whatever aspect of your product or business you can cut out to save money and thus get ahead of your competitors, you will cut out, and then your competitors will cut it out too, in order not to get outcompeted by you. This race-to-the-bottom phenomenon is fundamental to how competition works, and the result is that products gradually lose quality.
It's the reason why your grandfather's washing machine probably works 'till this day, while you have to fix your new one every year, and will probably replace it in five years. "Building to last" is a good example of a quality that the market economy optimized out over time across pretty much all products in all sectors.
Adjusting the cost of each product with inflation, things really are built like they used to be. Your grandfathers washing machine both cost far more than a current model* (again, adjusted for inflation), and all of the poorly built old washing machines broke and no on sees/thinks about them anymore.
* I am having trouble finding a source on washing machines specifically, however I'm assuming they followed the same trends as most commodities tracked by BLS: https://data.bls.gov/cgi-bin/surveymost?ap
As questionable as citing Reddit is, this post rather well encompasses what I am trying to get at: https://www.reddit.com/r/Showerthoughts/comments/4kn8ku/the_...
The way I see the post you're replying to is either you learn to cope with these things or you'll burn out faster.
Since there's no accountability, if you want to do things the right way, you'll have to do it by yourself and be prepared to swim against the tide..
Most of those bugs and failures you listed are really inconsequential in their contexts.
Car won't play your phone's music? Use the radio. Game has bugs? Play another game until it's patched, or find inventive ways to use the bug. Can't see your CC? You can still charge on it and pay its balance. Experian and Equifax don't report same credit score? Your creditors aren't reporting to every credit bureau.
Ashamed that someone else's system doesn't work? I can't help you there. That's some deep psychological issue.
About 10 years ago I came to understand that mediocre runs the world. All these people, who are your bosses, who are getting raises and promotions, they're the B/C students from college. They don't care about perfect. They really only care about finishing what they're assigned and going on with their outside life.
If you want perfect, do it on your own time.
Yes, I expect that for most things we could find a context that could render them inconsequential.
> Car won't play your phone's music? Use the radio. Game has bugs? Play another game until it's patched, or find inventive ways to use the bug. Can't see your CC? You can still charge on it and pay its balance. Experian and Equifax don't report same credit score? Your creditors aren't reporting to every credit bureau.
Elevator doesn't work? Use the stairs. Public restroom is filthy? Hold your breath and don't touch anything. Lost a tooth on the right side of your mouth because of an incompetent endodontist? Chew on the left side.
I'm not being facetious here. I really do agree that almost anything is tolerable if we decide to. That last example is from personal experience: I have lost three teeth on the right side of my mouth and I have to chew on the left. Most of the time, I don't even think about it anymore. And it really isn't that big of a deal -- it doesn't have a very significant impact on the quality of my life.
> Ashamed that someone else's system doesn't work? I can't help you there. That's some deep psychological issue.
It could be. Like I commented elsewhere, I would expect a doctor to be ashamed of Andrew Wakefield, but maybe most of them aren't. And even if they are, it could be a deep psychological issue that I choose to compare the state of our industry to what Wakefield did in his.
But here's the thing: I know that we can do better. Not perfect, better. But we don't have to, because we lack accountability.
Sure, perfect is the enemy of the good. But complacency is the last refuge of the mediocre.
Personally I get angry in those situations... the larger the company, typically the more safeguard crap in place that's supposed to prevent those issues, the more pissed off I get. But that's just me. I get angry when I see evidence of poor/buggy quality in business software the more visible it is.
why would you feel ashamed for waiting a little longer?
that's an odd thing to be insecure about
The problem is when the "negative value" is externalized leading to false evaluations. "Oops, so sorry we leaked all your social security numbers. Our bad."
Because it's not really the value overall the software provides that's being talked about but the instantaneous, immediately visible payoff to a single consumer that software, the people or that consumables are getting judged by. If the software is going to result in trouble over time, if it's going to have security holes that will cost a lot over time, if it's going to commit you to garbage that's updated less and less frequently, etc. None of this calculated. Just as the health costs of sugary drinks don't get calculated, the social costs of poor education don't get calculated, etc.
Is it possible that the value assigned to keeping that information secret was, in the end, actually appropriate?
Ask someone who's had their identity stolen.
I’d hire you.
The vast majority of people making agregrious security errors know no better. You could argue that whoever hired them shares or shoulders the blame, but to suggest they’re not decent people is a stretch. Most I’m sure are. They’re also likely infosec idiots.
Now if you know something is terribly insecure, understand what’s involved in fixing it, and go out of your way not to, then yes ethics come into play. I see that the same as an engineer (in the true sense of the word) staying silent on an issue involving automobile brakes that could lead to casualties. The consequences are not 1:1 but the ethical question is in the category.
If your bugs can hurt people (financially, physically) I think you need to work a bit harder to make sure it doesn't sneak into your work. Whatever you believe helps there (unit tests, formal verification, ...); if you didn't do all you could do because you are not paid for it (your boss tells you to add features, don't waste time on things that didn't break yet for instance), what should you do? Seems like a real issue for professional coders as there are not so many options; not many companies will pay to prevent these kinds of things unless they had a big issue before already (and someone(s) got fired / sued for it already).
But as one HNer to another, I was really talking about your second case. To claim here that security can ever be discounted, as the person I was replying to implied, is pretty much inexcusable. Everyone here knows that security affects more than just your business, so no one here should be solely applying business logic to it.
But those bugs could easily lead to mistakes in the output.
Code quality matters and has tangible consequences in that niche, and it was awesome to work in that environment.
I haven't worked anywhere like that previously, and I think the key factors that brought code quality to the forefront were:
* Bugs cost sales
* Poor code caused friction for features a significant amount (reduced ROI)
* Small teams and an insanely tight customer relationship to those teams. The client needed to have a stakeholder in our team or as close to that as possible.
But most importantly it was just the company culture from top to bottom. The director cared, he made the project managers care, and we already cared because it's more fun to write good code.
We did take on a rushed project at one point, so there is a good comparison in that project. It shipped, but everyone was unhappy, some key people left and had to be re-hired for. It triggered a very transparent discussion roughly titled "let's figure out how to never do that again" and to that end they curated the clients more carefully, and put in some checks to see if projects are a good fit.
But I understand that is probably unique, and at previous jobs the "good enough to make money" mantra has worked out okay.
I think when your software domain is complex and rapid, it pays to have sound architecture. When it is simple, or slow to change, it doesn't matter quite as much.
Whoa now. The Toyota 'unintended acceleration' case showed us that it's fine to kill the customer. The court declared themselves incapable of penalizing even the most stupendously egregious example of criminal negligence we're likely to see (Of 90+ 'required' and 'suggested' practices in automotive industry firmware coding practices, they did 4 in the code in question. The developers didn't have a bug tracker or static analysis tools. Typical of all organizations, the software engineers had no real power to demand more time or testing, etc). They lost a civil wrongful death case and paid out $4 million, then settled with the plaintiffs out of court before the jury could award punitive damages. So killing is OK.
The issue is that, I think, software people need to stand up for themselves. They need to tell executives no, and refuse to pump out slapdash work. They need to take responsibility for the successes and failures of the company. The practical truth is that in most organizations, the software is the most valuable part of the entire business and the thing with the power to enable the company to excel or fall flat. We've been waiting for executives to recognize this since the 1980s and they still just see the software people as people who do typing.
After a 10-month search, NASA and NHTSA scientists found no electronic defect in Toyota vehicles. Driver error or pedal misapplication was found responsible for most of the incidents. The report ended stating, "Our conclusion is Toyota's problems were mechanical, not electrical."
https://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle...
Third advice. It's not enough to fix bug, everyone MUST know that you fixed that weird bug that customers were complaining about for years and noone could understand the cause.
The important word here is pretend. If the system is safety critical you'd think that quality matters. It doesn't. What matters is following the process laid out in ISO 26262 or whatever standard applies to your field. Whether or not that improves quality is not important (it does, but only a little). The important part is that you have reduced/no liability for accidents if you can prove that you did everything by the book.
Edit: It's all about documenting that those things have been done and signed off on, so keeping track of paperwork.
https://en.wikipedia.org/wiki/What_Do_You_Care_What_Other_Pe...
...where he talks about his role and questions regarding the Challenger shuttle disaster; I don't know if things have changed much since then at NASA, but I suspect they haven't, given Columbia and such.
After all, that is the point of those heavy processes: manage to product something fairly reliable despite the acknowledged presence of morons and shitty managers. The process does not try to eradicate those people, it works around them with some kind of redundancy.
Having been one of those 'concerned' people, I must admit it is exhausting. You know that if some work comes from this guy, or that company, it will be 90% shit and you have to explain them again and again what is wrong and how to fix it, or do it yourself when you are really fed up. So basically you do your job + the slackers' job. That is how the system works. As a system, the result is not too bad. As far as individuals are concerned, however...
If you have to remind people of it, it's as good as not existing in the first place.
> What can you do for me or have done for me recently?
Services provided so far in the past that need to be reminded are at best irrelevant and it can actually hurt you to bring them up.
I'm not saying that it is nice, only that humans behave individually and (even more collectively) according to this.
You might also carefully consider your company's culture when deciding how to split your efforts between new (user-visible) features, preventive maintenance, and bugs affecting end users (especially any VIP end users that have your managers' ears).
For example, a 'Hero' culture rewards last-minute, late night, death march efforts, whether to fix an urgent problem, or to add that one feature that is (supposedly) needed to land a specific high-value customer/sale.
I suggest reading the comments on this thread:
I learned this at my first software engineer (though we didn't call it such) job back when I was 18; closing in on 45 years of age, and I'm still here at it, and don't see that changing soon. I have thought about management, but I really don't have such experience, and I'm not a real people person anyhow - plus I like to code.
Another thing I have learned - at least here in the United States: Not only do they not care about quality, they usually don't have any loyalty to you as an employee. They'll let you go without any warning at all, and if you're lucky, you'll get some severance pay.
So save your money, build a savings account with FU cash in it (6 months to a year of salary - or more), and don't be afraid to drop an employer like a hot potato if things aren't working out, or a better offer is in the works.
And above all else, don't let your skills stagnate.
Do they care if a year down the road your TTM times increase tenfold?
We know that the bad code slows us down. Why do we write it?
Why do we write the code that slows us down? How much does it
slow us down? It slows us down a lot. And every time we touch
the modules we get slowed down again. Every time we touch bad
code it slows us down, what do we write this stuff what slows
us down?
And the answer to that is: well we have to go fast.
I'll let you to deal with the logical inconsistency there, my
message to you today is—you don't go fast by writing crap.
When nobody cares about you get the point sooner or later where you can't ship, they've probably launched a product but there's still a lot more to ship in future. Eventually they become so mired in technical debt that they care.
When they realize they've invested a hundred million dollars in something that now has no value? They care. (especially if it's a turd before it gets out the door)
When a start up comes along and eats their lunch because they aren't weighed down be legacy code? They care.
When they lose revenue because they can't keep customers happy? They care.
The problem is that the professionalism of software developers doesn't allow them to learn these lessons early and hard enough.
> They care.
> They care.
> They care.
I disagree. They will hire a consulting company to do a root cause analysis. The Ha'vad grads from McKinsey will swoop in, determine that the past doesn't matter, you need to get to black and to get to black, the St. Louis team needs to go, along with 20% of the following 7 teams....
No, they don't care. And never will.
Edit: Unless we elect people who take away legal protections in place to regulate safety critical software
Where?
It's over two decades since that was written. I remember reading it when it was first published. Does it look much like the future?
Your method is refactored to be super-fast and have no branches? Nobody cares.
Elegant, re-usable architecture? Nobody cares.
You've optimized an inner loop in assembly and increased speed by 30%? Nobody cares.
Made it to zero compiler warnings? Nobody cares.
No known crashers left in the bug tracker? Nobody cares.
Fixed that bug that's been in the code for two years? Nobody cares.
Patched a security hole that could allow a crazy bad attack? Nobody cares.
The vast majority of software shops out there care only that something--anything--ships as fast as remotely possible, and as long as it does not kill the customer, it's a success. Nobody in leadership gives a single fuck about anything else. There are a few places where this is not true, and good software people tend to collect there, but it's true for the vast majority of places where you will work. The sooner you accept this, the less likely you'll burn out.