Dealing with large code base quickly in agile

Question

At my current company, the project I work on is coded in Java, at least for the systems / backend part. Whenever I get assigned a task dealing with the Java code, it take me hours or even days to figure everything out and apply my solutions. The reasons are:

1) Very large Java EE code base

2) A lot of abstraction

3) Get lost in figuring out all the abstractions such as methods created by past developers then i often spiral down a hole where i think of something else and forget my original solution etc.

My work environment is agile and I am expected to deliver quickly, but as a fairly new member of the company and a huge code base that was built before i joined, it is difficult for me to meet “agile” timing.

How is one supposed to deal with such a huge code base where nearly every single line/function leads to another abstraction and within those are even more abstractions in a timely manner?

Edit: I know I can ask my colleagues but at the same time i do not want to be constantly bothering them since problem solving is part of my job

Answer 1

The first thing is to realize you don't have to understand the entire code base. The abstraction is there for a reason. Try to mostly trust it works as it claims unless proven otherwise.

The second thing is to keep notes. I do this by writing my main question, something like, "Where do I make this change?", then indented under that I write the questions I need to answer to answer the main question, then questions to answer that question, and so forth. Eventually you get down to a question easy enough to answer, and you can work your way back up.

Answer 2

Without looking at the code base, it's hard to know what's wrong with it if at all. Your description sounds as if previous developers fell in love with abstraction and applied it all over the place. This seems to happen occasionally when developers think a single principle or pattern is the key to good software and apply it indiscriminately wherever they think it can be used. In my experience, there is basically one single principle that helps code readability and maintainability if applied liberally: KISS. Others can be used in moderation and with good judgement.

However, you're not going to change the code base, so this doesn't help in your current situation. Karl Bielefeldts answer is spot-on: Don't get lost by following every abstraction path down to the leaves, but initially trust that the implementations do what the abstractions promise. I found that stepping through code in a debugger helps a lot in seeing how such code is working, so that is something you can do when the control flow is really unclear or when you need to track a bug.

And you should use everything that helps you focus on the problem at hand. Dealing with a complex and largely unfamiliar code base is extremely taxing on your concentration, so take notes, shield yourself from distractions and noise, make breaks as needed to digest what you read and let puzzle pieces fall into place.

Answer 3

Lot of things said already. My contribution is:

Find some mentor for your start into the code

Since you need some navigation through this huge codebase, you could ask someone to do some pair programming, or showing you a way to a solution (not doung all the implementation work for you).

My work environment is agile

Since you mentiond the agile environment I wonder if it is agile in sense of the Agile Manifesto (see here). Since it says there that the agile way values:

Individuals and interactions over processes and tools

and in the list of principles it says

Build projects around motivated individuals.
Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

These two principles could give you an idea in which direction to look for: It is ok to ask for support you need! You should trust in your colleagues that they will watch for their "resource" of patience, and that they will inform you if your questions are too much.

And don't think that you should be perfect right from the start.

Answer 4

If you are using Scrum, you should definitely bring this in a daily standup. It's an impediment and you and your team should try to remove it. You can also talk with the Scrum Master or your supervisor about this.

Your team should have a plan for new employees to familiarize you with the software. For example there should be an extensive documentation or someone should explain to you how it works. Even more so if it's complicated piece of software.

I've been in a similar situation myself. Good luck!

Answer 5

People here have given you some nice practical suggestions; I just wanted to add a couple of higher-level comments.

I know I can ask my colleagues but at the same time i do not want to be constantly bothering them since problem solving is part of my job

A lot of us developers are the sort of people who take pride in our problem-solving skills, and so it almost feels unnatural for us to ask for help. You have to train yourself out of that mindset - sometimes, asking for help is in everyone's best interest (and you and your teammates can figure out how to go about help/training in a way that's not disruptive). Over time, you'll pick up on things, and you'll need less and less help. Also, the activity of trying to sort out (what appears to you as) the impenetrable mess of concepts expressed in legacy code is not the kind of problem solving that's at the center of your job description. It's grunt work. You want to get to solving the actual problems that the software was made for; some grunt work will be required to do that, but a little help from the more experienced members of your team can get you there faster. So it's a matter of finding a balance. A bit of struggling to figure things out on your own will lead to developing a deeper understanding of things, but don't go overboard.

