I started working as a Software Developer about 7 years ago. Since then I have had multiple different positions in different companies.

I started in the software department of an engineering company where software is either a tiny part of the manufactured product or just supports the process of manufacturing it. The first project I worked on was a big one man program which was grown into an enormous software mess. My boss at this time and the former "one man" were not interested in changing things, nor did my boss allow me to do things differently. It was very frustrating.
As a newcomer I tried to accept the fact that this is how things are and lived with it for some time. Later I contacted the boss of my boss (I'll call him Tom) about the situation I was in, and told him that it does not meet the expectation of how I want to write software.

Over the course of a year I had multiple meetings with Tom where I and a coworker of mine (who joined the team in the meantime) discussed the situation, and what could be done to improve it. I actually hoped that Tom at some point would pull my boss out and re-evaluate who is going to lead the ship.
Sadly this never happened (at least not while I was there - it did not take that long after that when the mentioned coworker and I quit).
Actually not very much happened at all. I never told Tom that I expected stuff to change radically. Which in the review I should absolutely have done.

At some point in a talk with Tom he told me that I should just do it the way I think, without discussing it with my boss, and if there were any problems I should just tell my boss that that is how it was discussed with him. At this point I realised that Tom was failing his leadership responsibilities in forcing me to bypass my boss. So I quit.

Now a few years and a few very similar frustrating positions later I am again stuck in a project that is grown over many years, where I have the feeling that I am the only one who is interested in cleaning up the mess up step by step, while my new boss is again not interested in going in that direction.
And again the meetings where I try to point out that we need to start creating clean software are never followed by any actions. And again the meetings need to be held with "Tom" because I can't get a constructive discussion going when communicating directly with my boss.

Now I start questioning my career choice. Maybe I am not made for being a software developer. I just can't accept the (as I found it) widespread decision to write bad software and fix it later (which of course never happens).

Have I just been unlucky with the companies I joined, or did I not make it clear enough that this is not how I want to do it. Or are they doing it fine and I need to change my domain into something different (design, project management, whatever).


Congratulations, you have just discovered what >90% of business software looks like.

You were in the wrong place to apply your skills. These businesses (which make up the majority of businesses, which in turn makes up the majority of software in production) do not care about technical debt because it doesn't add to their bottom line - or at least they don't see it that way.

You might try to persuade your superiors otherwise, but it's a thankless enterprise because they're probably trained not to think that way. Additionally you have a One Man Software guy who's been there for years and now you're messing with his toy. Don't mess with other people's toys.

I was in a similar position where we sold a software product suffering from technical debt equivalent to the fiscal debt of Greece, and very little indication of things going the other way*. The stable and low stress environment made it an ideal place to retire in, but for a young developer just starting out it wasn't for me.

I quit that job and joined a consultancy where I get to work on new projects every year or so, and we get to use the latest and greatest technologies whenever we can.

So, no, you're not in the wrong profession, just in the wrong company.

*They brought in VC funding while I was leaving and the new influx of cash, coupled with the constant moaning of the majority of developers, convinced management to do their core products from scratch, and put the current products on maintenance mode with limited development. I was very happy to hear that and wished the process had started while I was there so I could work on it, but I wouldn't go back.

  • These businesses do not care about technical debt because it doesn't add to their bottom line. You don't have to give a reason. They just don't care. period.
    – user7360
    Aug 3 '18 at 15:40

tl;dr On the contrary, you should start to ask yourself if to be a Software Engineer is the right career path when you stop caring about quality.

There are good books about dealing with legacy software (for example the evergreen Working Effectively With Legacy Code); the point is that you do not have to ASK to write good software as you do not have to ask to test the code you write. Refactoring and improving quality of existing code is almost always part of the maintenance process, as writing tests is also part of delivering a new feature. Related and interesting: As a developer; Not getting time to test, receiving extreme deadlines and not being listened to by the manager.

You can run away every single time, pursuing the perfect company chimera with the perfect code base (or always new projects without any legacy). Alternatively you can embrace this challenge and add your own professional value to the company you're working for.

Working on older projects will also teach you extremely important lessons about scalability, reliability and maintenability that you won't ever learn if you keep switching to new projects every year or so.

What you may improve is your approach to the problem. First of all you have to understand that technical debt is intrinsic in almost every software project, this is a fundamental point and you can't change it. As you already know a technical debt may be high because of many reasons:

  • The project started as a prototype (if not just a proof of concept) and then evolved over time. It might be because a poor SE choice or because of a business choice (no time to rewrite something that more or less works).
  • The project started as a simple tool and evolved to something too big to fit the original architecture/design. This usually happens in small steps where code goes progressively out-of-control.
  • Source code has been originally written or maintained by someone with a less than optimal skillset.
  • Source code has been well written but it's old, technology and best practice evolved enough to make it "outdated" but still functional.
  • Regardless original source code quality the applied business pressure (for example in a Startup environment) forced more and more technical debt.

After you embraced this revelation you have to understand how to deal with it. Sometimes a complete rewrite is a possible choice but you, usually, need to explain your managers what is the value that this big investment will bring to the company. This has been widely discussed and I won't repeat it here, the correct strategy is slightly different for each the above mentioned cases. This is the main point: a non-technical (but also a technical one because from her position she will see things from a different point of view) manager is not against quality but they need to justify the investment, consider:

  • Rewriting is expensive and provides no visible short-term output, and they may not even have a budget for this.
  • It's a risk because you will (for sure) introduce new bugs.
  • You may fail, any non-trivial project may fail (someone even says that most software projects fail) and then they'll have the original code base and X months of wasted time (or a new code base with the same, if not more, problems than the original one.)

What to do? Start with communication: first of all explain the situtation but don't simply go ranting about code quality or you will be unheard:

  • Be prepared: provide examples of when poor existing code quality was the source of some major production issue.
  • Be prepared: provide few different estimations of simple tasks that required much more time than it should be (again because of existing code quality).
  • Be prepared to discuss a potential architecture for the new implementation.
  • Be prepared: provide a wild (at this stage) but educated estimation.
  • Be prepared: provide a road map of how this transition may be conducted and which resources you will need. As Stefan noted in a comment this does not need to be made in one big jump.

If they do not agree with such rewrite (it might well be) then you have to take a step-by-step approach as part of your daily duties.

What you can do is to understand that it's YOUR DUTY to write good code with all the constraints given by your management (time, budget, resources). It means that you MUST:

  • Write tests every single time you change something.
  • Apply basic local refactoring techniques every time you're adding a feature or fixing a bug.
  • When big changes are required then you may extend refactoring to other modules/packages keeping them as small as required to complete the immediate task.
  • Schedule, if possible, some intra-module refactoring time when - after local refactoring has been completed - you see an opportunity to clean-up one step above.
  • Apply all of the above to collateral elements (like documentation, for example.)
  • Repeat.

Iterate enough times and your code base will now be good enough. Sometimes some big architectural changes may need approval because they're too long or complex but when you're at that point you probably have an already solid base.

This is an invisible process, quality is constantly evolving but it's not necessarily visible from outside. I think this is what Tom (the firt boss' boss) tried to tell you: "do your job (step by step!) without bothering your boss, it's your duty and I trust you know how to do it (send him to me if, by case, he doesn't understand this)." Should he had to speak about it with your boss? I can't say but if you do your job in a non desruptive way then the process is invisible and effective.

