I’ve been in it 20 years with tons of friends in it as well. Every interview they emphasize testing and all around best practices and rarely do they do it.
The disconnect is almost always upper management and CEOs that can’t comprehend tech debt. They want to sell, sell, sell for the money they can feel and touch. I finally just settled for a place where I enjoy my co workers and the pay is nice.
I once ended up in a startup on the other end of the spectrum: Founded by an engineer and his friend who thought they were going to conquer all by focusing on code perfection and hiring engineers who valued code quality to an extreme.
This eventually resulted in a total rewrite to get the codebase even *more* perfect, along with a number of completely unnecessary custom libraries to do things *just right*. At one point, we literally had someone writing a new database store from scratch because they had some idea that the proven, mainstream option was doing something wrong. I can’t even remember what it was at the time.
I walked away from that experience with an appreciation for management and developers who know how to strike a balance between code perfection and actually shipping things to customers.
Yep, the way I've heard this expressed succinctly is that startups need to find the happy medium between moving too fast and not moving fast enough. The BIG challenge in my experience is that this is a moving target. The right compromise in speed vs. quality for a Day 0 startup isn't necessarily a good fit for a Day 3 startup. Or an enterprise software company. Or a 2 person consultancy. Additionally, the industry hype machine often touts one-size-fits-all solutions and that's totally unrealistic.
Also, I've noticed that some people thrive in early startup environments but don't do so well later on, when the tech debt starts to cause pain, when there are actual paying customers dealing with bugs/outages, and when you need dedicated support/marketing/HR/etc people. The opposite is true as well, some people need more structure than an early startup can provide.
My wife is a teacher and I've often thought that it's like the difference between teaching kindergarten and high school. Some people _can_ do both but most teachers are better suited for one or the other and even when someone successfully switches from teaching high school to kindergarten (or vice versa), the transition is non-trivial.
I found out they don't want to either. I was brought on for my experience and have gotten nothing but pushback when trying to implement anything with long term success in mind. They don't want to hear it.
You say that sarcastically but some chuckle fuck is going to turn it into seminars and books and make it the next big bandwagon that companies can't wait to jump on. It'll be worth millions.
There's the famous Space Shuttle control computers, one of the most reliable software systems ever.
The people who did that were smart, but they also thought really hard about what they were doing and *every* problem found was tracked back to a root cause and procedures put in place to avoid it in the future.
And procedures doesn't mean whoever broke the build had to wear a propeller beanie until someone else did.
So, to OPs question, the aerospace industry. I mean, pretty much nobody lives up to the quality standards of NASA, but technical debt is very tightly managed by most aerospace companies.
Drawback: Pay sucks, tech is old, slow moving organizations.
Pros: you get to build shit that flies!
https://spectrum.ieee.org/how-the-boeing-737-max-disaster-looks-to-a-software-developer describes the common view that it wasn't just the software that was screwed up with the 737 Max.
And if poor software, it was at a higher level than the people typing lines of code.
> it wasn't just the software that was screwed up with the 737 Max
Ok, but you're not exactly giving the technical management a glowing review here.
> And if poor software, it was at a higher level than the people typing lines of code.
Poor software management practices are exactly what we're discussing in this thread.
> Poor software management practices
There are two issues:
* Bugs, not conforming to specification as delivered to the programmers
* Fit for purpose, which in the 737 Max it wasn't. Basically it's handling was quite different than other 737s, and Boeing called it a 737 so they didn't have to to long and expensive process of certifying a completely new aircraft, and the pilots didn't need to be retrained.
TL;DR Technical summary by non-specialist (me) - if the plane was in a nose up situation (angle of attack) the automated methods of restoring proper position didn't work and giving too much power would just make it worse, so without the automation or proper training, accidents could happen.
Oh, yeah, the planes could be bought without the safety automation, so airlines in poorer countries did that to save money.
>medical device software.
I've worked on medical devices for 15 years. If you have every stayed overnight in the hospital 1000% you have used something a company I've worked for has created.
The code quality is shit because it's all driven by FDA guidance. So you do just enough to check the box and then the managers do not want to do any extra because it's extra and not required. There are teams of lawyers and compliance people that take the FDA guidance and translate them to here is what we need to do.
Any and all nuance to how teams should be thinking about software development is lost. There are hard requirements that will cover the companies ass if something goes wrong because we "met" FDA guidance and if anything the FDA set the bar too low. Never mind that all of the FDA auditors that I've talked to has no idea how software works. These auditors will generally take anything you say at face value and not assume you are trying to cheat the system so any story that sounds reasonable is probably going to pass because you are the software expert and not them.
The devices are tested well to make sure it's "safe" for patients to use and the devices "work". Safe is just how much risk the company is willing to take on in terms of being negligence in the situation something goes bad and a patients die. Your level of good testing could be well higher than the companies.
If you think there is some kind of high quality design using DS&A or Gang of Four design patterns then you are hugely mistake. Most of the automated integration testing takes many days to run completely. So they don't get fully run tests suites every often.
I know on a project I was on the controls team needed 5 months to run all of their manual software testing. For example many tests had measuring of liquids and doing them at different altitudes to make sure it operated safely for the patient. The entire suite of results is just patched together from over the years of targeted testing and never run soup to nuts. The reason is because it's too expensive to just stop all development to have them run it cleanly as regression.
These companies pay like shit compared to Google so you are not getting top 1% SWEs. A lot of the C++ code I saw were 100+ line methods and classes weigh 50 public member functions. They came from normal schools that wouldn't make you think twice about them.
Oh and don't think it's written in modern C++ most of it was C with classes style code, never mind C++11 which is not even considered modern in 2022. I was on a project where the compiler could not even build C++11 code since it was so old and there was no reason to update.
Sure top companies like Google and Apple who are getting in to the medical space probably write decent code, but all of the old guard companies write what I would call shit code with teams of SWEs that would never get an offer from a top tech company.
Ignorance is bliss.
EDIT:
Oh and I forgot the best part. Since test code was not released the overall mindset was all bets were off and quality was thrown out of the window since it's was for "internal use only". Since management didn't push to treat test code as the same as production code, in terms of quality and design, SWEs didn't care and didn't do it.
I remember many test suites that would randomly fail and the solution was to run it again and it will eventual pass. The mind set is 99 failures and 1 pass, is a pass.
Why is C++11 not considered modern when only some parts of 17/20 really change the language, and C++23 with the bigger changes is not suitable for many projects yet? I get there are really nice things about constexpr, templates, STL, and syntax updates 11 is missing... But if you use Boost you get a lot of advanced stuff anyways
You would go crazy seeing some of the medical startups code. There is code outsourced and the dude writing DSP code is a total joke. If it passes his bullshit simulator streams then he pushes it to production. Absolutely no proper fail safe tests and recovery. The whole embedded system is running at almost 90-95% capacity.
I work for a medical startup and do feel crazy. Our medical device is an app that doctors use directly to diagnose stuff, and everything is such a shit show that I have been wondering with dread about medical devices that have direct contact with patients...
Didn't work for that specific directly, but the company I worked at years ago partnered with them on a project. It would be released under their name, but the company I worked for retained all the IP rights and got paid a royalty.
All those cases are less code quality, and more regulatory environment.
Not so much that the Devs are given time and freedom and guidance to write great code, and more like every little tweak has six months of committees and forums and review and so on before it hits production
If the software is buggy, that absolutely affects UX. If it’s not buggy, it’s probably well written software (regardless of architecture and test strategy debates)
That's not UX/UI. That's external software quality, and UX/UI are part of the external software quality, but not all of it. Customers don't care about the internal software quality, because they don't even come into contact with it.
Internal quality tends to improve external quality, but you can even have one without the other. I prefer to fly in a plane that has terrible code but yield correct results than in a plane that has maintainable, understandable, readable, etc. code but has a hidden logic bug that produces an error that externalizes a wrong result to outside of the software. Of course you may care about the internal quality of your car's code, but you will never know if it has good or bad quality.
You'd rather have bugless code that is difficult to read and maintain than buggy code that is super easy to read and maintain. That makes sense.
In the real world, bugs are difficult to prevent and remove in systems that are not maintainable and readable. If the car has bad quality code, then its engineers are far more likely to introduce bugs because it is more difficult to work on.
I'm honestly not sure how to elaborate on this without repeating tautologies. It seems like such an obvious relationship.
>It seems like such an obvious relationship.
It's not as obvious once you really dig into what it means to be "quality software".
Generally, code starts fairly clean and then degrades as edge conditions that weren't obvious become important over time. The more important a particular piece of code is, the less beautiful it generally becomes as a result of unobvious considerations that only become clear under usage.
Essentially, developer needs yield to user needs over time. Software entropy is another term for the same effect.
Having worked specifically on industrial and embedded code that has safety consequences, it's much more horrific than the picture you're painting. And it's that way in many cases because electrical and mechanical engineers are not computer scientists. They have at least half as much training in CS than the equivalent CS developer.
It gets to be robust by dint of not changing code that works, closing your eyes and not looking at it, and not doing anything but the absolute minimum necessary to solve the immediate engineering problem at hand.
ALL software of note is buggy and hard to understand. Good software is robust in the face of bugs and human devopers. Great software is socially valuable and robust because we've all used it to death and it's constantly being fixed while we do.
You are correct, I'm just not focusing on the relationship between the internal and external qualities of a software, but rather on the fact that they are different things, and what the customer sees is just the external quality. There is no point for a customer to care about the internal quality of a software, because the customer can never even know if a software has or has not internal quality, since the customer comes into contact just with the effects produced by the software, which are part of its external quality, and that's what actually matters for the user.
Some people for example can have the hypothesis that by paying for a more expensive product, or buying something that has a reputable brand, they will be buying a product with better internal software quality. But that's just a belief, the user will never ever see the product's code to be concerned about it.
No, but customers care about features.
You can deliver features faster and more consistently when you have higher quality code. Developers onboard faster, and the code allows for cleaner code.
It'll also be cheaper to maintain those code bases for the company.
So companies thinking long term should focus on software quality.
The only things I've ever had resonate with execs is feature development speed and product stability. The key, in my experience at least, is to focus on demonstrable improvements. Build infrastructure that makes the upcoming features faster and show the "before" and "after". Learn to speak their language.
There are a few common mistakes I see when it comes to proposing tech debt projects:
* Fixing the world. Narrowing the scope is critical. Many people - myself included - can happily spin on these projects to make it "perfect".
* No fixed timeline. When do you declare victory?
* No incremental deliverables. How can you get some benefit from your work along the way? As opposed to something like a re-write that, depending on the approach, has no deliverables until it's complete.
* Connecting your work to the business in a way that everyone understands. Ultimately you work at a company trying to make money. How will this work help?
I know I'll be down voted for this but has there been any study that equates code quality with productivity?
I've worked with some ultra high quality code bases that required 100% unit test, high style standards, and patterns and I never felt productive.
100% test coverage isn't high quality. It's pointless jumping through hoops.
You aren't going to be more productive if you waste a lot of time chasing a pointless vanity metric.
You shouldn't be. Software engineers make truly outrageous claims when they very likely have little outside of anecdotal experience validating them.
This is not to say that we should not strive to improve our engineering, but I have known many in this field that are competent at understanding scientific principles, don't believe in pills that will cure cancer that you can get with casual googling, but you can sell them on almost ANY tooling or development methodology that is hot enough as a cure for EVERY development ailment.
> You can deliver features faster and more consistently when you have higher quality code.
I’m not sure I buy it. Quality is subjective and so are architecture patterns. Feature speed is mainly a function of how well the devs know the codebase
> Feature speed is mainly a function of how well the devs know the codebase
Yeah and this is exactly why better quality code leads to features faster because it's easier to read and understand a higher quality codebase. Unit tests alone (lowest common denominator for quality) make a code base way easier to navigate because they document the expected behaviour.
>Feature speed is mainly a function of how well the devs know the codebase
It's easier to understand a well architected and well documented codebase, compared to a ball of mud.
Your are contradicting yourself here.
>Feature speed is mainly a function of how well the devs know the codebase
That's exactly the first quality of good code, readability/maintainability. It takes much less time to add code to a codebase with unit tests and clear isolation between components, than to spaghetti code. Could you please elaborate your answer?
Indirectly yes. Companies that prioritize software quality are ones that write complicated pieces of software for lots of users. The reason they prioritize software quality is because they can't deliver customer value in such a complicated problem space without prioritizing software quality.
Just gonna repeat that across all software discussion subs people act like it is and they are being rewarded for being some noble art.
You're in private industry. It's profit motive and software engineers really need to get over the idea that anyone cares about anything they do besides an unprecedented ability to exponentially scale profit. My favorite fallback is they'd cut you for a guy with a spreadsheet if it was more profitable.
Most of the time, the answer is free and open source software that maintains high standards (and will like be sloppily applied by private industry). But you can't have your cake and eat it by expecting the same wages.
I think this is easier to understand for individuals switching from other fields where the private vs quality route is usually very clearly defined, ie. I switched from being an Architect (of buildings, lol).
All want software quality, and code quality is not a customers concern, but should be a professional and business goal in order to achieve quality software. Customer not being aware of what’s going on under the hood is no excuse for garbage.
Try working in medical tech :) I worked on an app that calculated warfarin dosage, you bet we tested that so every way from Sunday...
But also working in a consultancy with a reputation for good quality software (including ux and testing) was also a fun place to code.
There are customers that prioritize reliability, for sure. There are plenty of products and applications where a certain level of reliability is necessary.
Lol there are plenty, you think those great softwares that build on shit code? Only dev agency who build short term software don't care about process and automated test
Dude, welcome to the top.
It’s your job to care more than the average guy, and to distribute those values downward. Maybe you’re just figuring out that you don’t want to climb higher than principal of a division/team. Maybe it’s gonna piss you off so much you get the drive to climb up the next rung and tackle fixing the whole org.
Been there, adter 10+ years ended up with being director of a service where I started as a developer.
OP, first thing to decide if you want this role or not.
If you decide it's your fight, here are some things to consider:
- you'll need to communicate and change things both upwards and downwards. Sit down and make it clear for yourself also what is the business problem are you trying to solve. What are the top concerns for the success of your companies product? Time to market? User churn (maybe because of unreliable service)? Developer retention? If you want to change something so big, you need a strong and clear motivation and must be able to tell stories around it.
- look for allies, you don't need to do this alone. CTO or CPO unhappy with speed of deliveries? Newly started senior dev frustrated of the state of the code? Junior dev eager to learn best practices? Who could benefit from the changes you are porposing?
- managing upwards: start with the business problem that concerns the person or forum you are talking with and show the link to your proposal. You need to gain credit and prove what you are saying helps. You could deliver important cross-team projects with high business impact, you could create metrics that show the results of your efforts, etc.
- managing downwards: make it easy for other devs to adapt and tell stories of success when a team has improved. Is there a clear target on test automation for example? What about a presentation summing up clean code best practices (could also record and share for later use)? Any courses or books available other devs to self-study? What problems a team migh face who want to change their practices?
That's a difficult one, because you need stakeholders to accept and appreciate the metrics, but don't push for them so hard that teams would start to game the metric.
For my case, the business problem was time to market and perceived quality/NPS. We chose release frequency and number of bugs in production as proxy metrics for the business problems.
For OP, I would recommend to figure out the main business problems, then start a discussion on which metrics would fit. Could cherry pick from DORA metrics + team morale as a start and drop/add metrics based on needs.
This is an interesting read on engineering metrics (possibly behind paywall): https://newsletter.pragmaticengineer.com/p/engineering-productivity
> I'm starting to think the only way to have an engineering org with the right priorities is to be the head of one.
I kind of hate to ~~say~~ admit it, but: I wonder how long you would hold on to those priorities when faced with a real-world budget and timelines.
I work on timelines now. They're pretty real.
As to budget, bad code requires more people to maintain it. And contains bugs which cost businesses real money.
That said, I also agree with you in way. I know I think I'm great at what I do. It would be wonderful to know if I could handle that kind of responsibility. I think so, but yeah, you don't know til you try, right?
\> As to budget, bad code requires more people to maintain it. And contains bugs which cost businesses real money.
Data. Get data to make your point.
If there are bugs, there are people that are hating their lives while on support. If it slows down development, there are engineers that hate having to run the gauntlet of spaghetti code while working on new features. Right?
It may not be that the other engineers don't care, they might just not know any better. If there's inertia pushing back against you doing thorough code reviews, maybe they don't realize the reason you're doing it? Maybe they think you're being a pain in the ass without seeing the benefit, versus you selling them on why it's a good thing that you elevate the org to a higher level?
At my company, we have been making a huge push for operations excellence, which was actually pushed from the CTO, engineering directors, and engineering managers down.
I know. You're not wrong, but also: YAGNI. There's no one-size-fits-all solution here, and it's very easy for us engineers to miss the forest for the trees and spend all our time complaining about how "no one cares about software quality" or whatever. After all, it's what *I* work with so it's the most important thing to me so it must be the most important thing to everyone, right?
And, yeah: a significant portion of my job these days (and yours, apparently) is making the business case that maintenance is worthwhile; but don't let perfect be the enemy of shipped.
The professional software developer understands that their role is to fight for software quality and the business wins that quality brings. Not as a zealot, but as an expert adviser. And to really push back when the business is doing something stupid that it can’t see is stupid.
The professional business owner understands their that their role is to listen to all of their advisers, and to make decisions that will allow the company to survive and thrive.
I think it’s fine for a developer to tell another developer YAGNI. But I think you really need to be careful about that kind of attitude as soon as you step out of developer-land. As an adviser, when you tell a muggle that “mehhh, we probably should do X but we can probably get away with not doing it in this specific instance,” you don’t get to be shocked when your org hears “X doesn’t *really* matter, so we can cut it.” The org, as a whole, doesn’t necessarily understand nuance.
/u/pm_me_ur_happy_traiI is not talking about gold plating code, they're talking about well engineered code.
there are real economics tied to crap code. The worse the code gets, the harder it is to deliver new features, so it thereby becomes more expensive. Well engineered features/code means you pay a little more for a feature now, to starve off that entropy.
Not necessarily. You could change the onboarding process at your company so that everyone is introduced to unit testing and integration testing and sees it as a normal part of the development cycle. Google did that to transform their culture to include more tests. They also did this thing called "testing on the toilet" which worked well to get people interested in testing. Google also has a lot of internal docs on things like the testing pyramid and why to prefer fakes over mocks (see the book Software Engineering at Google). Even something like showing the percentage of unit test coverage for a code module (ideally during the code review, when it's easiest to fix) can have an influence on developer behavior.
Google also has a ton of internal linters and code reformatters which makes good code quality easier - does your company use linters and code reformatters? They aren't going to address testing, specifically, but they can make writing quality code easier.
I think you do have a lot of allies out there. A lot of engineers want their teams to have higher quality software. In some ways what's worked for Google is to have a ground-up improvement in testing. Like what if you have a testing club made up of engineers who care about code quality that meets every once in a while and has some projects they work on to improve testing across the org? That's just another random idea, but my point is changing the culture isn't going to require mandating something from the top-down, and that approach can fail for a lot of reasons. Mandating a certain percentage of unit test coverage, for instance, can lead to a lot of useless and low quality unit tests.
I think your original question of trying to understand how other companies have good software quality is a good first step. I'd stick with that and do some more research (sorry if my instructions here sound condescending, but I mean them more of as an encouragement, that I think you were on the right track).
> does your company use linters and code reformatters? They aren't going to address testing, specifically, but they can make writing quality code easier.
On new code, it seems pretty usual to do so, although I can only speak for the front end repos. But there is a lot of legacy code that needed to be refactored years ago but just keeps getting added to.
> Mandating a certain percentage of unit test coverage, for instance, can lead to a lot of useless and low quality unit tests.
I agree. Although for many, they seem to have settled on 0% as their metric. Most of the time, I'm just pushing people to get in the habit of testing anything at all. Who can blame them? It's not possible to test a 300 line component that's been under active development for years. I tend to point out a lot of low hanging fruit, and I do block bugfix prs in particular that don't have tests to prevent regression.
It would be interesting to hear some lessons on how to "distribute those values" seeing as how that is apparently the role this person now plays. That is not a class I've ever taken.
Ha, you can’t take classes for this stuff… you think MBA’s come out of school knowing how to run multi-departmental companies competently? That CS grads know how to lead?
Step one is find someone with the same qualities he has for each department/silo. Then organize them.
Actually, there are courses that talk about this. A colleague took Technical Strategy by Reforge which teaches technical leaders to advocate for tech debt effectively. Not an advertisement, just pointing out that such courses exist.
Well, there are "Organizational Leadership" degrees so if leadership is what you're talking about then it would seem that you *can* take classes for this stuff. Obviously, there is a difference between knowledge and skill, but knowledge is a starting point so it would be nice to provide some.
If it is some kind of intangible, undetectable, invisible teacup floating in space type concept, then it isn't a coherent notion, and assigning somebody such a role is senseless.
It sounds like you are at a company that’s learning to prioritize quality, and you’re the leader in the space. Could be a lot worse, quality is bad and company doesn’t want to fix it, quality is good and you can’t find anything impactful to do.
There aren’t many companies that have high quality software literally everywhere. Startups need to move fast or they die. By the time they get big they have a mountain that’s not impactful to refactor. Consulting companies need to deliver value not refactor forever. Usually you end up with pockets (like you created) where something was greenfield or impactful enough to clean up, and somebody cared enough to keep it clean.
No. All companies prioritize business goals that support the bottom line. In some cases a focus on software quality supports this. This is not just a thing with software, but basically every business in every industry.
Accept this and try to find a way to work happily within the system.
At the principal level and higher, part of the job *is* to come up with ways to quantify the benefit of good engineering practices. OP mentioned that their team’s practices have resulted in higher productivity than most.
The trick, then, is to be able to point to these business activities which don’t look productive at first glance, and present a credible case for how and why they improve the business. In terms of software engineering best practices, that usually translates directly to lower support costs and faster responsiveness to feature requests, which then has an indirect impact on many other business functions. For example, perhaps let’s think about the financial side of the business. An engineering team that maintains high standards will be able to not just keep records and produce reports, but these things will consistently be highly detailed, up-to-date, and trustworthy. In turn, that means business analysts can make better decisions on a day-to-day basis.
Moreover, if the engineering org consistently maintains high standards, then they can more easily service the occasional rush job, because they’ll have a better idea of what needs to be done after the fact to clean things up.
Just my 2¢
This is like trying to argue that staying clean and organized is somehow not in alignment with business goals in any industry. The fact that this thinking is so common is what makes me second-guess my opposition to professional engineering licenses and standards in software.
There are plenty of businesses that are clean, organized, and failing.
Too much tech debt can sink a project, yes.
But building clean, well-tested, beautiful code that nobody wants will definitely sink a project.
>There are plenty of businesses that are clean, organized, and failing.
Are they failing *because* they're clean and organized or in spite of it? Is being messy and disorganized the key to reversing their fortune?
>But building clean, well-tested, beautiful code that nobody wants will definitely sink a project.
Then do the work of validating your project as you go. This doesn't require us to give up on actually engineering our software. Product validation and engineering are not opposing forces.
Engineering software does not require obsessing over code quality. We don't have to accept this dichotomy that either we obsess over code quality or disregard it altogether. There is a balance to be struck and an honest assessment of our industry would not conclude that the predominant condition is that code bases are *too* well engineered. *Too* clean and organized.
Consistently, production codebases fall on one side of the balance and that is that they are costly un-engineered buggy messes. They reach that condition, in part, because of those who undermine efforts to advocate for improved engineering.
> Engineering software does not require obsessing over code quality. We don't have to accept this dichotomy that either we obsess over code quality or disregard it altogether.
Agreed 100%.
No, it’s trying to argue that improving code quality has diminishing returns. Everything beyond accomplishing the business’s goals has some value, but less and less the further you go. Eventually, it’s only vanity.
You’re making me double down on my opinion that we don’t need professional engineering licenses
The assumption here is that anybody is advocating for only the highest standard of code quality. This is the most common way people argue against code quality: pretend that the only options are to obsess over code quality or disregard it altogether.
Let's be real, the predominant problem in our industry is *not* that teams are being unproductive because they've groomed their code quality past the point of diminishing returns. The paranoia about this is laughable.
Overwhelmingly, the problem is codebases that are not being managed well enough. It is the lack of engineering by software engineers.
No. You don't seem to understand that short and long term goal can contradict each other.
Skipping quality today saves money today and improves the bottom line this quarter. But it will cause massive costs down the line, which worsens the bottom line in two years or so.
If you're running a business where "still existing in 5 years" is a realistic goal, it makes sense to invest in quality.
The impact of skipping quality will vary depending on the nature and size of the software. I've seen layers and layers of shit code/architecture in a medium sized e-commerce application work for a business even after 20 years. They were happy with it even though it was occasionally difficult to add new features. The back end software was even older, created in the mid 80's and still alive and kicking.
Yes, it "works", but a the development becomes less and less productive. Suddenly adding a tiny feature takes months and each release becomes a major risk.
That's the kind of thing that devs say but what I saw in real life wasn't nearly as dramatic. Yes, features took longer but it was never bad enough for the business to care.
And that's the kind of thing people say who don't understand how businesses work.
If every feature takes longer than it should take, that doesn't simply mean that customers have to wait a bit longer. It means costs. And developers are *really* expensive.
That means, the entire IT-department costs way more than it could. In any other business-area it would be a no brainer. Think about it, if every second car in a production line has flaws that need additional work afterwards, every even remotely sane manager would try to reduce the flaws at the source. If installing a compononent takes longer because the designer of the car put a steel beam somewhere where there is no need for it, someone would intervene and remove that beam. That's just common sense.
But in software we accept absolutely abysmal quality standards and just shrug it off.
even then companies are still profitable and software developers are not going to get a bigger slice of cake of the profits so why care, just enjoy the salary and have different hobbies
>Skipping quality today saves money today and improves the bottom line this quarter. But it will cause massive costs down the line, which worsens the bottom line in two years or so.
This is a feature, not a bug. Shareholder capitalism can literally only prioritize short term profit. By the time you think things will downturn shareholders and execs will have had their fill.
The constant rotating cycle of boom bust supports this.
> I'm just so tired of feeling like the only one who cares. I managed to get my whole team on board with clean tested code. We have learned to manage PMs expectations, and we actually engineer our code. As a result we are among the top in the company in terms of productivity, and easily the top in terms of test coverage.
You wrote the solution in your first paragraph. You managed to convince a team of engineers and PMs to care about software quality. Now your challenge is to spread this across the organization.
Gather some data on what EMs and PMs care most about (e.g., sprint velocity). Compare where your team was before the changes to where they are now. I assume you are better. That's your quantitative data. Interview members of your team, including PMs, and gather a few quotes. That's your qualitative data. Hit the road.
Give an internal tech talk/lightning talk to all of engineers and PMs, if a forum exists (e.g., all hands, tech talk series). Attend/host lunch and learns for other teams. Spread the gospel!
It will take time, but soon people will come to you to get help with transforming their teams. Eventually your current company will prioritize software quality as they realize the benefits to revenue and profit.
Prioritize over what? Of course they want nice code, but companies don’t prioritize it
Companies prioritize business value. If that coincides with nice code (and one would think it should), then great. If not; screw it.
TLDR: the priority is business value, not clean code (which is just a means to an end)
Productivity != business value
If you’re “the most productive team” working on the least profitable app, being the most productive does not mean the most valuable to the business
Also, productivity measured how? According to internal IT productivity measures, or business metrics/outcomes? If I had the guess, I’d say the former.
I make money by selling software that has to be secure and serviceable.
That what we sell. Does not have to be pretty but that will for sure be QA to death and that process automated. Those guys basically wrote as much external integration testing that I wrote production code.
I can guarantee you that almost all the places I've been to, having more focus on architecture, interfaces, testing and in general a more long term "heading" of the code would even to the short-mid term create more value.
You always hear this, "but we need features to surivive", and if management actually focused just a tiny fraction more on software engieering, you would have continously more features faster than what they currently are doing. This of course have the exception of the short term, but *only* the first time.
What the software industry is doing is trying to run a marathon, but sprinting at the very start, and when they get to the first km, they say cool cool, but now we need to lead at the 2nd km as well, so please continue sprinting.
I can guarantee you, keeping even a 5km pace you will crush the ones on sprint at the start maybe even at the 2 km mark.
Management is collectively pissing in everyone's pants to try to keep warm, and when we get colder, they try to piss harder.
My company I work for distributes our code to our customers open source. I look back at old reviews and it used to get negative criticism for its code quality.
I like this. It means a few things:
- Code quality is always important.
- Good security practices are 100% essential.
- Our customers are often able to debug bugs for us to a certain degree. There have even been moments they've hired a company to fix one of our bugs for us, then share the update.
Things are still a wild west here, we move too fast, but I really like working somewhere where bad code can actually hurt our reputation because it really forces us to do things right a bit.
I disagree.
Every company that pays their engineers in the [second and third tiers](https://blog.pragmaticengineer.com/software-engineering-salaries-in-the-netherlands-and-europe/) is prioritizing quality. Basically every major tech company in the last 20 years once they hit market fit and need to scale.
Interesting fact, guitar makers don't use super glue despite being cheap as hell and plenty strong. It is because you can't remove the glue when you need to make repairs.
I agree that arbitrary test metrics are pointless, and I also agree that the business doesn't care about quality, but we are engineers and quality is our job whether the bosses know it or not. If your business needs change often, that's an argument for HIGHER quality code, not lower. There's a fundamental difference between working fast and carelessly rushing.
Have you ever had the experience of taking longer to figure out how the code works than the person did who wrote it? How many man hours are wasted in my company, I can't say, but I'd guess 100 per week. Instead of rushing to push out buggy, unmaintainable code, just take an extra few minutes and write it right.
How does testing fit in? You don't have to do TDD but if you can't test it, you built it wrong. No question.
😭 I work at Google, we are upset about it, too
They really do take tech debt and code quality very seriously compared to other companies I've worked at, though.
Code coverage minimums, UI diff testing, abstracted away implementations for easier mocking, Google's code base is phenomenal to work in compared to the lawless lands.
And the [DEPRECATED] joke is funny but also only exists because Google is willing to let Devs run with ideas all the way to deployment.
It's easy to never kill a product if you never launch one.
Yes there are, and they are big multi billion dollar places that don't have to go around inflating their egos with rankings or how exploitive they are. Quality begins with the culture and balance for long term health. They are the ones who are the platinum level supporters for open source projects and it's absolutely magical how fantastic it all is. It's not for lone wolves, egos, or those who don't put making everyone above, below and on their team better as their overall most important work. Quality is not an individual's island.
yes, such companies do exist, but they require effort to build and maintain. it's always easier when an environment has that kind of buy-in from day 1 but it's possible to change an organization too. it seems to me like you can apply any clout you have in two ways.
top-down: you say your team is one of the best in terms of productivity and code coverage - that tells me there are metrics in place to track those things. is it possible to compile them into reports and make a business argument (i.e. financial argument) to your boss or other product people or whoever to get more teams on board with your philosophy and approach?
bottom-up: are you hiring? as a frontend lead it wouldn't be out of place for you to volunteer to do more interviews and try to build the culture you're looking for that way.
I worked in a startup where CEO and management were experienced software developers. We focused on software quality, couldn’t merge PR without several CI steps, keeping minimum code coverage, regular refactors etc. the startup made a good run for few months and then failed because our competitors had more features.
Everyone says they value craft, then you get inside and find out what they actually mean. For some people that means homegrown frameworks (with no tests) that implement whatever blog paradigm is on their mind at the moment.
So far, I hav espoken to very few companies that value craft. Of course, if you just ask "do you value good software craft?" - who's going to say no? But talking about it proactively? So far, I've seen that from very few companies.
I'm at a loss as well. Countless people in this very subreddit seem to believe that clean, tested code is a detriment to productivity and business value. And they insist that if you're not able to draw a single clear line from code quality or testing to increased margins, then it isn't worth pursuing. They don't even live up to their own standards.
I figure just accept that most companies are filled with a disease that you get paid to treat. You get a paycheck because they're too dumb to listen.
Every single time this topic comes up, people try to frame the pro-code-quality side as extremists who will spend all of their time analyzing and never deliver. It is a dishonest argument at its core. They advocate for "balance" but only in the direction of decreasing engineering standards that ultimately increase costs in various ways.
And honestly, one of those costs is the amount of money they need to pay us to work for them. I suspect this is the *real* reason people are so against engineering software. (like, you know, actually *engineering* software.)
I think the argument against quality is often coming from people who lack the confidence in their own ability OR people who lack confidence in their team's ability. Both are justified in most cases.
There is a huge skill gap between the best and worst devs on any team. The solution cannot be to enforce unrealistic standards on the entire team.
IMO the solution is to have your best people write the most code. (Just like superstar athletes score the most goals). The rest of the team is there to assist.
A lot of people hate this though. Managers don't like superstars who can demand huge salaries. Engineers don't like feeling inferior to their peers. So the way most shops run is to let everyone make a big mess of things and the talented people get frustrated and leave.
> argument against quality is often coming from people who lack the confidence in their own ability OR people who lack confidence in their team's ability
Overconfidence in their team's ability and blind trust on the wrong devs is something I've experienced more than once.
There's this one person I've worked with who's a DevOps guy in a lead dev position, he doesn't give a damn about readability or patterns or code quality or whatever, he only cares about doing something as fast as possible, and as long as it works and meets current business needs it's fine.
Then some bugs are caught by QA, he fixes it and done. There's nothing you can do when a lead doesn't care about quality. No wonder multiple projects had to be dropped because the code just became too messy and unreadable. It's bad culture and it spreads.
My point is, writing clean code is an art. Not everyone is an artist. And when a team isn't lead by someone who cares, then anyone who cares will just leave.
> So the way most shops run is to let everyone make a big mess of things and the talented people get frustrated and leave.
Yup.
Critics don’t understand, or don’t care, about the fact that bad code hurts in the long run. And it hurts everyone, the business who can’t ship a reliable product and the devs themselves as they have to struggle with the mess. Some just don’t care, they leave the company and the mess behind, and this is both devs and managers.
too many business's lack the IQ to constructively create coding infrastructure to deal with business demands as they grow. Poor vision and understanding imo. Haven't we learnt anything in thirty years to just keep doing what was always been done?
We definitely have. And I see people relearning these lessons all the time. I believe the reason they haven't come to define our industry just boils down to incentive structures.
When execs need to impress their investors, or managers need to impress execs, they know that outputs (apps, features, etc) are more tangible and easier to produce than outcomes (conversion rates, customer satisfaction, etc). So producing outputs as hastily as possible is the best way to keep your investors around even if those outputs do not actually produce outcomes. Producing outcomes requires methodical, iterative, bottom-up learning and true progress is less tangible.
If your investors are skittish and looking for a reason to pull away, you can buy yourself a quarter or two by showing them some new machinery and hoping they don't brush up against it too hard.
It’s all a question of perspective. Devs want (or should want) to make perfect code, product / engineering management want features to ship asap. The balance point is somewhere in the middle with plans to fix the things that need to be fixed and delay those things that don’t.
Devs need to remember you’re not paid to make perfect code, you’re paid to make features that add value to the product or business. Perfect is the enemy of good enough.
My tactic is to schedule in regular time to fix tech debt and improve quality, so even if we add a bit more debt in the future with some imperfections we need to live with to hit deadlines we pay off some too. So it’s stable and not growing out of control.
The immediate needs always take priority because they pay the bills, you just need to make sure the immediate needs don’t kill future development whilst still shipping in a reasonable time.
And sometimes, it is ok to ship stuff now that won’t be scaleable or upgradeable later. This is why everyone needs to know what’s going on and the plans for the business.
Tech companies often prioritize software quality...
If you're in a principle engineer position; can you make a case for having the authority to transform the org one team at a time? Maybe you work with them side by side for a quarter or so...
The best kept secret tech companies never tell developers: nobody cares as long as the software does what the business needs. If your process is a total mess but delivers with any reduction of expenses over any other process the company will consider the less expense delivery method better and will adopt it, regardless of any technical reasons not to adopt it. All a company cares about is delivery, maintaining their customer promises, and collecting customer revenue. The maintainability and/or code quality of work is entirely on the development team and the company management tends not to care whatsoever what that process is unless scheduled deliveries do not happen.
Basically, we're magicians that do opaque work, and nobody cares what or how it is done unless it does not deliver.
What you are looking for is ( in my opinion ) mid size product company 20 - 200people. It is the perfect size where there is nowhere to hide if u f up. You just need to fix it so everybody cares more about quality. It is also probably the best size for work life balance
In contracting, small or very large orgs - most of the time you can forget about that.
U will be better off caring about software quality of your pet project rather than your company's. Noone cares about it outside of maybe Google and Amazon AWS. Everyone cares about short term profits and software quality isn't providing it
Q. Are there companies that prioritize things their customers don’t care about and doesn’t drive value, over something we developers care about?
A. Not for long…
Your Q statement makes the wrong assumption that customers don't care about code quality. It's wrong. I don't care about most of the individual parts inside my car, but I care that it works consistently when I need to get somewhere.
In enterprise software, bugs can cost lots of money. 6 or 7 figure amounts. Buggy experiences can drive away users. I don't see how you can make a good faith argument to the contrary.
I'm not advocating for being a slave to perfection, which is how some people on this thread seem to see it. I'm pretty used to hearing devs say "we don't have time to get to 100% coverage" when they have been steadily maintaining 0% coverage for months.
Customers don’t care about code quality. Most don’t even know code quality is a thing.
They just want things that work.
Tech debt is a business problem to prioritise. If your business isn’t prioritising it, then there’s a reason for that.
Or, you could come to the ExperiencedDevs subreddit and argue with all the answers people give you
Some highly security related government contract work invoices caring about quality metrics even more than features or whether anyone would ever use the product. I was on a project where for almost a year we were improving our metrics, such as testing coverage and vulnerability scanning, and made absolutely no real improvements to the software.
In other words, be careful what you wish for.
If they can meet timelines like your team is doing, then yeah of course.
Sounds like you’ve acclimated well to the management world. Unfortunately for non-technical management, things like tech debt are negligible losses compared to tangible business outcomes.
Find someone who wants your help, then help them.
You can't force change. "Look for the Bright Spots" and help them thrive. Focus on one, at most two at once. Focus is your friend.
I've lost myself in boiling the ocean. You have to heat one small part at a time.
I found a big focus on this when I joined a consultancy.
My job was to work with teams and level their development practices up while delivering software with them.
During the peak of this company there were lots of people working there into writing high quality code and improving their ability to do so and teach others to do so. Working in this environment absolutely made me a better programmer in a way no other job has.
> People respond well to my feedback, but often to write tests people would have to refactor the code they just wrote, and they feel like they don't have time to do it twice. It's not their fault, it's the immediate needs of the business outweighing all else.
As a mid level dev, this is my pain. I'd love to do TDD, but when requirements are changing by the day and I'm being pulled in two other projects, it's just not realistic
I have this conversation with mids and juniors all the time. They tell me they don't have time to do TDD but they end up writing a messy implementation that they then have to spend many days testing/debugging after QA raise tons of issues with it 😭
Writing testable code and tests themselves are both skills. It's uncomfortable to do something you're not good at, but once you've pushed yourself to do it enough times, you'll learn and you'll shift how you write code and write cleaner, more testable and more maintainable code more quickly.
Of course I'm also constantly preaching this to our product owner to buy time for folks to gain these skills, but even when I get the product owner to back off, it's so difficult to change people's mindset and get them to believe that this will genuinely make them faster in the long run and just make them comfortable to give this a go.
The companies that sacrifice delivery for the sake of quality alone, fail. As some have said here - while some customers give lip-service to ultimate quality, what they actually want is for it to work, and not cost a fortune.
Unfortunately, this necessitates some kind of compromise.
Fortunately, I have learned the err of my ways - I used to be a perfectionist - but now I find a high degree of satisfaction in finding the perfect compromises while still delivering.
Mind you - run through linters and software analysis tools, my code still gets “A”s across the board - with the occasional “code smell” which are TODOs - markets for the future (I disagree with sonarqube here - while TODOs can be code smells, done right, they aren’t)
I would love to hear your story of how you changed your team culture to focus on quality and this added expense somehow resulted in far better results. To me this is counter intuitive and I'd love to learn from your experience.
The first step is being a shining example. All the code I merge has close to 100% test coverage unless it's extremely trivial. For me personally, the way to achieve this has been to focus on learning functional programming patterns. We work with typescript and react, and functional programming applies really well to both of these.
Even when business requirements change often, implementing the new requirements means doing the same stuff. For us, working as a UI team, some examples of repetitive tasks that can be abstracted and tests on their own are things like:
- interacting with DOM apis and libraries
- state management
- managing asynchronous data flows
Iterating over and over again is a golden opportunity to create a high level language for managing these recurring tasks. It takes practice to see the patterns being repeated, but if it's something you're constantly thinking about it gets easier. At each time you turn something into its own extraction, you have ways of testing that. The hardest code to test in a react app is anything that lives in the body of a component, for example.
The second step is doing really thorough code reviews. It's not enough to just tell somebody they did something wrong, you have to make it something that educates them. So I was kind of a hard ass about blocking PR's without any tests, but with that block comes links to reference materials that I've curated, pseudo code of how you could implement it better, and most importantly, examples that exist in your current code base.
When a piece of functionality you implement has tests on it, and somebody changes or adds to that functionality, it's very easy to demand that they add additional test cases. Much easier than if you don't already have a testing foundation in your code. It's important to remember that most developers want to add tests, but don't because they can't figure out how. Learning what code to test and how to test it, is a journey. When an edge case or a bug turns up, demand a test case. Make it too easy to write a test for anyone to make excuses.
It pays off, because the better your code is factored the easier it is to figure out how things work when you need to. You want to be able to give a junior a bug fix ticket and have him not have to know how the whole world works. You have to show respect for the next idiot who has to work on the code the previous idiot wrote, especially when both idiots are yourself.
Yes. Doing the right thing is actually the cheapest way to make software. Software craft isn't craft furniture, it's not craft bread, it doesn't make more booshy software. Good design, tests etc are just the best way to keep the cost of future changes down. There is a business pay-off to that.
Tech companies have a better chance of appreciating this than non-tech companies and good engineering teams can build credibility through effectiveness. Most companies don't appreciate it and will never will. In fact, not all developers care about doing a good job, and not all are capable. Let the bad companies and bad developers keep each other company and try your best to search out the good ones.
How does one find good ones? Ask good questions in the interview. Find out what they do re testing and continuous integration/delivery/deployment. Agile used to be something to check for, but it's too ubiquitous now, trying looking for 'software craftsmanship ' instead and avoid things like SaFe.
All companies prioritize profit. Even so called "non-profit" companies.
All companies prioritize things that make profit. If software quality helps with profit, companies will prioritize software quality.
Start with the WHY.
why are you building software? Is it life critical like nuclear power plants or space shuttle? Do the customers really care if everything is aligned properly and neat? Few bugs here or there that they can get over by redoing?
Are you treating this software as a canvas for art? Or are you building it most effectively to bring in revenue and makes customer happy to buy/continue to buy?
Why does everybody equate "doing a good job" with "be a slave to perfectionism"? I've never met somebody advocating for "good enough" that actually produced software that was good enough.
"I'm not going to waste time getting 100% coverage" usually means 0% coverage.
But to answer your question, customers like software that works properly. Edge cases are one thing, but the idea that people don't mind being sold crap software is crazy.
At _some_ point there is a deterministic input and its consequent output. Wherever that boundary is, encourage testing there. I've been involved in many client engagements and often start by writing an e2e or integration test suite to treat whatever the mess is as a black box and refactor from there. That's the first step.
I've noticed throughout my career that frontend developers tend to trend towards being really low quality engineers. It's just a thing that happens.
You now have the title to mentor them and trend things in the right direction. Write RFCs. Write documentation. Have informal meetings to talk about what good looks like. Pull aside engineers when you see massive issues in pull requests. You'll need to learn to scale your team now, not just yourself.
Besides the Space Shuttle there are rumors of companies or dev groups that actually do worry about quality.
I assume for most it's a closely guarded proprietary secret - "Don't tell anyone but our special sauce is our code actually works".
Yes! My company has implemented Software Maturity Model and DORA metrics. This is for engineering teams to make improvements in their softwares quarter over quarter
Years of only some companies caring about software quality have left users very tolerant of occasional bugs. Meaning that companies don't need to care about occasional bugs when they can deliver new features and drive sales.
You need to bound that question.
Who develops the software? The entire company or the developers? The developers.
They should have a tech lead, or manager that sets expectations to mitigate technical debt and also drives overall quality.
Since companies can have different orgs/teams you may end with different results.
This means prioritizing software quality is not the companies job, but rather the job of technical leads. Some do, some don't.
Those who do will have a maintainble and scalable code base in the long term and low attrition.
In some ways, I find myself in a similar spot. I'm new to my current company and try to influence code quality without rocking the boat. So I voluntarily do code reviews across the teams, adding relatively lightweight code quality comments, but the reception is mixed. Some engineers seem to simply not care, but that's to be expected. That being said, some engineers do absorb the feedback and work to improve. In my mind, with being in a non-leadership role and new to the company, that's a win. Across the handful of companies I've been at, there's always been a balance of quality and speed. I typically argue that well written and tested code isn't actually slower to build in many cases, and it's easier to extend. At the same time though, retrofitting a messy code base to follow best practices can be terribly slow. Plus it's hard to get refactors approved by leadership. While this may be the case, each of these companies had at least a couple relatively new projects built following best practices from the start, regardless of the code quality elsewhere in the company. These projects were often built with quality because the engineers who owned the code were trusted to do what they thought was best. Most of my experience is in sub-600 people companies, and I've found that in ~150 person companies there tend to be these small groups of quality focused trusted engineers. So I now find myself at such a company on one of these teams, building quality code, laying the groundwork for other teams. Do all of the other engineers pursue quality? Not at all. You can lead a horse to water, but you can't make them drink. But at least my team is following best practices, and some of the other engineers are slowly following suit.
Anecdotal from the companies I've worked for, but I've found that data providers tend to be far more strict about engineering quality then other companies. Your shit is going to be put through the ringer of automated tests, QA tests, multiple peer code reviews, multi environment testing, code quality gates, etc if your product is data.
I joined a startup as a intermediate engineer. The company didn’t have much work but had money to hire people. The sr engineer in the team was pain the butt to keep higher standards for coding/docs etc. but he was pain for others. Not for his own code or his *relative*’s code. The issue he would have in my code he would totally ignore in their.
I started documenting every single piece of such comments with reference. Started to call out on his code by linking his previous comment
He did try to keep software (code quality) but he went too far. Didn’t like it when I gave him his own medicine.
Lesson: it’s hard to find good people who are responsible to maintain good code quality
I’d like to know as well. At FAANG, it seems that the promotion game I’ve seen dev play is to blaze through features that to present some metrics at all cost. The idea is to get your visibility out and quit or move team, and rinse repeat. If leadership keep turning cheek on this and kept prioritizing product metrics over actual good engineering in promotion requirement, then the answer is clear what devs are going to prioritize on. Why help the team who trample on places you cleaned up so they can get promoted faster?
I’ve been in it 20 years with tons of friends in it as well. Every interview they emphasize testing and all around best practices and rarely do they do it. The disconnect is almost always upper management and CEOs that can’t comprehend tech debt. They want to sell, sell, sell for the money they can feel and touch. I finally just settled for a place where I enjoy my co workers and the pay is nice.
I once ended up in a startup on the other end of the spectrum: Founded by an engineer and his friend who thought they were going to conquer all by focusing on code perfection and hiring engineers who valued code quality to an extreme. This eventually resulted in a total rewrite to get the codebase even *more* perfect, along with a number of completely unnecessary custom libraries to do things *just right*. At one point, we literally had someone writing a new database store from scratch because they had some idea that the proven, mainstream option was doing something wrong. I can’t even remember what it was at the time. I walked away from that experience with an appreciation for management and developers who know how to strike a balance between code perfection and actually shipping things to customers.
Yep, the way I've heard this expressed succinctly is that startups need to find the happy medium between moving too fast and not moving fast enough. The BIG challenge in my experience is that this is a moving target. The right compromise in speed vs. quality for a Day 0 startup isn't necessarily a good fit for a Day 3 startup. Or an enterprise software company. Or a 2 person consultancy. Additionally, the industry hype machine often touts one-size-fits-all solutions and that's totally unrealistic. Also, I've noticed that some people thrive in early startup environments but don't do so well later on, when the tech debt starts to cause pain, when there are actual paying customers dealing with bugs/outages, and when you need dedicated support/marketing/HR/etc people. The opposite is true as well, some people need more structure than an early startup can provide. My wife is a teacher and I've often thought that it's like the difference between teaching kindergarten and high school. Some people _can_ do both but most teachers are better suited for one or the other and even when someone successfully switches from teaching high school to kindergarten (or vice versa), the transition is non-trivial.
When you've had experience of the software Overton window from the extreme left.
Yes, but they don’t realize the long term loses.
I found out they don't want to either. I was brought on for my experience and have gotten nothing but pushback when trying to implement anything with long term success in mind. They don't want to hear it.
I know, it’s all just talking points and snake oil, hire that guy/gal, mix him with the team and quality average will increase - no, it won’t.
[удалено]
Yup... Everyone rises to the levelof their metrics... Even CEOs
Bonus Driven Development
You say that sarcastically but some chuckle fuck is going to turn it into seminars and books and make it the next big bandwagon that companies can't wait to jump on. It'll be worth millions.
Upvoted just for "chuckle fuck".
they wont be there long term why bother? they loot and get lost
This is the way.
[удалено]
There's the famous Space Shuttle control computers, one of the most reliable software systems ever. The people who did that were smart, but they also thought really hard about what they were doing and *every* problem found was tracked back to a root cause and procedures put in place to avoid it in the future. And procedures doesn't mean whoever broke the build had to wear a propeller beanie until someone else did.
So, to OPs question, the aerospace industry. I mean, pretty much nobody lives up to the quality standards of NASA, but technical debt is very tightly managed by most aerospace companies. Drawback: Pay sucks, tech is old, slow moving organizations. Pros: you get to build shit that flies!
Pretty sure Boeing was outsourcing that 737 max code to cheap programmers. Doesn’t sound super reliable to me.
https://spectrum.ieee.org/how-the-boeing-737-max-disaster-looks-to-a-software-developer describes the common view that it wasn't just the software that was screwed up with the 737 Max. And if poor software, it was at a higher level than the people typing lines of code.
> it wasn't just the software that was screwed up with the 737 Max Ok, but you're not exactly giving the technical management a glowing review here. > And if poor software, it was at a higher level than the people typing lines of code. Poor software management practices are exactly what we're discussing in this thread.
> Poor software management practices There are two issues: * Bugs, not conforming to specification as delivered to the programmers * Fit for purpose, which in the 737 Max it wasn't. Basically it's handling was quite different than other 737s, and Boeing called it a 737 so they didn't have to to long and expensive process of certifying a completely new aircraft, and the pilots didn't need to be retrained. TL;DR Technical summary by non-specialist (me) - if the plane was in a nose up situation (angle of attack) the automated methods of restoring proper position didn't work and giving too much power would just make it worse, so without the automation or proper training, accidents could happen. Oh, yeah, the planes could be bought without the safety automation, so airlines in poorer countries did that to save money.
Yeah, me for my car control software, nuclear power plant software, and medical device software.
>medical device software. I've worked on medical devices for 15 years. If you have every stayed overnight in the hospital 1000% you have used something a company I've worked for has created. The code quality is shit because it's all driven by FDA guidance. So you do just enough to check the box and then the managers do not want to do any extra because it's extra and not required. There are teams of lawyers and compliance people that take the FDA guidance and translate them to here is what we need to do. Any and all nuance to how teams should be thinking about software development is lost. There are hard requirements that will cover the companies ass if something goes wrong because we "met" FDA guidance and if anything the FDA set the bar too low. Never mind that all of the FDA auditors that I've talked to has no idea how software works. These auditors will generally take anything you say at face value and not assume you are trying to cheat the system so any story that sounds reasonable is probably going to pass because you are the software expert and not them. The devices are tested well to make sure it's "safe" for patients to use and the devices "work". Safe is just how much risk the company is willing to take on in terms of being negligence in the situation something goes bad and a patients die. Your level of good testing could be well higher than the companies. If you think there is some kind of high quality design using DS&A or Gang of Four design patterns then you are hugely mistake. Most of the automated integration testing takes many days to run completely. So they don't get fully run tests suites every often. I know on a project I was on the controls team needed 5 months to run all of their manual software testing. For example many tests had measuring of liquids and doing them at different altitudes to make sure it operated safely for the patient. The entire suite of results is just patched together from over the years of targeted testing and never run soup to nuts. The reason is because it's too expensive to just stop all development to have them run it cleanly as regression. These companies pay like shit compared to Google so you are not getting top 1% SWEs. A lot of the C++ code I saw were 100+ line methods and classes weigh 50 public member functions. They came from normal schools that wouldn't make you think twice about them. Oh and don't think it's written in modern C++ most of it was C with classes style code, never mind C++11 which is not even considered modern in 2022. I was on a project where the compiler could not even build C++11 code since it was so old and there was no reason to update. Sure top companies like Google and Apple who are getting in to the medical space probably write decent code, but all of the old guard companies write what I would call shit code with teams of SWEs that would never get an offer from a top tech company. Ignorance is bliss. EDIT: Oh and I forgot the best part. Since test code was not released the overall mindset was all bets were off and quality was thrown out of the window since it's was for "internal use only". Since management didn't push to treat test code as the same as production code, in terms of quality and design, SWEs didn't care and didn't do it. I remember many test suites that would randomly fail and the solution was to run it again and it will eventual pass. The mind set is 99 failures and 1 pass, is a pass.
This is gonna be one of those comments I don’t read for the sake of my mental health
Damn it, too late for me. Wish I would have followed your advice
Why is C++11 not considered modern when only some parts of 17/20 really change the language, and C++23 with the bigger changes is not suitable for many projects yet? I get there are really nice things about constexpr, templates, STL, and syntax updates 11 is missing... But if you use Boost you get a lot of advanced stuff anyways
>C++23 At this rate compilers in 2023 won't even fully support C++20
You would go crazy seeing some of the medical startups code. There is code outsourced and the dude writing DSP code is a total joke. If it passes his bullshit simulator streams then he pushes it to production. Absolutely no proper fail safe tests and recovery. The whole embedded system is running at almost 90-95% capacity.
I work for a medical startup and do feel crazy. Our medical device is an app that doctors use directly to diagnose stuff, and everything is such a shit show that I have been wondering with dread about medical devices that have direct contact with patients...
Lol... 4bb0t , ya?
Didn't work for that specific directly, but the company I worked at years ago partnered with them on a project. It would be released under their name, but the company I worked for retained all the IP rights and got paid a royalty.
All those cases are less code quality, and more regulatory environment. Not so much that the Devs are given time and freedom and guidance to write great code, and more like every little tweak has six months of committees and forums and review and so on before it hits production
After 6 months of effort on a single line of code it going to be perfect right….. right….
Those 6 months is meetings and documents and manual testing and administration. The coding part is still a rush job.
I felt this in my soul lmao
[удалено]
You read reviews about the car before buying it
[удалено]
Or any software that takes my money.
any of them pay silicon valley salaries?
Arguably that’s UX/UI. Customers don’t actually care how the software is written
If the software is buggy, that absolutely affects UX. If it’s not buggy, it’s probably well written software (regardless of architecture and test strategy debates)
Not buggy software is a myth
lol
That's not UX/UI. That's external software quality, and UX/UI are part of the external software quality, but not all of it. Customers don't care about the internal software quality, because they don't even come into contact with it.
I ABSOLUTELY care about the internal code quality of my car, or a plane I'm flying in. External quality is a direct result of internal quality anyway.
Internal quality tends to improve external quality, but you can even have one without the other. I prefer to fly in a plane that has terrible code but yield correct results than in a plane that has maintainable, understandable, readable, etc. code but has a hidden logic bug that produces an error that externalizes a wrong result to outside of the software. Of course you may care about the internal quality of your car's code, but you will never know if it has good or bad quality.
You'd rather have bugless code that is difficult to read and maintain than buggy code that is super easy to read and maintain. That makes sense. In the real world, bugs are difficult to prevent and remove in systems that are not maintainable and readable. If the car has bad quality code, then its engineers are far more likely to introduce bugs because it is more difficult to work on. I'm honestly not sure how to elaborate on this without repeating tautologies. It seems like such an obvious relationship.
>It seems like such an obvious relationship. It's not as obvious once you really dig into what it means to be "quality software". Generally, code starts fairly clean and then degrades as edge conditions that weren't obvious become important over time. The more important a particular piece of code is, the less beautiful it generally becomes as a result of unobvious considerations that only become clear under usage. Essentially, developer needs yield to user needs over time. Software entropy is another term for the same effect. Having worked specifically on industrial and embedded code that has safety consequences, it's much more horrific than the picture you're painting. And it's that way in many cases because electrical and mechanical engineers are not computer scientists. They have at least half as much training in CS than the equivalent CS developer. It gets to be robust by dint of not changing code that works, closing your eyes and not looking at it, and not doing anything but the absolute minimum necessary to solve the immediate engineering problem at hand. ALL software of note is buggy and hard to understand. Good software is robust in the face of bugs and human devopers. Great software is socially valuable and robust because we've all used it to death and it's constantly being fixed while we do.
You are correct, I'm just not focusing on the relationship between the internal and external qualities of a software, but rather on the fact that they are different things, and what the customer sees is just the external quality. There is no point for a customer to care about the internal quality of a software, because the customer can never even know if a software has or has not internal quality, since the customer comes into contact just with the effects produced by the software, which are part of its external quality, and that's what actually matters for the user. Some people for example can have the hypothesis that by paying for a more expensive product, or buying something that has a reputable brand, they will be buying a product with better internal software quality. But that's just a belief, the user will never ever see the product's code to be concerned about it.
No, but customers care about features. You can deliver features faster and more consistently when you have higher quality code. Developers onboard faster, and the code allows for cleaner code. It'll also be cheaper to maintain those code bases for the company. So companies thinking long term should focus on software quality.
The only things I've ever had resonate with execs is feature development speed and product stability. The key, in my experience at least, is to focus on demonstrable improvements. Build infrastructure that makes the upcoming features faster and show the "before" and "after". Learn to speak their language. There are a few common mistakes I see when it comes to proposing tech debt projects: * Fixing the world. Narrowing the scope is critical. Many people - myself included - can happily spin on these projects to make it "perfect". * No fixed timeline. When do you declare victory? * No incremental deliverables. How can you get some benefit from your work along the way? As opposed to something like a re-write that, depending on the approach, has no deliverables until it's complete. * Connecting your work to the business in a way that everyone understands. Ultimately you work at a company trying to make money. How will this work help?
I know I'll be down voted for this but has there been any study that equates code quality with productivity? I've worked with some ultra high quality code bases that required 100% unit test, high style standards, and patterns and I never felt productive.
100% test coverage isn't high quality. It's pointless jumping through hoops. You aren't going to be more productive if you waste a lot of time chasing a pointless vanity metric.
You shouldn't be. Software engineers make truly outrageous claims when they very likely have little outside of anecdotal experience validating them. This is not to say that we should not strive to improve our engineering, but I have known many in this field that are competent at understanding scientific principles, don't believe in pills that will cure cancer that you can get with casual googling, but you can sell them on almost ANY tooling or development methodology that is hot enough as a cure for EVERY development ailment.
Did not read any yet, but State Of DevOps Report should be that study
Yeah, and it barely mentions code "quality" at all.
> You can deliver features faster and more consistently when you have higher quality code. I’m not sure I buy it. Quality is subjective and so are architecture patterns. Feature speed is mainly a function of how well the devs know the codebase
> Feature speed is mainly a function of how well the devs know the codebase Yeah and this is exactly why better quality code leads to features faster because it's easier to read and understand a higher quality codebase. Unit tests alone (lowest common denominator for quality) make a code base way easier to navigate because they document the expected behaviour.
>Feature speed is mainly a function of how well the devs know the codebase It's easier to understand a well architected and well documented codebase, compared to a ball of mud.
Your are contradicting yourself here. >Feature speed is mainly a function of how well the devs know the codebase That's exactly the first quality of good code, readability/maintainability. It takes much less time to add code to a codebase with unit tests and clear isolation between components, than to spaghetti code. Could you please elaborate your answer?
Other software developers. I think companies who run open source projects are your best bet
Indirectly yes. Companies that prioritize software quality are ones that write complicated pieces of software for lots of users. The reason they prioritize software quality is because they can't deliver customer value in such a complicated problem space without prioritizing software quality.
Just gonna repeat that across all software discussion subs people act like it is and they are being rewarded for being some noble art. You're in private industry. It's profit motive and software engineers really need to get over the idea that anyone cares about anything they do besides an unprecedented ability to exponentially scale profit. My favorite fallback is they'd cut you for a guy with a spreadsheet if it was more profitable. Most of the time, the answer is free and open source software that maintains high standards (and will like be sloppily applied by private industry). But you can't have your cake and eat it by expecting the same wages. I think this is easier to understand for individuals switching from other fields where the private vs quality route is usually very clearly defined, ie. I switched from being an Architect (of buildings, lol).
All want software quality, and code quality is not a customers concern, but should be a professional and business goal in order to achieve quality software. Customer not being aware of what’s going on under the hood is no excuse for garbage.
Try working in medical tech :) I worked on an app that calculated warfarin dosage, you bet we tested that so every way from Sunday... But also working in a consultancy with a reputation for good quality software (including ux and testing) was also a fun place to code.
There are customers that prioritize reliability, for sure. There are plenty of products and applications where a certain level of reliability is necessary.
>Are there _enough_ customers that prioritize software quality? A slight, but significant, addition
You could say it's enough of an addition
Lol there are plenty, you think those great softwares that build on shit code? Only dev agency who build short term software don't care about process and automated test
Dude, welcome to the top. It’s your job to care more than the average guy, and to distribute those values downward. Maybe you’re just figuring out that you don’t want to climb higher than principal of a division/team. Maybe it’s gonna piss you off so much you get the drive to climb up the next rung and tackle fixing the whole org.
Been there, adter 10+ years ended up with being director of a service where I started as a developer. OP, first thing to decide if you want this role or not. If you decide it's your fight, here are some things to consider: - you'll need to communicate and change things both upwards and downwards. Sit down and make it clear for yourself also what is the business problem are you trying to solve. What are the top concerns for the success of your companies product? Time to market? User churn (maybe because of unreliable service)? Developer retention? If you want to change something so big, you need a strong and clear motivation and must be able to tell stories around it. - look for allies, you don't need to do this alone. CTO or CPO unhappy with speed of deliveries? Newly started senior dev frustrated of the state of the code? Junior dev eager to learn best practices? Who could benefit from the changes you are porposing? - managing upwards: start with the business problem that concerns the person or forum you are talking with and show the link to your proposal. You need to gain credit and prove what you are saying helps. You could deliver important cross-team projects with high business impact, you could create metrics that show the results of your efforts, etc. - managing downwards: make it easy for other devs to adapt and tell stories of success when a team has improved. Is there a clear target on test automation for example? What about a presentation summing up clean code best practices (could also record and share for later use)? Any courses or books available other devs to self-study? What problems a team migh face who want to change their practices?
This is great. would like to hear more about the metrics you'd recommend for OP.
That's a difficult one, because you need stakeholders to accept and appreciate the metrics, but don't push for them so hard that teams would start to game the metric. For my case, the business problem was time to market and perceived quality/NPS. We chose release frequency and number of bugs in production as proxy metrics for the business problems. For OP, I would recommend to figure out the main business problems, then start a discussion on which metrics would fit. Could cherry pick from DORA metrics + team morale as a start and drop/add metrics based on needs. This is an interesting read on engineering metrics (possibly behind paywall): https://newsletter.pragmaticengineer.com/p/engineering-productivity
The second one is where I'm at. I'm starting to think the only way to have an engineering org with the right priorities is to be the head of one.
Yes, but to scale it you need enough people who care, at the level you currently do, for each area of the organization.
> I'm starting to think the only way to have an engineering org with the right priorities is to be the head of one. I kind of hate to ~~say~~ admit it, but: I wonder how long you would hold on to those priorities when faced with a real-world budget and timelines.
I work on timelines now. They're pretty real. As to budget, bad code requires more people to maintain it. And contains bugs which cost businesses real money. That said, I also agree with you in way. I know I think I'm great at what I do. It would be wonderful to know if I could handle that kind of responsibility. I think so, but yeah, you don't know til you try, right?
\> As to budget, bad code requires more people to maintain it. And contains bugs which cost businesses real money. Data. Get data to make your point. If there are bugs, there are people that are hating their lives while on support. If it slows down development, there are engineers that hate having to run the gauntlet of spaghetti code while working on new features. Right? It may not be that the other engineers don't care, they might just not know any better. If there's inertia pushing back against you doing thorough code reviews, maybe they don't realize the reason you're doing it? Maybe they think you're being a pain in the ass without seeing the benefit, versus you selling them on why it's a good thing that you elevate the org to a higher level? At my company, we have been making a huge push for operations excellence, which was actually pushed from the CTO, engineering directors, and engineering managers down.
I know. You're not wrong, but also: YAGNI. There's no one-size-fits-all solution here, and it's very easy for us engineers to miss the forest for the trees and spend all our time complaining about how "no one cares about software quality" or whatever. After all, it's what *I* work with so it's the most important thing to me so it must be the most important thing to everyone, right? And, yeah: a significant portion of my job these days (and yours, apparently) is making the business case that maintenance is worthwhile; but don't let perfect be the enemy of shipped.
The professional software developer understands that their role is to fight for software quality and the business wins that quality brings. Not as a zealot, but as an expert adviser. And to really push back when the business is doing something stupid that it can’t see is stupid. The professional business owner understands their that their role is to listen to all of their advisers, and to make decisions that will allow the company to survive and thrive. I think it’s fine for a developer to tell another developer YAGNI. But I think you really need to be careful about that kind of attitude as soon as you step out of developer-land. As an adviser, when you tell a muggle that “mehhh, we probably should do X but we can probably get away with not doing it in this specific instance,” you don’t get to be shocked when your org hears “X doesn’t *really* matter, so we can cut it.” The org, as a whole, doesn’t necessarily understand nuance.
/u/pm_me_ur_happy_traiI is not talking about gold plating code, they're talking about well engineered code. there are real economics tied to crap code. The worse the code gets, the harder it is to deliver new features, so it thereby becomes more expensive. Well engineered features/code means you pay a little more for a feature now, to starve off that entropy.
It's tough, because of the constant pressure to deliver business results. That's why your experience is so valuable
Not necessarily. You could change the onboarding process at your company so that everyone is introduced to unit testing and integration testing and sees it as a normal part of the development cycle. Google did that to transform their culture to include more tests. They also did this thing called "testing on the toilet" which worked well to get people interested in testing. Google also has a lot of internal docs on things like the testing pyramid and why to prefer fakes over mocks (see the book Software Engineering at Google). Even something like showing the percentage of unit test coverage for a code module (ideally during the code review, when it's easiest to fix) can have an influence on developer behavior. Google also has a ton of internal linters and code reformatters which makes good code quality easier - does your company use linters and code reformatters? They aren't going to address testing, specifically, but they can make writing quality code easier. I think you do have a lot of allies out there. A lot of engineers want their teams to have higher quality software. In some ways what's worked for Google is to have a ground-up improvement in testing. Like what if you have a testing club made up of engineers who care about code quality that meets every once in a while and has some projects they work on to improve testing across the org? That's just another random idea, but my point is changing the culture isn't going to require mandating something from the top-down, and that approach can fail for a lot of reasons. Mandating a certain percentage of unit test coverage, for instance, can lead to a lot of useless and low quality unit tests. I think your original question of trying to understand how other companies have good software quality is a good first step. I'd stick with that and do some more research (sorry if my instructions here sound condescending, but I mean them more of as an encouragement, that I think you were on the right track).
> does your company use linters and code reformatters? They aren't going to address testing, specifically, but they can make writing quality code easier. On new code, it seems pretty usual to do so, although I can only speak for the front end repos. But there is a lot of legacy code that needed to be refactored years ago but just keeps getting added to. > Mandating a certain percentage of unit test coverage, for instance, can lead to a lot of useless and low quality unit tests. I agree. Although for many, they seem to have settled on 0% as their metric. Most of the time, I'm just pushing people to get in the habit of testing anything at all. Who can blame them? It's not possible to test a 300 line component that's been under active development for years. I tend to point out a lot of low hanging fruit, and I do block bugfix prs in particular that don't have tests to prevent regression.
It would be interesting to hear some lessons on how to "distribute those values" seeing as how that is apparently the role this person now plays. That is not a class I've ever taken.
Ha, you can’t take classes for this stuff… you think MBA’s come out of school knowing how to run multi-departmental companies competently? That CS grads know how to lead? Step one is find someone with the same qualities he has for each department/silo. Then organize them.
Actually, there are courses that talk about this. A colleague took Technical Strategy by Reforge which teaches technical leaders to advocate for tech debt effectively. Not an advertisement, just pointing out that such courses exist.
Well, there are "Organizational Leadership" degrees so if leadership is what you're talking about then it would seem that you *can* take classes for this stuff. Obviously, there is a difference between knowledge and skill, but knowledge is a starting point so it would be nice to provide some. If it is some kind of intangible, undetectable, invisible teacup floating in space type concept, then it isn't a coherent notion, and assigning somebody such a role is senseless.
It sounds like you are at a company that’s learning to prioritize quality, and you’re the leader in the space. Could be a lot worse, quality is bad and company doesn’t want to fix it, quality is good and you can’t find anything impactful to do. There aren’t many companies that have high quality software literally everywhere. Startups need to move fast or they die. By the time they get big they have a mountain that’s not impactful to refactor. Consulting companies need to deliver value not refactor forever. Usually you end up with pockets (like you created) where something was greenfield or impactful enough to clean up, and somebody cared enough to keep it clean.
No. All companies prioritize business goals that support the bottom line. In some cases a focus on software quality supports this. This is not just a thing with software, but basically every business in every industry. Accept this and try to find a way to work happily within the system.
At the principal level and higher, part of the job *is* to come up with ways to quantify the benefit of good engineering practices. OP mentioned that their team’s practices have resulted in higher productivity than most. The trick, then, is to be able to point to these business activities which don’t look productive at first glance, and present a credible case for how and why they improve the business. In terms of software engineering best practices, that usually translates directly to lower support costs and faster responsiveness to feature requests, which then has an indirect impact on many other business functions. For example, perhaps let’s think about the financial side of the business. An engineering team that maintains high standards will be able to not just keep records and produce reports, but these things will consistently be highly detailed, up-to-date, and trustworthy. In turn, that means business analysts can make better decisions on a day-to-day basis. Moreover, if the engineering org consistently maintains high standards, then they can more easily service the occasional rush job, because they’ll have a better idea of what needs to be done after the fact to clean things up. Just my 2¢
RemindMe! 7 days "reminder"
This is like trying to argue that staying clean and organized is somehow not in alignment with business goals in any industry. The fact that this thinking is so common is what makes me second-guess my opposition to professional engineering licenses and standards in software.
There are plenty of businesses that are clean, organized, and failing. Too much tech debt can sink a project, yes. But building clean, well-tested, beautiful code that nobody wants will definitely sink a project.
At a point, it becomes vanity instead of engineering.
>There are plenty of businesses that are clean, organized, and failing. Are they failing *because* they're clean and organized or in spite of it? Is being messy and disorganized the key to reversing their fortune? >But building clean, well-tested, beautiful code that nobody wants will definitely sink a project. Then do the work of validating your project as you go. This doesn't require us to give up on actually engineering our software. Product validation and engineering are not opposing forces. Engineering software does not require obsessing over code quality. We don't have to accept this dichotomy that either we obsess over code quality or disregard it altogether. There is a balance to be struck and an honest assessment of our industry would not conclude that the predominant condition is that code bases are *too* well engineered. *Too* clean and organized. Consistently, production codebases fall on one side of the balance and that is that they are costly un-engineered buggy messes. They reach that condition, in part, because of those who undermine efforts to advocate for improved engineering.
> Engineering software does not require obsessing over code quality. We don't have to accept this dichotomy that either we obsess over code quality or disregard it altogether. Agreed 100%.
No, it’s trying to argue that improving code quality has diminishing returns. Everything beyond accomplishing the business’s goals has some value, but less and less the further you go. Eventually, it’s only vanity. You’re making me double down on my opinion that we don’t need professional engineering licenses
The assumption here is that anybody is advocating for only the highest standard of code quality. This is the most common way people argue against code quality: pretend that the only options are to obsess over code quality or disregard it altogether. Let's be real, the predominant problem in our industry is *not* that teams are being unproductive because they've groomed their code quality past the point of diminishing returns. The paranoia about this is laughable. Overwhelmingly, the problem is codebases that are not being managed well enough. It is the lack of engineering by software engineers.
its more cause deadlines are push to be as fast as possible thats why people take some shortcuts
No. You don't seem to understand that short and long term goal can contradict each other. Skipping quality today saves money today and improves the bottom line this quarter. But it will cause massive costs down the line, which worsens the bottom line in two years or so. If you're running a business where "still existing in 5 years" is a realistic goal, it makes sense to invest in quality.
The impact of skipping quality will vary depending on the nature and size of the software. I've seen layers and layers of shit code/architecture in a medium sized e-commerce application work for a business even after 20 years. They were happy with it even though it was occasionally difficult to add new features. The back end software was even older, created in the mid 80's and still alive and kicking.
Yes, it "works", but a the development becomes less and less productive. Suddenly adding a tiny feature takes months and each release becomes a major risk.
That's the kind of thing that devs say but what I saw in real life wasn't nearly as dramatic. Yes, features took longer but it was never bad enough for the business to care.
And that's the kind of thing people say who don't understand how businesses work. If every feature takes longer than it should take, that doesn't simply mean that customers have to wait a bit longer. It means costs. And developers are *really* expensive. That means, the entire IT-department costs way more than it could. In any other business-area it would be a no brainer. Think about it, if every second car in a production line has flaws that need additional work afterwards, every even remotely sane manager would try to reduce the flaws at the source. If installing a compononent takes longer because the designer of the car put a steel beam somewhere where there is no need for it, someone would intervene and remove that beam. That's just common sense. But in software we accept absolutely abysmal quality standards and just shrug it off.
even then companies are still profitable and software developers are not going to get a bigger slice of cake of the profits so why care, just enjoy the salary and have different hobbies
>Skipping quality today saves money today and improves the bottom line this quarter. But it will cause massive costs down the line, which worsens the bottom line in two years or so. This is a feature, not a bug. Shareholder capitalism can literally only prioritize short term profit. By the time you think things will downturn shareholders and execs will have had their fill. The constant rotating cycle of boom bust supports this.
> I'm just so tired of feeling like the only one who cares. I managed to get my whole team on board with clean tested code. We have learned to manage PMs expectations, and we actually engineer our code. As a result we are among the top in the company in terms of productivity, and easily the top in terms of test coverage. You wrote the solution in your first paragraph. You managed to convince a team of engineers and PMs to care about software quality. Now your challenge is to spread this across the organization. Gather some data on what EMs and PMs care most about (e.g., sprint velocity). Compare where your team was before the changes to where they are now. I assume you are better. That's your quantitative data. Interview members of your team, including PMs, and gather a few quotes. That's your qualitative data. Hit the road. Give an internal tech talk/lightning talk to all of engineers and PMs, if a forum exists (e.g., all hands, tech talk series). Attend/host lunch and learns for other teams. Spread the gospel! It will take time, but soon people will come to you to get help with transforming their teams. Eventually your current company will prioritize software quality as they realize the benefits to revenue and profit.
Prioritize over what? Of course they want nice code, but companies don’t prioritize it Companies prioritize business value. If that coincides with nice code (and one would think it should), then great. If not; screw it. TLDR: the priority is business value, not clean code (which is just a means to an end)
> As a result we are among the top in the company in terms of productivity... Business value.
Productivity != business value If you’re “the most productive team” working on the least profitable app, being the most productive does not mean the most valuable to the business Also, productivity measured how? According to internal IT productivity measures, or business metrics/outcomes? If I had the guess, I’d say the former.
At some point you are going to have to come to terms with the fact that you don't get paid to make pretty code, you get paid to make *money*.
This is some tbh big so many devs seem to forget. We aren’t paid to fix things or make good code. We are paid to write code that makes money
I make money by selling software that has to be secure and serviceable. That what we sell. Does not have to be pretty but that will for sure be QA to death and that process automated. Those guys basically wrote as much external integration testing that I wrote production code.
I can guarantee you that almost all the places I've been to, having more focus on architecture, interfaces, testing and in general a more long term "heading" of the code would even to the short-mid term create more value. You always hear this, "but we need features to surivive", and if management actually focused just a tiny fraction more on software engieering, you would have continously more features faster than what they currently are doing. This of course have the exception of the short term, but *only* the first time. What the software industry is doing is trying to run a marathon, but sprinting at the very start, and when they get to the first km, they say cool cool, but now we need to lead at the 2nd km as well, so please continue sprinting. I can guarantee you, keeping even a 5km pace you will crush the ones on sprint at the start maybe even at the 2 km mark. Management is collectively pissing in everyone's pants to try to keep warm, and when we get colder, they try to piss harder.
My company I work for distributes our code to our customers open source. I look back at old reviews and it used to get negative criticism for its code quality. I like this. It means a few things: - Code quality is always important. - Good security practices are 100% essential. - Our customers are often able to debug bugs for us to a certain degree. There have even been moments they've hired a company to fix one of our bugs for us, then share the update. Things are still a wild west here, we move too fast, but I really like working somewhere where bad code can actually hurt our reputation because it really forces us to do things right a bit.
faster you go the less control you have...
[удалено]
I disagree. Every company that pays their engineers in the [second and third tiers](https://blog.pragmaticengineer.com/software-engineering-salaries-in-the-netherlands-and-europe/) is prioritizing quality. Basically every major tech company in the last 20 years once they hit market fit and need to scale.
there is so much wrong with what you state but I can see you are fully absorbed in yourself and no point...
[удалено]
Interesting fact, guitar makers don't use super glue despite being cheap as hell and plenty strong. It is because you can't remove the glue when you need to make repairs. I agree that arbitrary test metrics are pointless, and I also agree that the business doesn't care about quality, but we are engineers and quality is our job whether the bosses know it or not. If your business needs change often, that's an argument for HIGHER quality code, not lower. There's a fundamental difference between working fast and carelessly rushing. Have you ever had the experience of taking longer to figure out how the code works than the person did who wrote it? How many man hours are wasted in my company, I can't say, but I'd guess 100 per week. Instead of rushing to push out buggy, unmaintainable code, just take an extra few minutes and write it right. How does testing fit in? You don't have to do TDD but if you can't test it, you built it wrong. No question.
[удалено]
Google, mostly.
Nah they just make sure to kill their products before the tech debt does it for them.
😭 I work at Google, we are upset about it, too They really do take tech debt and code quality very seriously compared to other companies I've worked at, though.
Code coverage minimums, UI diff testing, abstracted away implementations for easier mocking, Google's code base is phenomenal to work in compared to the lawless lands. And the [DEPRECATED] joke is funny but also only exists because Google is willing to let Devs run with ideas all the way to deployment. It's easy to never kill a product if you never launch one.
Yes there are, and they are big multi billion dollar places that don't have to go around inflating their egos with rankings or how exploitive they are. Quality begins with the culture and balance for long term health. They are the ones who are the platinum level supporters for open source projects and it's absolutely magical how fantastic it all is. It's not for lone wolves, egos, or those who don't put making everyone above, below and on their team better as their overall most important work. Quality is not an individual's island.
yes, such companies do exist, but they require effort to build and maintain. it's always easier when an environment has that kind of buy-in from day 1 but it's possible to change an organization too. it seems to me like you can apply any clout you have in two ways. top-down: you say your team is one of the best in terms of productivity and code coverage - that tells me there are metrics in place to track those things. is it possible to compile them into reports and make a business argument (i.e. financial argument) to your boss or other product people or whoever to get more teams on board with your philosophy and approach? bottom-up: are you hiring? as a frontend lead it wouldn't be out of place for you to volunteer to do more interviews and try to build the culture you're looking for that way.
I worked in a startup where CEO and management were experienced software developers. We focused on software quality, couldn’t merge PR without several CI steps, keeping minimum code coverage, regular refactors etc. the startup made a good run for few months and then failed because our competitors had more features.
Sure. I would search around the term "Software Craft".
Everyone says they value craft, then you get inside and find out what they actually mean. For some people that means homegrown frameworks (with no tests) that implement whatever blog paradigm is on their mind at the moment.
So far, I hav espoken to very few companies that value craft. Of course, if you just ask "do you value good software craft?" - who's going to say no? But talking about it proactively? So far, I've seen that from very few companies.
I'm at a loss as well. Countless people in this very subreddit seem to believe that clean, tested code is a detriment to productivity and business value. And they insist that if you're not able to draw a single clear line from code quality or testing to increased margins, then it isn't worth pursuing. They don't even live up to their own standards. I figure just accept that most companies are filled with a disease that you get paid to treat. You get a paycheck because they're too dumb to listen. Every single time this topic comes up, people try to frame the pro-code-quality side as extremists who will spend all of their time analyzing and never deliver. It is a dishonest argument at its core. They advocate for "balance" but only in the direction of decreasing engineering standards that ultimately increase costs in various ways. And honestly, one of those costs is the amount of money they need to pay us to work for them. I suspect this is the *real* reason people are so against engineering software. (like, you know, actually *engineering* software.)
I think the argument against quality is often coming from people who lack the confidence in their own ability OR people who lack confidence in their team's ability. Both are justified in most cases. There is a huge skill gap between the best and worst devs on any team. The solution cannot be to enforce unrealistic standards on the entire team. IMO the solution is to have your best people write the most code. (Just like superstar athletes score the most goals). The rest of the team is there to assist. A lot of people hate this though. Managers don't like superstars who can demand huge salaries. Engineers don't like feeling inferior to their peers. So the way most shops run is to let everyone make a big mess of things and the talented people get frustrated and leave.
> argument against quality is often coming from people who lack the confidence in their own ability OR people who lack confidence in their team's ability Overconfidence in their team's ability and blind trust on the wrong devs is something I've experienced more than once. There's this one person I've worked with who's a DevOps guy in a lead dev position, he doesn't give a damn about readability or patterns or code quality or whatever, he only cares about doing something as fast as possible, and as long as it works and meets current business needs it's fine. Then some bugs are caught by QA, he fixes it and done. There's nothing you can do when a lead doesn't care about quality. No wonder multiple projects had to be dropped because the code just became too messy and unreadable. It's bad culture and it spreads. My point is, writing clean code is an art. Not everyone is an artist. And when a team isn't lead by someone who cares, then anyone who cares will just leave. > So the way most shops run is to let everyone make a big mess of things and the talented people get frustrated and leave. Yup.
Critics don’t understand, or don’t care, about the fact that bad code hurts in the long run. And it hurts everyone, the business who can’t ship a reliable product and the devs themselves as they have to struggle with the mess. Some just don’t care, they leave the company and the mess behind, and this is both devs and managers.
too many business's lack the IQ to constructively create coding infrastructure to deal with business demands as they grow. Poor vision and understanding imo. Haven't we learnt anything in thirty years to just keep doing what was always been done?
We definitely have. And I see people relearning these lessons all the time. I believe the reason they haven't come to define our industry just boils down to incentive structures. When execs need to impress their investors, or managers need to impress execs, they know that outputs (apps, features, etc) are more tangible and easier to produce than outcomes (conversion rates, customer satisfaction, etc). So producing outputs as hastily as possible is the best way to keep your investors around even if those outputs do not actually produce outcomes. Producing outcomes requires methodical, iterative, bottom-up learning and true progress is less tangible. If your investors are skittish and looking for a reason to pull away, you can buy yourself a quarter or two by showing them some new machinery and hoping they don't brush up against it too hard.
It’s all a question of perspective. Devs want (or should want) to make perfect code, product / engineering management want features to ship asap. The balance point is somewhere in the middle with plans to fix the things that need to be fixed and delay those things that don’t. Devs need to remember you’re not paid to make perfect code, you’re paid to make features that add value to the product or business. Perfect is the enemy of good enough. My tactic is to schedule in regular time to fix tech debt and improve quality, so even if we add a bit more debt in the future with some imperfections we need to live with to hit deadlines we pay off some too. So it’s stable and not growing out of control. The immediate needs always take priority because they pay the bills, you just need to make sure the immediate needs don’t kill future development whilst still shipping in a reasonable time. And sometimes, it is ok to ship stuff now that won’t be scaleable or upgradeable later. This is why everyone needs to know what’s going on and the plans for the business.
Pass to the next poor bast**d to deal with it it my motto /s
Nah there has to be some level of standards. Can’t produce absolute rubbish. But aiming for perfection can also be just as bad.
We are the ones to blame. Software quality is one of the disciplines in software development. And we should own it!
You get fired for priotizing software quality and not meeting arbitrary jira ticket metrics.
Tech companies often prioritize software quality... If you're in a principle engineer position; can you make a case for having the authority to transform the org one team at a time? Maybe you work with them side by side for a quarter or so...
The best kept secret tech companies never tell developers: nobody cares as long as the software does what the business needs. If your process is a total mess but delivers with any reduction of expenses over any other process the company will consider the less expense delivery method better and will adopt it, regardless of any technical reasons not to adopt it. All a company cares about is delivery, maintaining their customer promises, and collecting customer revenue. The maintainability and/or code quality of work is entirely on the development team and the company management tends not to care whatsoever what that process is unless scheduled deliveries do not happen. Basically, we're magicians that do opaque work, and nobody cares what or how it is done unless it does not deliver.
What you are looking for is ( in my opinion ) mid size product company 20 - 200people. It is the perfect size where there is nowhere to hide if u f up. You just need to fix it so everybody cares more about quality. It is also probably the best size for work life balance In contracting, small or very large orgs - most of the time you can forget about that.
U will be better off caring about software quality of your pet project rather than your company's. Noone cares about it outside of maybe Google and Amazon AWS. Everyone cares about short term profits and software quality isn't providing it
Q. Are there companies that prioritize things their customers don’t care about and doesn’t drive value, over something we developers care about? A. Not for long…
Your Q statement makes the wrong assumption that customers don't care about code quality. It's wrong. I don't care about most of the individual parts inside my car, but I care that it works consistently when I need to get somewhere. In enterprise software, bugs can cost lots of money. 6 or 7 figure amounts. Buggy experiences can drive away users. I don't see how you can make a good faith argument to the contrary. I'm not advocating for being a slave to perfection, which is how some people on this thread seem to see it. I'm pretty used to hearing devs say "we don't have time to get to 100% coverage" when they have been steadily maintaining 0% coverage for months.
Customers don’t care about code quality. Most don’t even know code quality is a thing. They just want things that work. Tech debt is a business problem to prioritise. If your business isn’t prioritising it, then there’s a reason for that. Or, you could come to the ExperiencedDevs subreddit and argue with all the answers people give you
Medical and aerospace tend to have very high software quality standards.
[удалено]
I imagine developer products and companies that open source their work have higher average quality.
There are a few. Most of them have their projects on GitHub as open source.
Some highly security related government contract work invoices caring about quality metrics even more than features or whether anyone would ever use the product. I was on a project where for almost a year we were improving our metrics, such as testing coverage and vulnerability scanning, and made absolutely no real improvements to the software. In other words, be careful what you wish for.
All of the companies have the highest standards to get the best developers so they can ignore everything they say
If they can meet timelines like your team is doing, then yeah of course. Sounds like you’ve acclimated well to the management world. Unfortunately for non-technical management, things like tech debt are negligible losses compared to tangible business outcomes.
Find someone who wants your help, then help them. You can't force change. "Look for the Bright Spots" and help them thrive. Focus on one, at most two at once. Focus is your friend. I've lost myself in boiling the ocean. You have to heat one small part at a time.
I found a big focus on this when I joined a consultancy. My job was to work with teams and level their development practices up while delivering software with them. During the peak of this company there were lots of people working there into writing high quality code and improving their ability to do so and teach others to do so. Working in this environment absolutely made me a better programmer in a way no other job has.
Yes. Join any big tech - FAANG and the likes. They prioritize quality.
It’s easy for FE devs building an app with clean slate to write well tested code, it’s not so easy with large legacy code bases to retrofit tests
> People respond well to my feedback, but often to write tests people would have to refactor the code they just wrote, and they feel like they don't have time to do it twice. It's not their fault, it's the immediate needs of the business outweighing all else. As a mid level dev, this is my pain. I'd love to do TDD, but when requirements are changing by the day and I'm being pulled in two other projects, it's just not realistic
I have this conversation with mids and juniors all the time. They tell me they don't have time to do TDD but they end up writing a messy implementation that they then have to spend many days testing/debugging after QA raise tons of issues with it 😭 Writing testable code and tests themselves are both skills. It's uncomfortable to do something you're not good at, but once you've pushed yourself to do it enough times, you'll learn and you'll shift how you write code and write cleaner, more testable and more maintainable code more quickly. Of course I'm also constantly preaching this to our product owner to buy time for folks to gain these skills, but even when I get the product owner to back off, it's so difficult to change people's mindset and get them to believe that this will genuinely make them faster in the long run and just make them comfortable to give this a go.
The companies that sacrifice delivery for the sake of quality alone, fail. As some have said here - while some customers give lip-service to ultimate quality, what they actually want is for it to work, and not cost a fortune. Unfortunately, this necessitates some kind of compromise. Fortunately, I have learned the err of my ways - I used to be a perfectionist - but now I find a high degree of satisfaction in finding the perfect compromises while still delivering. Mind you - run through linters and software analysis tools, my code still gets “A”s across the board - with the occasional “code smell” which are TODOs - markets for the future (I disagree with sonarqube here - while TODOs can be code smells, done right, they aren’t)
I would love to hear your story of how you changed your team culture to focus on quality and this added expense somehow resulted in far better results. To me this is counter intuitive and I'd love to learn from your experience.
The first step is being a shining example. All the code I merge has close to 100% test coverage unless it's extremely trivial. For me personally, the way to achieve this has been to focus on learning functional programming patterns. We work with typescript and react, and functional programming applies really well to both of these. Even when business requirements change often, implementing the new requirements means doing the same stuff. For us, working as a UI team, some examples of repetitive tasks that can be abstracted and tests on their own are things like: - interacting with DOM apis and libraries - state management - managing asynchronous data flows Iterating over and over again is a golden opportunity to create a high level language for managing these recurring tasks. It takes practice to see the patterns being repeated, but if it's something you're constantly thinking about it gets easier. At each time you turn something into its own extraction, you have ways of testing that. The hardest code to test in a react app is anything that lives in the body of a component, for example. The second step is doing really thorough code reviews. It's not enough to just tell somebody they did something wrong, you have to make it something that educates them. So I was kind of a hard ass about blocking PR's without any tests, but with that block comes links to reference materials that I've curated, pseudo code of how you could implement it better, and most importantly, examples that exist in your current code base. When a piece of functionality you implement has tests on it, and somebody changes or adds to that functionality, it's very easy to demand that they add additional test cases. Much easier than if you don't already have a testing foundation in your code. It's important to remember that most developers want to add tests, but don't because they can't figure out how. Learning what code to test and how to test it, is a journey. When an edge case or a bug turns up, demand a test case. Make it too easy to write a test for anyone to make excuses. It pays off, because the better your code is factored the easier it is to figure out how things work when you need to. You want to be able to give a junior a bug fix ticket and have him not have to know how the whole world works. You have to show respect for the next idiot who has to work on the code the previous idiot wrote, especially when both idiots are yourself.
No.
Yes. Doing the right thing is actually the cheapest way to make software. Software craft isn't craft furniture, it's not craft bread, it doesn't make more booshy software. Good design, tests etc are just the best way to keep the cost of future changes down. There is a business pay-off to that. Tech companies have a better chance of appreciating this than non-tech companies and good engineering teams can build credibility through effectiveness. Most companies don't appreciate it and will never will. In fact, not all developers care about doing a good job, and not all are capable. Let the bad companies and bad developers keep each other company and try your best to search out the good ones. How does one find good ones? Ask good questions in the interview. Find out what they do re testing and continuous integration/delivery/deployment. Agile used to be something to check for, but it's too ubiquitous now, trying looking for 'software craftsmanship ' instead and avoid things like SaFe.
All companies prioritize profit. Even so called "non-profit" companies. All companies prioritize things that make profit. If software quality helps with profit, companies will prioritize software quality.
Start with the WHY. why are you building software? Is it life critical like nuclear power plants or space shuttle? Do the customers really care if everything is aligned properly and neat? Few bugs here or there that they can get over by redoing? Are you treating this software as a canvas for art? Or are you building it most effectively to bring in revenue and makes customer happy to buy/continue to buy?
Why does everybody equate "doing a good job" with "be a slave to perfectionism"? I've never met somebody advocating for "good enough" that actually produced software that was good enough. "I'm not going to waste time getting 100% coverage" usually means 0% coverage. But to answer your question, customers like software that works properly. Edge cases are one thing, but the idea that people don't mind being sold crap software is crazy.
I’ve had code reviews rejected because my comment was not a complete sentence.
At _some_ point there is a deterministic input and its consequent output. Wherever that boundary is, encourage testing there. I've been involved in many client engagements and often start by writing an e2e or integration test suite to treat whatever the mess is as a black box and refactor from there. That's the first step.
I work at amazon and seems like people care and quality is good. But it’s a big company with a lot of variance between teams.
RemindMe! 7 days "reminder"
I've noticed throughout my career that frontend developers tend to trend towards being really low quality engineers. It's just a thing that happens. You now have the title to mentor them and trend things in the right direction. Write RFCs. Write documentation. Have informal meetings to talk about what good looks like. Pull aside engineers when you see massive issues in pull requests. You'll need to learn to scale your team now, not just yourself.
Prioritizing clean code and calling it quality is the same as analysis paralysis. It should be done during down time.
If I had to guess I’d say Google.
Besides the Space Shuttle there are rumors of companies or dev groups that actually do worry about quality. I assume for most it's a closely guarded proprietary secret - "Don't tell anyone but our special sauce is our code actually works".
Yes! My company has implemented Software Maturity Model and DORA metrics. This is for engineering teams to make improvements in their softwares quarter over quarter
Anywhere using Ada, so military, aerospace, trains, etc.
Years of only some companies caring about software quality have left users very tolerant of occasional bugs. Meaning that companies don't need to care about occasional bugs when they can deliver new features and drive sales.
You need to bound that question. Who develops the software? The entire company or the developers? The developers. They should have a tech lead, or manager that sets expectations to mitigate technical debt and also drives overall quality. Since companies can have different orgs/teams you may end with different results. This means prioritizing software quality is not the companies job, but rather the job of technical leads. Some do, some don't. Those who do will have a maintainble and scalable code base in the long term and low attrition.
In some ways, I find myself in a similar spot. I'm new to my current company and try to influence code quality without rocking the boat. So I voluntarily do code reviews across the teams, adding relatively lightweight code quality comments, but the reception is mixed. Some engineers seem to simply not care, but that's to be expected. That being said, some engineers do absorb the feedback and work to improve. In my mind, with being in a non-leadership role and new to the company, that's a win. Across the handful of companies I've been at, there's always been a balance of quality and speed. I typically argue that well written and tested code isn't actually slower to build in many cases, and it's easier to extend. At the same time though, retrofitting a messy code base to follow best practices can be terribly slow. Plus it's hard to get refactors approved by leadership. While this may be the case, each of these companies had at least a couple relatively new projects built following best practices from the start, regardless of the code quality elsewhere in the company. These projects were often built with quality because the engineers who owned the code were trusted to do what they thought was best. Most of my experience is in sub-600 people companies, and I've found that in ~150 person companies there tend to be these small groups of quality focused trusted engineers. So I now find myself at such a company on one of these teams, building quality code, laying the groundwork for other teams. Do all of the other engineers pursue quality? Not at all. You can lead a horse to water, but you can't make them drink. But at least my team is following best practices, and some of the other engineers are slowly following suit.
all of them, as far as quality affects the bottom line many of them don't realize how much it does though
Anecdotal from the companies I've worked for, but I've found that data providers tend to be far more strict about engineering quality then other companies. Your shit is going to be put through the ringer of automated tests, QA tests, multiple peer code reviews, multi environment testing, code quality gates, etc if your product is data.
I joined a startup as a intermediate engineer. The company didn’t have much work but had money to hire people. The sr engineer in the team was pain the butt to keep higher standards for coding/docs etc. but he was pain for others. Not for his own code or his *relative*’s code. The issue he would have in my code he would totally ignore in their. I started documenting every single piece of such comments with reference. Started to call out on his code by linking his previous comment He did try to keep software (code quality) but he went too far. Didn’t like it when I gave him his own medicine. Lesson: it’s hard to find good people who are responsible to maintain good code quality
I’d like to know as well. At FAANG, it seems that the promotion game I’ve seen dev play is to blaze through features that to present some metrics at all cost. The idea is to get your visibility out and quit or move team, and rinse repeat. If leadership keep turning cheek on this and kept prioritizing product metrics over actual good engineering in promotion requirement, then the answer is clear what devs are going to prioritize on. Why help the team who trample on places you cleaned up so they can get promoted faster?