My work environment is agile and I am expected to deliver quickly, but as a fairly new member of the company and a huge code base that was built before i joined, it is difficult for me to meet “agile” timing.

It's difficult to say what the exact source of the problem is without being there; every organization is different. In any case, because of the fact that you are a new member of the team, and that the codebase is the way that it is, it's a given that you'll be needing some help or training. Your organization should know this. The thing is, you are trying to solve the issue, but you are trying to figure it out while working with limited information and with untested assumptions (i.e., you don't know how your organization may (or may not) be able to help you with your issue, you assume your teammates will feel you are bothering them, etc.). You should ask around first; talk to people about these things. Then you'll know what the options are, who to else to talk to, and so on. Then you'll be in a better position to decide how to act.

How is one supposed to deal with such a huge code base where nearly every single line/function leads to another abstraction and within those are even more abstractions

What I'm about to say is more of a general remark, and not really intended to help you solve your current problem (except that it may offer a new perspective). When people complain about abstractions, it either means that they are unfamiliar with the concepts, or that the abstractions themselves are wrong. If it's the first one, great: that is comparatively easy to fix - these concepts and ways of thinking can be taught. The second case is not so easy. You see, good abstractions may introduce structural complexity, and a learning curve, but once you understand the concepts they represent, and the problem domain, they don't make things harder to understand or work with, they make them easier. They should be designed is such a way that, under most circumstances, you shouldn't have to dig 5 levels deep to understand how to write some bit of client code. In fact, there shouldn't even be 5 levels (from your point of view). They shouldn't be more complicated then they need to be. What sometimes happens is that people follow "best practices" without really understanding the reasoning behind them, and you end up with a lot of superfluous abstractions. Instead, abstractions should be designed very deliberately, as tools that make life easier for the developers. Maybe you are struggling with superfluous abstractions here. On the other hand, maybe the original developers had good reasons for introducing them. If it's the former, you can't do much about it, given your current position and the fact that it's a legacy codebase.

Answer 6

My work environment is agile and I am expected to deliver quickly, but as a fairly new member of the company [...]

These two things don't match. If you work for a company that expects you to develop quickly even-though you're new, find another employer because there is no way that's happening.

How is one supposed to deal with such a huge code base where nearly every single line/function leads to another abstraction and within those are even more abstractions in a timely manner?

Tooling. Find some tools that generate UML diagrams based on your code. Visual aides help you learn the code base much quicker than you could by clicking around.

Edit: I know I can ask my colleagues but at the same time i do not want to be constantly bothering them since problem solving is part of my job.

It is also part of their job to pass on knowledge to new colleagues. If you spend 30 minutes trying to figure something out that you could have found out in 5 minutes by asking your colleagues it saves everyone time and effort.

To be honest what I'm reading is that you're concerned you're not fast enough. You're not, and that's ok. Employers usually count on this type of thing with a new hire. So don't worry, and ask as many questions as you can. As if furthers your understanding, shows you're capable of admitting you don't know certain things, shows you're inquisitive and curious about how the code works.

Answer 7

We've all been there! A few things which might help:

Planning poker

Who is time-boxing your tasks? If you're actively involved in the planning process you can feed your input in as to how long something will take. If it is just a team of senior developers pulling the strings, it is easy for them to forget how long it takes to get traction on something if you're new.

Unit tests

Are there unit tests in the code base? If so, you can have a certain level of confidence that you can make changes without breaking something. If there aren't any, this should be raised as a red flag immediately.

Ask targeted questions

Senior developers are going to be more more inclined to help if you can ask specific questions rather than: "How does this work?". Don't be afraid to ask them for technical docs, cheat sheets or anything that can help you hit the ground running.

Story or a spike?

Project managers dislike spikes. But spending some time up front to see how long something will take is far better than saying it will take you 2 days and then it takes you 5.