How do I communicate (with trust) to my boss, that our app is spaghetti code

Question

I am the sole developer at a company. Before I came on board, the app was developed by a freelancer.

I am working through the code base and making massive improvements. These improvements are not immediately appreciable users and our 100% non technical staff.

Basically the app is spaghetti code. There are horrible anti patterns everywhere. Violations of OOP and encapsulation. Adopted libraries and patterns meant to separate business logic and presentation.....then intermix them anyways. Disregard for properly handling all valid error cases.

I am taking time to make massive improvements....but with no appreciable change. In addition, since I am the only developer at the company, the boss has no way to gauge if I am doing good work.....which makes me feel awkward. I want the boss to know I do good work.

How do I communicate to the boss that the code was bad and I am making it good in a better manner than "the code was bad, I am making it good". As well, how do I do so in a manner that builds trust?

The company had a third party consultant as a trusted adviser (who helped interview me). I almost want to suggest that he review my changes.

Answer 1

Basically the app is spaghetti code. There are horrible anti patterns everywhere.

Avoid shit talking the code base and previous developers. It makes you look bad and untrustworthy. You don't know under what circumstances the code was written.

It's also becoming a very common excuse these days. Developers finding something too complicated or don't understand a programming concept, so they blame it on "bad code".

How do I communicate to the boss that the code was bad and I am making it good

Don't say it's bad. You can simply say, the code doesn't follow best practice, so you need time to re-factor which will have the following benefits... List them out.

Edit: As per comments. It may be best to avoid saying "doesn't follow best practice", as best practice changes over time. Instead you could just keep it to the benefits eg: "I need to refactor some of the code, this will help make the code more readable, less prone to bugs and easier to maintain." etc...

I am taking time to make massive improvements....but with no appreciable change. In addition, since I am the only developer at the company, the boss has no way to gauge if I am doing good work.....which makes me feel awkward. I want the boss to know I do good work.

Why make changes that aren't important enough to be noticed, that's a waste of time!

I assume you mean changes that will lead to long term improvement, in which case don't say they don't have any appreciable change, because they do.

What were you hired to do?

You need to think about the business aims and goals. Before doing anything with the code, talk to the boss and discuss the goals.

Create a list of high level goals, and create a list of tasks that achieve the goals. Each task can include if it's long or short term.

Share this list with your boss, and put them into a task tracker, and continue to give status updates as you work through them.

Your boss can then see the progress you're making, understands why the work is being done, what goals they achieve and when results can be expected.

Answer 2

The way you build trust with an employer is to understand and show how you're contributing towards their goals. Otherwise you are definitely seen as disposable.

Your first challenge is to understand the goals and pain points of your boss and organization around this app. You don't seem to be clear if you're supposed to be doing feature development, or bug fixing, or what and seem to just be using your time to refactor. In the unlikely case they decided to spend a lot of money just to hire a "code babysitter," then that's fine, but I imagine they have things they either want done or fixed or improved.

Your second challenge is to understand why you are refactoring. You don't seem to know that either, except for "this is theoretically bad and this is theoretically better," and believe there's no user benefit. This is troubling. Ideally handling more errors would be helping reduce bugs and problems users are having. Or making these changes will make it easier and faster to add new features by some percent. In the end, these improvements should be surfaced to your boss in this way. "I can do these three new things in a month, or I can do this refactor for a month and then doing those three new things will only take a week and ones after will be faster too..."

So figure out what your org needs done, figure out why you're doing the things you're doing, and then work with your boss to fold those together. Usually you should be doing a mix of delivering features/fixes people want and refactoring, lest you get fired in six months as the "never did anything guy." And if you are unable to explain the benefits of a specific improvement in terms of more successful outcomes it will produce, you should consider that maybe it's not a benefit. No one cares or should care about artificial software metrics, those are internal means to an end, not an end in themselves.

Autonomy is not given so you can not understand and work towards these goals, it's given in expectation that you are senior enough you'll be able to lead this process.

Answer 3

flexi and mxyzplk's answers are both good situational answers. I'd like to contrribute a more literal answer.

How do I communicate to the boss that the code was bad and I am making it good in a better manner than "the code was bad, I am making it good". As well, how do I do so in a manner that builds trust?

If you are really the sole developer, and the only person there with non-superficial technical knowledge, then

• they already trust you, because they have no choice.
• there is very little point in being more detailed than "the code was bad, I am making it good".

The key is to not abuse the trust they (are forced to) already have in you.

If the code really is bad and you really do need to improve it in order to add some feature that they are asking for, you can explain it something like this:

"OK, as I understand it, we want to make the foofar register a lemlon every time it gezbars. That's not a very complicated thing on a conceptual level, and would ordinarily take me about a week to implement. However, in our system, the foofars were built in a way where there is no straightforward way for them to register lemlons. So I'll need to fix that before I can get to the main problem, and it will probably take three weeks to finish it instead. The good news is that, after this, the next time we need foofars to register lemlons for some other reason, it will be a much easier change to make."

You build (or rather, maintain) trust over time as they recognize that your explanations are truthful.

Answer 4

I like the answers from Flexi and Helena, but this touches on a very hard lesson that I had to learn once being in OP's situation that the other answers don't bring up.

If you are a good developer and you understand the code base and the code as it now pretty much works, then you can find a way to work with it.

A practical way to develop trust is to demonstrate a consistent ability to estimate for tasks and deliver close to those estimates. It's not so much about personal trust and gut feelings it's about establishing a pattern of communication and behaviour that builds confidence in your ability to deliver.

