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"?


  • 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.
  • 3
  • 3
    @gnat, I think the questions are related (especially the last one), but not duplicates. I see this question as "Given the architect of a system is not the implementer, and the implementers are not given a high level view of the system, how can it be assured the implementations are sufficiently flexible or scalable?"
    – MetaFight
    Apr 4, 2014 at 11:07
  • 1
    Are you asking how to fight technical debt in general, or are you asking how to fight technical debt when you are in the role of a coder with no assigned responsibility for improving the architecture?
    – Doc Brown
    Apr 4, 2014 at 11:37
  • 2
    @JosephtheDreamer Yes, there are a lot of things that can be done to improve the source code, but you stated in your question that the problem is a lack of authority to act on any changes. I could tell you all the best practices but if you're not allowed to invest the huge amounts of time to implement them, then what's the point? ;)
    – Reactgular
    Apr 4, 2014 at 14:06
  • 2
    "But the tasks come from the higher people" - what prevents you from giving yourself some tasks, other than "I'm not paid for it" today? If you act like a command-receiving worker bee, you will be treated as one.
    – JensG
    Apr 6, 2014 at 10:10

5 Answers 5


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

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"1...

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.

  • 8
    +1 Good advice, but issue tracking in an environment that doesn't embrace process just becomes a black hole. What good is an issue tracker of one person. At best a fancy to-do list.
    – Reactgular
    Apr 4, 2014 at 14:11
  • @MathewFoscarini prior to posting, I clarified this with OP in comments (linked under "your issue tracking system" in my answer) - 'Yes, hence the "tasks" (issues, tickets, whatever you might call them)...' I would also be not that pessimistic about "black hole" cases, in the long run things tend to change, especially if "lowest level" developers take an initiative and invest effort into maintaining the tracker and promoting its use themselves (been there done that)
    – gnat
    Apr 4, 2014 at 14:14
  • And on top of it, I have seen people being blamed for polluting the ticket system (= opening "too many" tickets). If the culture doesn't fit, no ticket system will help. Unfortunately, technically people tend to look out for a technical tool rather than a solution, and other technical people think of it as good advice because it fits their thinking process.
    – JensG
    Apr 5, 2014 at 16:20
  • 1
    @JensG "people being blamed for polluting the ticket system" - this is a known phenomenon, probably deserving a dedicated question (or maybe it was already asked and answered, I didn't search). If the culture doesn't fit, additional specific efforts needed for ticket system to become helpful (as I wrote in prior comment I've been through that before).
    – gnat
    Apr 5, 2014 at 17:25

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.


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).
  • This answer is exactly what I would do. I don't put petty refactoring tasks into the issue tracker. I just refactor. Putting every little bit of technical debt into the backlog of issues just creates a huge list of issues, which will make it hard for them to gain visibility, and by the time anybody works on such a task, the issue may be gone, changed form, worsened, moved, or who knows what. If it takes 5 minutes, just fix it!
    – Brandon
    Aug 6, 2018 at 17:55

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.

  • 2
    "Technical debt rarely causes the employment-ending failure of an enterprise." I wouldn't be so sure. The reason behind failure of many software projects is a technical debt.
    – Euphoric
    Apr 4, 2014 at 13:19
  • 2
    A project is not an enterprise, @Euphoric. Mozilla is not defunct just because Sunbird never took off. If your project fails, you go on to a new project with the same employer. If your enterprise fails, you need to find a new job.
    – DougM
    Apr 4, 2014 at 13:55
  • This answer is very wrong. I have seen technical debt destroy an enterprise product. And as for "technically debt are literally not your problem", whose responsibility is it, if not the software developers?
    – Brandon
    Aug 6, 2018 at 17:59

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.

  • 4
    is this only your opinion or you can back it up somehow? At OP ("lowest") level, "stepping on the brake, saying no" in my experience rarely turned out okay. Neither for project, nor for career. Looking back I can clearly recall cases when I missed a thing or two when "saying no" against the vision of senior colleagues / lead / manager
    – gnat
    Apr 4, 2014 at 14:25
  • In terms of human resource, putting people behind work tickets without proper handling of their work value concerns is likely to end up in a disaster. Happy workers work more for less, there is economic proof of that. Stepping on the brakes is a learning opportunity for both the junior and the management. Stepping on brakes is how startups can be so competent in so little time, we don't have friggin tickets. It may rise conflict, but conflict is part of the goddamn life. Caring about quality should be listened to and enforced, so I'm on the step on brakes side.
    – Diane M
    Apr 4, 2014 at 20:22
  • 2
    I recommend this reading which treat about low-level devs empowering joelonsoftware.com/articles/TwoStories.html
    – Diane M
    Apr 4, 2014 at 20:35

Your Answer

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

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