9

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.

6
  • What did your boss ask you to do with this code when he hired you?
    – sf02
    Dec 18 '20 at 18:19
  • Basically I am the lead developer and code owner of the app.
    – Scorb
    Dec 18 '20 at 18:21
  • 2
    Right, but did he ask you to add new features, or to improve the existing code as you see fit?
    – sf02
    Dec 18 '20 at 18:22
  • 5
    Does this answer your question? How can I convince my manager that we need to reduce technical debt?
    – gnat
    Dec 18 '20 at 19:09
  • 1
    What was the quality of the code as seen from the users as delivered by the previous developer. Dec 19 '20 at 2:21
24

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.

8
  • 3
    +1. I wouldn't go so far as to say "Doesn't follow best practice" because, in 4 years, that best practice might have changed. Patterns change. Instead everything else is right on- since they're non technical you could say "There are many different coding styles which makes reading and maintaining the code far more difficult than it could be. Refactoring reduces these issues, decreases the chance for bugs, and most importantly decreases ramp up time for any developer coming after me, saving the company money". Or similar. It would be bad to find out the 'boss's kid' did the code for a summer..
    – J.Hirsch
    Dec 18 '20 at 20:59
  • 1
    @J.Hirsch really good points.
    – flexi
    Dec 18 '20 at 21:33
  • Been in that position a long time ago, you need to explain everything as how it affects their profitability and expenditures. How will it gain them to fix it, with however much time that will take, or how will it save money. Perhaps the best approach after my own lengthy experience with this situation is to do it in small bites. Identify small sections that in the process of adding a requested feature can be improved. Do it slowly so they get used to the gradual changes.
    – crosenblum
    Dec 21 '20 at 7:35
  • 3
    I remember writing code for a real world problem that required me to have ten workarounds for let's say "interesting" behaviour. My code was complicated. After I was mostly off that project someone convinced my boss that my code was too complicated. He replaced it with really nice, elegant, easy to understand code. On the other hand, each of the ten bugs that I had documented was back.
    – gnasher729
    Dec 21 '20 at 12:48
  • 1
    @StephanBranczyk They actually removed ten different bits of code, each one with comments that described exactly the behaviour that was wrong, and how it was fixed by this code. So that wasn't "a bug re-introduced", it was "a well documented bug-fix removed".
    – gnasher729
    Dec 25 '20 at 0:02
15

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.

4

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.

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.
    Is it worth the time

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.

2

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.

1

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.

0
  • 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.

4
  • Why would there need to be coding guidelines for a sole developer?
    – Helena
    Dec 19 '20 at 9:02
  • I expect they’re supposed to be visable in some sort of way so others can see something, that looks like the OP is preparing for future growth.
    – morbo
    Dec 19 '20 at 10:39
  • 1
    @Helena As a metric to discuss what you need to fix next. With such guideline you can attach a value to every single guideline. And things where the spaghetti code actually caused real proven harm should be fixed first is discussion with the PM
    – Sascha
    Dec 19 '20 at 10:40
  • 2
    -1 because this is the StackOverflow answer, not the Workplace.SE answer. Would be a better fit if you generalize the bullet points and focus more on the impact for the business.
    – Chris
    Dec 19 '20 at 23:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .