Is low code quality and lack of testing the norm in B2B software development?

Question

I've been working at this company for about a year now. it's a growth company working in B2B. I'm one year out of university, with a major in computer science. I work in the web team, using an Angular frontend and node as the backend. Throughout my time here it's always irked me how little effort seems to be put into the codebase. Massive files (1000 lines +) containing entire pages of components that haven't been broken down into subsequent components. Lack of static typing (either typescript or jsdoc, I'm not overly picky). Poorly named functions and variables, you get the point.

The thing that scares me the most is the lack of testing. There was an initiative to hire an end-to-end tester about a year ago, so we have a small portion (around 1%) of our end-to-end functions tested. There's a very small number of unit tests, which aren't even running on our CI pipelines. I noticed these shortcomings when I started, and I began reading many highly regarded books to understand how to not contribute to these shortfalls (Clean Code, Pragmatic Programmer, Clean Architecture, Don't Make Me Think, how Google tests software, etc).

Over a couple of beers, I mentioned to my manager about these shortcomings. She was interested to hear my feedback, but her response was along the lines of "I appreciate your concern. However, these books that you've been reading are all written by developers in B2C companies. At this company we are growing so fast, and the requirements are changing so quickly that we throw away our code so frequently. Why put time into writing code that has a 50% chance of being thrown away within the next year. If you want to write perfect software, become a scholar".

I understand where she's coming from, in the sense that these authors tend to come from sizeable B2C companies. I also understand that there's a balance between the immediate value and the delayed value of code. This opinion doesn't resonate with me however, as from my understanding, testing (unit, end-to-end, usability, etc.) would appear even more suitable in this situation with fast changing requirements.

I'm interested in knowing whether this really is the norm in B2B software companies? I'm not trying to prove her wrong, because I really respect her work, she has done an awful lot for the company, and I have no doubt that we wouldn't be at the state we are today without her.

Open to any answers, including those that tell me I'm being naive and overly optimistic, because then I can set my expectations for work appropriately.

Answer 1

Kind of, but you are being fobbed off.

these books that you've been reading are all written by developers in B2C companies

No, B2C companies are just as bad/good as B2B and everyone writes books

Why put time into writing code that has a 50% chance of being thrown away within the next year. If you want to write perfect software, become a scholar

Because writing the code "well" is faster overall. Even if you end up throwing features away (you won't) the "good practices" you mention are good because they are good for productivity.

In fact Academics tend to write the "worst" code, because these ideas are driven by problems from the commercial world

• How do I deploy twice a week without wasting time and getting errors?
• How do I find out about bugs before the customer?
• How do I manage a team of devs so that the overall feature gets done on time?
• How do I onboard new devs and get them up to speed as fast as possible?

etc

The reason your company's code is like it is, is not because its a B2B company. It's because the people in charge either haven't encountered these issues in a way which impacts them, or understood that these "best practice" ideas are solutions, or at least attempted solutions, to those problems.

You probably have some good programmers who have been there a while and can churn out features in a good time frame. When the number of features increases beyond what they can cope with, when they leave, or when some competitor starts to over take you, that's when the company will start to feel the pain of not doing some of these things.

Generally speaking the larger the company the more they will value "engineering excellence" because they will have been hit by various problems and hired consultants to tell them why, and then been sent on courses that say "write tests", "use CI/CD"

You should keep notes on your experience and the flaws you see in your company. These will for the basis of your own book and many anecdotes you can tell when you are consulting.

Answer 2

A horrible standard of quality from a practitioner's experience is certainly the norm in the industry, and as usual, it comes down to incentives. As long as customers are willing to pay for incomplete, slow, late and only vaguely correct systems, there is no reason why any vendor would clean up their act and increase internal quality (particularly since this would trade short-term losses for longer-term gains, and business is notoriously short-sighted).

And why are customers willing to pay for a bad product? One reason is that it's relatively hard to distinguish a quality product from a shoddy one; everyone can tell if an apple tastes like crap, but in buying a car it's already a lot more difficult to tell whether someone is selling you a "lemon", and for major software projects, almost no customer can readily tell the difference without actually running them in practice long-term - i.e. long after they've been paid.

The solution can only be a higher-level framework of regulation (even food required a lot of regulation until it became routinely safe, since people can tell what tastes bad, but not what tasteless harmful components might be present), but for the moment both sides are reluctant to propose such measures; vendors fear liability and bureaucracy, while buyers fear price increases. That is why the major factor driving software quality right now is still personal responsibility and integrity. Keep it up!

Answer 3

Poor quality is indeed the rule.

Aside from anything else however, there isn't widespread agreement on what good quality looks like.

Automatic tests only add a small increment of reliability, and exact a large cost in terms of development and rigidity against further change.

For the largest and slowest-moving companies, an extra month of development (consisting of several man-months) for more testing of something crucial that will eventually handle billions of pounds of turnover, is good value.

In the smallest of businesses, that additional cost of a few man-months of development may be more than their entire profit, and any increment in software reliability may be dwarfed by much larger operational risks. That is, as well as being unaffordable, big-company-style software reliability is also gold-plating a particular part of the business whilst other parts remain dilapidated.

The point is that there isn't one standard of software quality, because there isn't just one context to which computer software is applied. Avionics isn't the same context as keeping the books for a small church charity.

Adaptability is also a crucial property of software. The ability to change what the software does - sometimes suddenly - is often crucial. Many businesses don't control their entire world, nor have the kind of market power where they can just lean in to (what are by private domestic standards) massive costs of remaining still. Sometimes when someone says the computer needs to change what's it's doing, they mean today, not next year by which time the company would have been bankrupted by the failure of its computers to cope.

Adaptability roughly corresponds negatively with the amount of time developers have to invest in analysis and design, and the design effort and complexity developers then embed in source code.

Automatic tests promote adaptability in the sense that, when used correctly, they allow a carefully controlled change to occur with less risk of error - especially by different people than who wrote the software originally. For a business that is capable of standing still for however long it takes to make a controlled change, and who are just too large to expect that they will retain the same staff forever, that is a boon.

But automatic tests also promote their own kind of sclerosis. They have to be developed, and they have to be adapted when things change. And if the adaptations are not careful - if developers just hack through changes to the tests to correspond to changes they have had to make quickly to the main code under test - then the tests were probably completely worthless, a pure overhead.

Now for a business of any size, software that contains costly but worthless overheads which makes necessary changes to it slower, is the definition of poor quality.

The need for adaptation and to preserve adaptability, is the main reason why it isn't acceptable or desirable to simply embed more time and complexity in software.

The definition of a computer system's reliability is not just the correctness of the existing programming, but the ability of the computer to accept and follow new programming from its human masters in a timely manner. There's a dynamical aspect to the problem that is much under-appreciated.