> Well, first you’d need every worker in the factory—I mean, the tech company—to be a predictable, consistent cog in that machine. Then you’d need to be able to measure their performance.
That's part of the problem from what I've noticed. Engineers performance is not measured against the application of computer science as much as how much they add value to the business in the short term... since in the long term there is strong indication that good engineering always adds value (i.e. by reducing bugs, making software more performant, more reliable, etc).
I have no sources but I think it's easy to see that bad software costs companies a ton of money and it also makes or breaks a lot of startups, and one symptom of this is how engineers get yearly reviews that are based on soft skills, how many other people you manage, or how good of a job you did communicating the project status and planning.
It seems to me the business side of companies takes over the entire culture of the company and everyone needs to think in terms of customer needs and whatever makes profit... but ironically this may be leading to poor engineering practices that are hard for engineers to deal with because they have different kinds of priorities and a different kind of mindset.
> It seems to me the business side of companies takes over the entire culture of the company and everyone needs to think in terms of customer needs and whatever makes profit
Yet a lot of times engineers do help make profit, e.g. optimize the application or infrastructure often savings thousands to millions of $$$. It doesn't earn them a good pass at review though.
Yes that would be a shame. I think usually those changes do get recognized but perhaps for the wrong reasons. While it's fine to recognize how much profit the business is making, the engineering role should be recognized for how well the system is implemented and working. It's a subtle but important difference. I have seen so many teams with talented engineers yet they produce brittle code that breaks all the time and is hard to develop, and I suspect it's because they're constantly thinking about how their changes will add business value instead of how well the system is being engineered (which should indirectly add that value anyway).
> That's part of the problem from what I've noticed. Engineers performance is not measured against the application of computer science as much as how much they add value to the business in the short term... since in the long term there is strong indication that good engineering always adds value (i.e. by reducing bugs, making software more performant, more reliable, etc).
My suspicion is, this is because from a business perspective, improving the quality of software is only one way to secure revenue, out of several, with others potentially being cheaper.
A business person might ask an engineer "so we have this technical debt that you request time to fix. What happens if we don't fix it?"
The engineer might answer: "well, the software will perform worse"
Business person: "...and?"
Engineer: "This will make the experience worse for the end users."
Business person: "...and?"
Engineer: "They might leave?"
Business person: "They can't leave, the software was purchased by their managers, not them. They have no agency about this."
Engineer: "Ok, but they might complain to management and the company might not renew the contract...?"
Business person: "Lol, the company just completed a 6 month, $500.000 data migration and rollout to integrate our software with their existing systems. Like hell they'd throw this away because a few case workers are unhappy."
Engineer: "...oookay... but they might complain on social media and give our software a bad reputation?"
Business person: "Yeah, I'll let Marketing handle that. Request denied!"
Sure, you're just outlining the details of why software companies are ok with bad software. There's nothing inherently wrong with that, but it does mean we get more bad software and bad user experiences as consumers.
Everyone is free to build bad software, but I believe that it only happens because the true value of good software is really hard to measure (since it involves comparing against something you are not going to build).
That's part of the problem from what I've noticed. Engineers performance is not measured against the application of computer science as much as how much they add value to the business in the short term... since in the long term there is strong indication that good engineering always adds value (i.e. by reducing bugs, making software more performant, more reliable, etc).
I have no sources but I think it's easy to see that bad software costs companies a ton of money and it also makes or breaks a lot of startups, and one symptom of this is how engineers get yearly reviews that are based on soft skills, how many other people you manage, or how good of a job you did communicating the project status and planning.
It seems to me the business side of companies takes over the entire culture of the company and everyone needs to think in terms of customer needs and whatever makes profit... but ironically this may be leading to poor engineering practices that are hard for engineers to deal with because they have different kinds of priorities and a different kind of mindset.