As poor as the code is, if it works, then the product owner is not likely to appreciate or approve the large amount of time that it might take to ovehaul the whole lot. Usually the exact amount of time is unknown and often blows out of budget anyway, especially if the PO adds in improvements as you go.

• These improvements or change requests, while good natured, blur the lines between the effort it takes you to implement the requests and the effort that you spend on code base improvements. You should only undertake code improvement in a way that you can accurately separate the record of your efforts between the two tasks.

• If you can't effectively estimate or you fail to deliver on deadlines, any trust you may have had at the start can quickly break down.

• before starting an overhaul however small, keep this chart in mind from xkcd: Is it worth the time. In this case the time you are trying to save is the next developer's time or the time it may take to complete the next request.
  

There are long term benefits to improving the code, the actual cost of that improvement however can often exceed the cost of starting again, or worse, after the improvement process is complete, it may not attract any additional clients or usage. If your changes do not provide any improvement to the end user it makes it hard to increase fees or charges to raise the revenue to cover your effort.

Being the only developer in the team brings with it a very large obligation to see it through and represents significant risk to the product.

Whilst in a perfect world we would like to leave every class structure that we touch in a better state than it was before, in a business world it is OK to leave these classes in the same or similar functional state, the time to re-write a class and its dependencies to assist the next interation of development is sometimes a luxury that the product owner cannot afford, even if we can justify it.

• A good developer should be able to be pragmatic in this regard and be agile enough in their personal views to accept that the PO is generally paying for change they can see, so let them know that a task will take longer to complete due to the lagacy the code brings with it, you can also offer a counter estimate that includes cleaning up that area of code as well, but let PO own the decision on if or when substantial changes should be made for the sake of it.
• A good developer should be prepared to accept leaving the program in a better functional state to satisfy time and resource constraints, even if that means leaving it in the mess that is was already in, just don't make it worse...

If you can see improvements to be made, the first thing you should ask for is a set amount of time to conduct a review of the code base and to produce some estimates on areas that you would like to change.

• Focus on process that improves time to market first, but implementing a good process of how new changes are requested, estimated, implemented, reviewed and deployed will help set a standard for all future work.
• Consider implementation of DevOps strategies like CI/CD as well as a level of test automation. You want all of your new work to be solid, if you are pushing for new process or paradigms, make sure your work is representative of how you could improve the whole solution.
  • This doesn't have to be all-in, focus on time saving strategies that make you more productive day to day

A radical option is to request an allocation of time to work on a complete overhaul, do this in a separate branch or as a completely new application, perhaps 1 day in every week or every 2 weeks. Over time you try to develop this side project until it reaches feature parity with the first one. This often represents a marketing option for PO, at some point you only put new features into the new application and can raise revenue through the sale/distribution of the new application as you have now created a clear value proposition.

Answer 5

Learn to speak your boss's language

What does your boss want?

• Increase profits
• Reduce operating costs
• Reduce risk (note that in a lot of companies, reducing operating costs outranks reducing risk, because operating cost is always visible on your quarterly sheets while risks only sometimes turn into actual incidents)
• Predictable results (new feature is done when you said it'd be done)
• Quick results (new feature is done quickly)

Code quality can help with these points. A healthy code base makes it easier to develop new stuff, and less stuff will break. This is something you can sell to your boss.

But you have to make sure that it actually does - if you spend a month cleaning up code that doesn't do anything important, you're not being useful to the company. So you have to view the codebase from two directions - technical and bussiness. And you need to aim your efforts where the combination of these two has the highest value.

Don't do standalone code quality projects. Each project has to also cater to a bussiness need, and in a way that you can demonstrate to bussiness oriented people. If you can say "thanks to refactoring, doing the payroll calculation now takes an hour instead of a day" then the accountancy department can easily see the bussiness value of that. They don't care that it's because you removed stupid loop constructions.

Answer 6

How do I communicate to the boss that the code was bad and I am making it good in a better manner than "the code was bad, I am making it good". As well, how do I do so in a manner that builds trust?

You don't. Change your narrative instead from "The code was pure crap and I make it Ok" to "The code was OK, it delivered what it needed, but I am making it way better than it was before." That approach has two advantages: 1.) Without doing anything differently you change the perception from someone who makes Ok code to someone who makes even better code.

2.) You don't blame any of the managers for letting the code quality deteriorate under their watch. Imagine your manager has to tell their manager what you are spending your time on "He is spending weeks to get to an industry standard level." "Why was the code below standard in the first place?" "I guess I slept on the job and I failed as a manager" (Spoiler alert: won't happen).

Since you are the only tech person, usually nobody will care about any technical details, complexity metrics, architecture, test coverage, CI/CD, this is just technobabble to them. Instead you can promote your work by focusing on outcome from their point of view (also see ObscureOwl's answer):

• Faster deployments and shorter time to market
• Fewer open bugs
• Less server down-time
• More new features faster
• Less recurring issues

Externally nobody cares whether you have decent test coverage or not, but since you are the engineer you decide what kind test coverage is best to achieve your goals and you just go with what helps delivering these results.

Answer 7

• It you have a code metrics tool available, use it. We used Sonar once for a Java project, and there was nothing better to get the Project lead on board than having a clear metric

• Define coding guidelines, estimate the changes and prioritize.

• Define unit tests

The best would be if you can provide examples to your boss where not keeping the guidelines actually increased the effort.