Architecture – Fighting technical debt as the “lowest developer”

Architecturemaintainabilityscalabilitysoftwaretechnical-debt

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.

Best Answer

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:>
http://i.stack.imgur.com/ARBSs.jpg

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.

Related Topic