13 ms·
If billions of computers become vulnerable to malicious actors and a few hundred or thousand people suffer dramatic personal damages, well that's a nice and qui
If billions of computers become vulnerable to malicious actors and a few hundred or thousand people suffer dramatic personal damages, well that's a nice and quiet problem which will be quickly forgotten in the 24-hour news cycle.
This. I do development coaching and training. I’m totally burned out because my job doesn’t matter. These companies don’t care. They hire me to “increase code quality” but that ends up being a lie. They just use me to get their teams to crank out shit faster, and I do mean “shit”. They don’t care if the systems blow up a few times a year or once a week. Banks, oil companies, airlines, all of them. They loose millions because of it too, still it doesn’t matter. No one (in leadership) gives a fuck. “Just make this quarter’s goal” is all that matters.
Fucking equifax for crying out loud, NO CONSEQUENCES. If this isn’t ironic enough do some googling on why Equifax is named such. tl;dr This isn’t their first rodeo. They once fucked up so big they had to change their name.
Sucking at software only has consequences in a few industries, usually ones where the product is software, the product is discretionary, and the customer is fickle. Even then it usually sucks.
These same companies are audit conscious (about money), they’re crazy about regulatory compliance, and workplace harassment. Why? These things have real consequences.
The sooner some company gets fined one year’s profit or an exec goes to jail the sooner this shit will actually matter to them.
I think you've nailed it on the head but haven't realized why you've nailed it on the head.
`Why? These things have real consequences.`
To a business they see software/engineers as a expense. The whole focus as a business is to provide a service that people are will to pay more than it costs to provide said service.
Everything else doesn't matter, what does matter for a business is $$$$$ and making sure business doesn't get sued because bill touched jill with his #####.
For what my words are worth, I do think you need to take a step back and view it from a Business person perspective and attempt to align your goals with theirs. Get out of your cube and go and meet CEO's and CIO and talk to them about their problems and what their goals are. Then see if you two can work together to achieve their goals and bring value to the table.
Even writing this I've could think of 10 or 20 different business discussions you could have.
>To a business they see software/engineers as a expense.
Anecdotally, this is one of the first things I try to gauge at a prospective employer. "Are their development teams seen as cost centers, or profit centers?" If the company works with technology a lot and doesn't see technology as being particularly important to its bottom line, that's usually a bad sign.
Also, discussions with C-levels tend to be pretty one-dimensional. It doesn't matter how much their infrastructure is falling apart, they'll still stonewall with something along the lines of, "our goal this quarter is new user acquisition - how does this improve those numbers?"
And they won't accept, "users cannot sign up if everything is broken" as an answer.
You're 100% right but also 100% wrong.
Like I said before you're viewing it from the perspective of a developer but not from the perspective of a Business person.
Instead of saying `Users cannot sing up if everything is broken` you need to see it from a Business perspective, and communicate it to them in the language they understand.
For example,
`From our quarterly earnings report we need to have 10,0000 new clients signed up by the end of the month to reach the goal. We have on average 2,000 sign-ups per day. On the 2nd, 3rd of last month two of the critical system's fell over, and this result in a estimated 4,000 failed client acquisitions. The estimate from our quarterly earnings each new customer bring's in a revenue of $300 net profit from each client for the quarter. As a result of the system crash our quarterly earnings will be down 1.2 Million.`
Your job is to communicate clearly in the language they understand how it will achieve their goals. You're not the only department/manager who is requiring resources from the Business. As I stated before you're there to serve the business to achieve their goals.
The corollary here that it is perfectly acceptable for business users to not understand significant parts of their own business operations. In fact, everybody should work around your shortcomings in understanding that "technical" stuff. As the guy with the MBA, you are the most important person in the room and everybody else is there to serve you.
Regarding Equifax, when a company like that gets enough negative public reaction, they look for a bandaid. In the case of Equifax, they recently hired ReliaQuest https://www.reliaquest.com/ https://www.reliaquest.com/
I've friends at ReliaQuest and I know it is a good company, but I am frustrated that the leadership at Equifax thinks that security is a minor issue that they can outsource to a 3rd party. If a company deals with sensitive financial data, shouldn't security be a core competence?
The topic of your rant is something that it took me forever to accept as a software engineer. Nobody cares about quality.
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.
If there were a list of such companies, I would patronize them.
My universal advice to graduating CS students is, "no matter what your current code quality/dev speed balance is, your boss will think you're polishing too much."
Second advice. If you want to pretend that quality matters, move to aerospace, finance, or any critical systems.
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.
> If you want to pretend that quality matters, move to aerospace, finance, or any critical systems.
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.
>"Are their development teams seen as cost centers, or profit centers?"
It's not a matter of opinion, but what the term means. They are cost centers unless they are closing sales (or being billed for about 3x what they cost, which is still way less than sales people will generate, being closer to 10x+ cost).
Best thing any employee can do is find out how their company actually makes money and understand how they align. Unfortunately, the highest business expense is salaries and one of the most important things for most businesses is remaining runway. So there is huge pressure to keep salaries down, particularly in cost centres, which aren't directly extending runway. If it's a service business it can get worse, as the money is typically made on billable hours - creating a perverse incentive to have cheaper and less efficient people to bill out rather than a 10xer (outside a senior business facing role). As long as they are capable and not so bad that they lose the client, it's often more efficient to have cheaper mediocre people from a business point of view.
How can a software developer fight against this salary limitation?
Become a highly sought after specialist for a product offering (e.g. self-driving cars, blockchain, fintech), or get ownership (startup), or go customer facing (particularly if commission involved), or go into technical management on CTO route.
> one of the most important things for most businesses is remaining runway
Remaining runway is a measure that only exist for companies in the red. For most business it doesn't even exist.
Yet my experience is that the issue comes from engineering a lot of times: fixing bugs is not fun, let’s rewrite everything because this time we learned from our errors, or just to use the new shiny framework. A buggy legacy code base that no one wants to touch or improve, and V2/New projects that of course completely fail to deliver in the end and the cycle repeats. Being in a customer team I try everyday to make Engineering care about non technical end users. My team and business might be responsible for some feature creep, but bad code quality comes from engineering practices.
Edit: to be more clear the discussion usually goes like this:
- Me: “where are we on fixing this bug? it’s been two years and customers are still complaining”
- Engineering: “we can’t touch at this component it’s a mess but we are rewriting it, this bug will no longer exists and it’ll be so much powerful, just wait a few month”
We all know how it ends. And when business pressure comes because it failed to deliver it’s all “business is evil we need more time to do great software!”
What we really need is senior and experienced engineers IMHO
I agree with you, and this is a hard lesson to learn. But I don't think it's necessarily a bad thing.
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.
I’m a web developer in my spare time. I write little things that solve problems in my two day jobs, they haven’t tended to be pretty because often I’m learning as I go and when it works then it’s truly time to move on to the next problem, even though I now know enough to solve the old problem again more elegantly. I’m trying to use better practices and modern JS frameworks in new projects just for experience, even though they are actually overkill in many cases. Certainly the people I work for would rather have two useful utilities written in plain es5 and php than one useful utility plus a story about the code quality. I’m gradually finding the middle ground where somebody call look at my code and not instantly want to take a shower.
You're forgetting about ethics. Even if your boss doesn't care about security, if you want to be a decent person, you need to at least try to prevent your system from becoming a tool to harm others.
Hanlon’s razor comes through in full force.
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.
I already have issues when I see something but I know no-one is going to pay to fix it, so what can I do? I report it, no-one cares; I might be able to fix it but then I do this for free.
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).
I'm normally on board with Hanlon, but "infosec idiots" who fail to educate themselves on basic security principles are guilty of negligence at best. There's no reasonable way they don't know that security is a real concern, so they should be looking into it. If they still fail, then we can go back to Hanlon's razor.
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.
> Software should really only be measured by the value it provides.
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."
Yes, the "software should really only be measured by the value it provides" attitucde is kind of the key problem we're facing in a whole lot fields.
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.
This, ironic enough, is my main motivation to improve my software development skills, from algorithms to system design to development patterns. Because, like first impressions, the first write is the most important. If it's done well the first time around, the true risk of missing an improvement upon the next iteration is significantly lowered.
Edit: also the reason I'd like an ongoing education in basic security for app devs
This is what I call the Mediocre Mercenary Mentality, this idea that "as long as we can make money off of it, it's good enough".
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.
I have a feeling you dont have much experience on working on other peoples code. You have just bundled all kinds of issues into a bucket of "buggy piece of poorly written code". Some of these are outright security vulnerabilities and some make you wonder how was the bug not found so far. Sometimes fixing these issues require a heavy rewrite which cannot be justified as a bug-fix. And how do you justify playing with your customers data by "slapdash jquery-and-duct-tape" techniques.
"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)"
But those bugs could easily lead to mistakes in the output.
>as long as it does not kill the customer
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.
Totally agree. But the only way for software people to take any power or control (really, for any worker to have any say in the business at all) is to unionize, and us tech folks tend to treat that like a curse word.
Bad example.
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_recalls https://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle...
> The sooner you accept this, the less likely you'll burn out.
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.
It was a simple performance bug (think N+1 query type) that was trivial to implement and trivial to be confident about its behavior vs the pathological implementation, and I used the normal channels for shipping it, it passed QA.
The only "clandestine" part is that I added the split test, and did some work outside of the set of features that was scheduled.
We had no policies around SLA, developing off-site, security or restricting sensitive information (think potential FERPA/HIPPA violation) which are yet other "non-features" that I tried to get them to adopt.
I implemented this entirely above-board, with more precautions and consideration than were taken by other developers on that team for the day-to-day.
I don't think the phenomenon you described, as some new thing specific to this age, is in any way real. If anything, the things you mention only reflect the new choices we have. Going over your individual examples:
> 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 sounds like you'd burn out in any profession. Perfect is the enemy of the good. If you're holding your work, and that of others', to a perfectionist's standard, then you're just causing yourself unnecessary stress and anxiety.
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.
> Most of those bugs and failures you listed are really inconsequential in their contexts.
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.
> Ashamed that someone else's system doesn't work? I can't help you there. That's some deep psychological issue.
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.