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.

  • 2
    I took the freedom to improve your question a little bit (a title which allows to understand people what this question is about before reading it), more paragraphs, no distracting "thanks" at the end etc. Still I think it is not a good idea to work such a question as a "yes or no" question. What you obviously really want to know is if it is worth or justified to fight against this mindset, and maybe if B2B in general has really lower requirements for code quality than B2C software.
    – Doc Brown
    Commented Dec 18, 2023 at 9:32
  • 1
    After several decades in the career you have chosen, you will realize that there are no recipes for success. Yet the recipe market will always flourish, because who doesn't want a recipe for success ? And yet, few will ever replicate the actual success, despite doing everything right, by the book. If you want to solve a real world problem better than the competitors (who also follow best practices, and do everything right) you'll need something that no book ever taught: creativity. And creativity, by definition, will be at odds with the best practices.
    – S.D.
    Commented Dec 18, 2023 at 12:22
  • 3
    dont see how this is "opinion based" lots of us have worked in both B2B and B2C im sure, and are in a position to give an authoritative answer
    – Ewan
    Commented Dec 18, 2023 at 16:03
  • 1
    Define "the norm": do you mean what's actually the case on average, or do you mean what's considered to be good practice on average? There's a big gap between what people think should be built and what they actually build.
    – Flater
    Commented Dec 20, 2023 at 1:24

3 Answers 3


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?


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.

  • Thank you for your comprehensive answer Ewan! It's good feel validation regarding my opinion on code quality, and differences in B2B/B2C. It leaves me one question for the short term. Do I just sit on my hands and wait until a problem appears before I preach about code quality? We've had new hires since I've started, and after conversations with them, it appears that their velocity is hindered by the quality of the codebase. Does this constitute enough of a problem, or does it need to be more apparent/larger? Thanks again! Commented Dec 18, 2023 at 19:15
  • 1
    a question for #theworkplace, my advice would be to try and implement these things on small projects you can do yourself and remember to ask about that kind of stuff when you interview at other places. "what best practices do you use? Do you do X architecture? what version of Y are you on?" etc You shouldn't hang around too long as without that kind of experience you will be less employable
    – Ewan
    Commented Dec 18, 2023 at 19:44

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!

  • 1
    Great answer Killian, thank you! I guess I want to know whether my efforts to make my own code clean, and promote code quality and testing are in vain. Since the software is paid for by customers regardless of whether it's a "lemon", is there any place for me to preach otherwise considering it already pays the bills? I feel shoddy when I release code that isn't maintainable or tested, but should I just lower my standards? Again, thank you for your comprehensive answer Commented Dec 18, 2023 at 19:00
  • 2
    I firmly believe the the habit of writing reasonably clean code pays for itself even if you can't convince your colleagues of it, because you won't always work at that place, but you will always take your improved skills with you. But of course it's even nicer if you can propagate it to at least some others there. Commented Dec 18, 2023 at 21:49
  • 1
    A bit OT: have a look at how security is implemented ... As long as no one pays for security it comes more as an afterthought. Commented Dec 21, 2023 at 8:54

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.