Fighting technical debt as the “lowest developer”?

Question

Let's say you work for a company and what you do is develop software for them. You have no idea of the big picture or maybe slight. What you do have are tasks assigned to you via issue tracking system. You're given tasks, you make them work the way the task describes them, you send them back. Like adding 2 integers:

function add(a,b){return a + b;}

But later, as the project goes forward, you notice that as add becomes more complex, you realize that it should have needed some form of architecture, more than just a function that adds parameters and returns a value. However, you didn't know that. In the first place, all they needed was that simple add. You didn't expect add to become so complex.

The project progresses with more features, which you didn't expect to have in the first place. And in the end, you keep piling up hacks and layer upon layer of functions to avoid breaking/rewriting the existing code.

How do you deal with these situations? How do you fight technical debt as "the lowest developer"?

Clarification:

• You're the "implementer", the lowest in the hierarchy.

• You see the problem, but have no say with the matter.

• I'm not quantifying technical debt or looking for tools.

• Regarding the third "duplicate"

  • Refactoring & Rewrite - You are locked to your tasks. You are not paid to do extra.
  • Architecture Overview - You know the overall system, but no idea of the architecture.
  • Code Freeze - Not your call. You're not management.
  • Modularization - No idea of architecture. Modules change as requirements change.
  • Automated Tests - None exists.

Answer 1

Every time you notice something like that, enter a new ticket into your issue tracking system.

Make a habit to use issue tracker as a primary tool to communicate stuff like that, because from there, it will be easy to pick, evaluate and prioritize for your senior colleagues / lead / manager / whoever is responsible for tracking the issues in your project.

Use the right tool for the job. I do it always and strongly recommend you do the same.

As an example, here is a ticket I created about a month ago. Upon completion of particular feature I discovered that code became substantially more complicated than it was before but I can't fix that within deadline given for feature implementation.

(Names of the features, tickets and code used in the real tracker is obscured, but the text is copied as is).

Summary: simplify design involving ParticularPieceOfCode

Description:
In the course of implementation per TICKET-12345, code involving usage of ParticularPieceOfCode accrued a bit of complication and became rather difficult to read, understand and maintain (see example code snippet below).

Find a way to simplify it.

An example of code which would be desirable to redesign can be found in ClassName#methodName:

<a piece of code like one behind the right door here:>

---

FWIW my advice applies independently of what "level" you are.

I've been using it at your current ("lowest") level and I am using it now that my level is quite far from "lowest" and I have satisfactory "say" as you call it, and I am going to use it always no matter what.

Just think of it, no level, no matter how much authority you have, there just can't be no better way.

If you "say" hey we've got an issue, it's only air rattling. And even if your boss / lead agrees and says you're right, we've got an issue, this changes nothing - it's only air rattling yet again, and it can't be anything else.