Sometimes they [management/boss] are to blame but it's often a communication problem, you may like to read Representation and Misrepresentation: Tufte and the Morton Thiokol Engineers on the Challenger and original Tufte's text in Visual Explanations: Images and Quantities, Evidence and Narrative.

  • 1
    I understand but YOU (and I and probalby almost all programmers) can understand the reason to invest in code quality. As long as software works, managers (and customers) don't care (are you even aware, for example, of the design procedures - and relative regulations - adopted by the manufacturer of the car you're driving?) That's why you have to incrementally improve code quality as part as your day-to-day duties. Some rare times code is such a mess that you may need to rewrite (and that will need to be approved by management) but usually it's an invisible process. Aug 3 '18 at 11:48
  • 2
    With this I do not say that it wouldn't be great iif CEO comes to us saying "I saw your code and it looks gorgeous, thank you and this is the bonus you deserve" but the truth is that only your direct tech lead knows about the quality of your code and it's always judged (NO EXCEPTIONS) together with its business value. Aug 3 '18 at 12:14
  • 2
    Unless your boss duties are ONLY technical (in this case I agree, you have the wrong boss) then he has to deal both with business requirements and the technical aspect. It's a compromise (and some people are easy to forget the technical aspect even if they have a technical background). Again the point is that you do not need to ASK but to do it because it's a fundamental part of your job. If you're working in a team where everyone has to focus more on quality then go with evidence, numbers and solutions. Quality alone is not a metric but a tool to achieve something else. Aug 3 '18 at 12:19
  • 2
    This summarizes my own experience well. I'd like highlight that instead of going for The Big Rewrite you could rather propose stepwise improvements. Less risk, easier to plan in a few steps, you get at least some improvements and feel better. Also, the first Big Rewrite usually fails in one way or the other. I've seen that several times. Aug 3 '18 at 12:57
  • 1
    Also worth mentioning that the "perfect company with the perfect code base" does not exist. Every design decision in software comes with trade-offs. Spending your time refactoring means you aren't spending your time adding some other value. One design pattern makes some enhancements easier, and others harder. Your job as software engineer isn't to write "perfect" code (you can't), but to recognize the trade-offs and make your best guess at the right balance.
    – Seth R
    Aug 3 '18 at 15:26

Yes, a lot of larger companies have groups of "untouchables" where new people come in, and they don't want you to break a "working" product. I seen it at my last company. A small group of people developed the main software for the company. They all gained into management positions and in good standing with upper management. They hire in new developers since they justified they needed new developers to continue growth of the product. New folks come in, and the original group that made it simply expects the newer developers to work on the product the way they want to.

It's fairly common in companies that got into some niche market. At my last company they never had any software or IT related products and once they moved into that market, the people who were originally hired made it big since they became the "go to" group once the software matured. None of the upper management understands how IT development works and relies on the original group of developers. They only care about revenue and whether it is coming in. They are quick to fire any new manager hired who doesn't meet this expectation.

You'll have to find a company that either don't drive on profits alone or find a well established company that was always in the IT field with IT executives and upper management.

You can usually figure this out without asking directly. Simply ask the main manager how he got to his position within the company. If he tells you a story like above, then you know what to expect.