• ^{You may think that having your say written (eg in email) would be better, but if you think of it, it really isn't. If your project has substantial mail activity, what was written will be lost and long forgotten a month later.}

Use the right tool for the job. For the job you describe, issue tracker is exactly the right tool.

You notice the issue, you enter it into system designed for tracking these and it takes care of the rest, in the best possible way - simply because it was designed for that:

computer software package that manages and maintains lists of issues, as needed by an organization... commonly used... to create, update, and resolve reported customer issues, or even issues reported by that organization's other employees... An issue tracking system is similar to a "bugtracker", and often, a software company will sell both, and some bugtrackers are capable of being used as an issue tracking system, and vice versa. Consistent use of an issue or bug tracking system is considered one of the "hallmarks of a good software team"¹...

Whatever other means you would want to choose to communicate, having a ticket in tracker will only make it easier for you.

Even if you prefer to rattle the air, saying "I'd want to discuss TICKET-54321..." makes a more solid starting point than "Listen I'd want to talk about some piece of code I dealt with a while ago..." And you can safely pass the references to ticket by mail: even if mail gets lost, the issue will still be there in the tracker, with all the details you wanted to tell about.

Answer 2

What makes me feeling bad about your scenario is exactly what you wrote in the headline and multiple times in the question text:

You are the lowest developer in the chain

Why is that point so important? Well, first of all, and from a purely technically viewpoint, you are certainly right. You are hired as what you call an "implementor" of things, a worker bee that acts upon commands given.

But even if you are the lowest developer with regard to rank, this still is not quite right. The key here is to realize, that you are only perceiving yourself as being the lowest developer. Have you ever tried to overcome that self-perception and actually take over responsibility for something?

Take! Not wait, until someone makes you responsible.

• You see the problem, but have no say with the matter.
• I'm not quantifying technical debt or looking for tools.
• You are locked to your tasks. You are not paid to do extra.
• Not your call. You're not management.

Typically it is quite the opposite: You are paid more and your opinion is respected more, once you show that you are worth the money. It's "do before have", not the other way round.

What I expect from the people within my team is exactly that: A sense of responsibility for the project or product we are trying to build and for all the processes related to that effort. Whenever someone in my team impresses me by taking over responsibility, e.g. proposing improvements or even better start to improve things on their own, these are the people that will get promoted.

To put it the other way: Nobody promotes worker bees, people passively waiting for tasks being assigned to them, lacking even the tiniest blink of initiative "because they are not paid for it", finally whining that they never had a chance.

Of course, all of this again depends on the culture of your company, to what Joel relates to in the "Two Stories" linked by Arthur. If the company managers are really that stupid to block their own people from making progress, then the fluctuation ratio is probably already very high and it may be time to draw conclusions from that. But if that is not the case, the real problem might be within yourself.

Answer 3

You're a professional. Your employer hired you to be professional. So, treat your concerns the same way you'd want professionals you hire to treat their professional opinions. In particular, you expect other professionals to make necessary optimizations and corrections along the way, provided those optimizations don't unexpectedly increase the cost.

For instance, suppose you take your car to a mechanic to have a lamp replaced. The mechanic notices four things:

1. The wire leading to the lamp is frayed and dangerous. But, it can be trimmed without notably increasing the cost. You'd expect him to take a few minutes to trim the wire, possibly without even noting it.
2. A bolt is loose. It's totally unrelated, he just happened to see it. It's 20 seconds of his time to grab the necessary driver and tighten it; so, you'd expect him to do it.
3. The chassis for the lamp is cracked, which will cause the lamp to rattle. It's expensive to replace. And it's not essential. So, he calls you to ask about it -- if you say "no", he puts a written recommendation on your visit summary.
4. There's a fair amount of brake fluid under the car. He should, and may even be required as a professional, to prevent you from using the car until you allow someone to fix the leak.

Each of these scenarios, and I'm sure others, have parallels in software development -- especially if you consider yourself a professional of any level. As a professional, with very very few exceptions, your job is to reach the end-goal of improving the product in a particular way according to your professional understanding.

1. If the fix is trivial, whether unrelated or not, make the fix.
2. If the fix is non-trivial and unnecessary, make a formal recommendation using whatever formal communication/issue-tracking mechanism you've agreed on.
3. If a case can be made that the fix is necessary to accomplish the primary task, but will unexpectedly increase cost, communicate the scope change.
4. If the identified problem poses a serious threat to the success of the project, make that clear. Formally. If there are ethical concerns with allowing the problem to go unfixed (like in health, emergency, or transportation systems), insist on addressing the problem before the product ships (notify the media or authorities if ethically necessary).

Answer 4

You do this the same way a clerk in a law office fights unethical behavior, a fast food worker fights unsanitary behavior, or a parking enforcement officer fights police corruption.

1. Be a good example. To the extent you can, produce clean and sensible code. When given a choice, choose the one that meets your requiremets with less downside. (Be aware that technical debt is not unlike mortage debt -- just having it isn't necessarily a bad thing.)
2. Communicate your concerns. You should have someone, either a team lead or customer or architect, who has the actual responsibility for managing technical debt and allocating your enterprise's resources. When you see something that you believe is bad, communicate your concern to them. Put it in writing (i.e., an email) if you're not confident that they will understand, respond to, and give credit for your input.
3. Don't stress. Technical debt rarely causes the employment-ending failure of an enterprise. So long as you've communicated your concerns and are doing your work, arcitecture issues such as technical debt are literally not your problem. Yes, they may affect you, but they're no more your worry than a sheriff's re-election is the worry of a junior police officer.

---

In the example you provided, with an add function that has suffered complete feature creep, take a few minutes and draft the outline of what would improve it. Send that to whomever you would need approval to implement it, and move on.

Assuming your enterprise was managed by extremely competent people and structured correctly, either your concern would be routed to the right system designer for a decision or you would be given leeway to implement your suggestion. As a junior developer, I'd worry more about learning how your enterprise works than technical debt -- and if you know the former, how to handle the latter should be obvious.

Answer 5

I have never heard of an organization that didn't want it's employees to participate. You say that you are only paid to do the tasks. I sincerely doubt you have the right tasks in mind. Because you are paid to write good software.

Take this responsibility. Say no to adding features if you can't support the base. Advice the customer with your expertise. Step on the brakes now, before it's too late and you have to throw away the entire project, because it will no longer be maintainable.