How should I go about learning a very large and complex application?

Question

Being a young and fairly inexperienced developer recently employed by a "real" software company I'd like some opinions and pointers on how to do the following:

Approaches on how to get familiar with a companies products , especially when you've no idea how it all works. The company I'm at now has one HUGE product , continually evolving and having been here for 2 weeks I've still no idea how it all sticks together apart from a special kind of glue made from the tears and frustration of young developers, it's incredibly fragmented and only 4 people in the office know the inner workings, all of them constantly busy

Give useful input on the product : Now, I know I'm just a kid in the company and I can't be expected to deliver anything ground-breaking in my first months, but you have to give as much as you're paid. I'm getting around twice as much as at my previous job but objectively speaking I've not done anything to deserve it yet. Just sat around staring at my laptop screen trying to decipher code. Now you might say that this is what I'm here for , to start off with at least, but at my previous job I was something of a go-to-guy, making decisions and contributing to almost every aspect of the company's daily running. While that was a lot of work I enjoyed the feeling of being 'connected' in the inner workings of the company I have a stake in (a symbiotic relationship if you will).please edit this point down, I'll leave it up to you guys to decide what's important

I'll post more things as I think of them, have to get back to reading and writing something only vaguely resembling C#

Answer 1

2 weeks ? In my second job it was quite common for new hires to only get the 'oh! i get it now!' moment 9 months in....

If it is genuinely a huge product then they will expect a long time to 'get' it, just keep working hard and ask plenty of questions.

Answer 2

Even as a not-so-new developer, I often find myself thrust into situations where I have no idea how the software works or is designed (if it was designed). Often if there is someone around to ask, they don't know much more than I do, or are wrapped up in something else.

• First step - Get prepared. Install a dev environment, get a notebook, clear off a whiteboard. If there are any design docs, find them and have them available for reference. @mcottle's answer is a great one. If you want to understand a system, you need to approach it like you're going to [take a test]/[teach someone else]. Write down lots of questions, draw relationships between components, and keep track of things that surprised you. If a new developer were to put together a rough sketch of the system in a format (wiki, document, whatever) that I could pass around to other new developers as a starting point - 1 million brownie points in my book.

• Second step - Approach it as a user. What is this software for? What problem is it designed to solve? Read the manual. This will hopefully give you some context as you move on.

• Third step - Determine the edges of the system. Where does input come from? What's the final result?

• Fourth step - Trace an input through the code base. Don't get too hung up in the details on the first pass, just write down questions as you go. As you make additional passes you can try and answer those questions and generate new ones.

• Fifth step - Find the seams in the system. The idea here is to find the major architectural layers (an I/O or network boundary is usually a good thing to document).

• Sixth step - Now move on to breaking things into components. Is the system modular enough that you can think about X without wondering what's happening to Y and Z? If not, document that relationship. From here you can divide and conquer your way through the system, breaking each component down until you reach a "good enough" understanding.

Note that this is a fairly thorough method. In a very large project you'll likely be able to go a very long time without needing to know exactly how the Foo module interacts with Bar. I would strive to learn enough about the system that I know which parts I feel comfortable changing and which are shrouded in mystery. This is normal in any project; there are always libraries where you use 5% of the functionality and remain blissfully ignorant of the rest.

Answer 3

I assume you have already installed the development environment and have all the necessary tools working - if not, start with these. Setting up your dev environment usually takes a lot of time, with long idle periods waiting for software to download/install, while you can still do other things.

About your lack of information, I suggest you talk to your fellow developers and manager. If the senior devs are busy, talk to the others - they may be able to explain some things to you, or point you to documentation sources, and/or they are also frustrated by not having the full picture. In the latter case, you can approach your manager together, to work out some solution to your problem.

Even if the seniors are fully engaged, they probably understand that spending some time on teaching/mentoring the juniors now may reduce their workload in the long run. But it is management who ultimately decides about task assignment, so the decision is theirs to make.

Answer 4

One tip, ask lots of questions but not as you think of them. Keep a list of questions and when you do get time with a senior developer bring out the list. It's a far more efficient use of their time to answer 10 well thought through questions in on burst than five questions over the course of a day that interrupts their focus.

Consider using e-mail if they'd prefer that.

When you have the answer to a question, document it. If there's a wiki use it. If there isn't create one. Even tiddlywiki would be better than nothing.

Answer 5

If I were you wouldn't worry so much about understanding "how it all works". If you are hired as a junior/inexperienced then focus on your tasks and ask questions when time given. For example when you are given a new task try to use that connection with your seniors to ask more general questions but don't ask too many questions at once. Also try to devote a little of your time each day in browsing through other parts the software, documents or whatever you have access to. Before you know it you'll see how it fits together end you'll end up being the senior.

Remember that if you consider it to be fragmented it may not actually be so, maybe you just don't know enough about the product yet.

Answer 6

While I admire those who can sit back and read code like they read a novel, I find it a bit tedious at times and that it does not really work with large complex software products and libraries.

I wrote a long post about reading and understanding code here that might be useful for this particular discussion - technikhil.wordpress.com/2010/07/06/how-to-read-code-a-primer The post deals with reading code in the context of improving oneself, so it talks about how to go about finding good code to read; but in this case since you already have identified the code you want to comprehend - these points might be useful -

1. Go through the design documentation and try to get a feel for the way the code has been built. Good software projects follow certain architectural patterns – these dictate the code organization. Once you get a handle on this, understanding the code becomes a whole lot easier. If you can create a class diagram of the code you can get a good idea of the layout.
2. The next thing to do is to compile it and run it. This can be straightforward or tough depending on the process followed in the project and it’s documentation.
3. Now it’s time to fire up your favorite IDE and go exploring. A good place to start your code exploration would be to try to trace a functionality of the project that you are familiar with. This would let you go through the various layers and sub-systems and get a handle on how they inter-connect. For example when I was exploring NUnit – I started by writing a test and looking at the code classes I needed to do that.
4. Try and identify the design patterns used in the code. If you do not know what design patterns are, then you need to stop reading this post right now and read this book. Familiarize yourself with design patterns – they form a great way to recognize and understand the design of well written code. This makes it easier to keep it in your head while reading code. It also helps you identify nuances and customizations made by the programmers more easily.
5. Try to write tests for the code to fully understand it – this is really useful way to understand the dependencies between different parts of the code. When you try to write a test for the code you first need to satisfy (mock) all its dependencies. Next you need to understand the possible entry points as well as the exit values for the code. This improves your understanding of the code and gets you to the next level.
6. Try to refactor the code. In this step you have moved from simply understanding the code to becoming familiar enough to be able to modify it. As the sophistication of your refactoring increases so too does your understanding.

Answer 7

Also, if it's a truly huge project, you may not ever know how all of it works. You may only know the details of a few modules, and then just know how they interact with other modules. Very few engineers are experts on an entire system.

Answer 8

Everyones different but I found the best way I came to grips quickly was to do the "hard" yards and get down and learning. Basically this involved reading and more reading, investigating and more investigating and not being afraid to ask questions (although in the right situation and time).

If there are log files, look into these. I found to a certain degree being involved in looking into bugs was a great way to start coming to grips with the project. Although boring and not the most enjoyable it gave me a chance to really delve deep into a solution. As long as you are prepared to investigate an issue as thoroughly as you can. Even if you can't resolve it yourself and need to escalate it to a senior member, if you have shown your ability to really look into the issue and can help point out the areas you investigated and even offer your own opinions on what might be going wrong.

I found that senior members were more willing to sit down and then go through it with you at your desk if they know you have already taken the time to do alot of the donkey work.

An important note which may help you is when you ask questions try to write down the answer so that you do not make the same mistake of asking again. Although most senior developers have a great deal of patience for juniors it can quickly wear thin when the junior does not seem to be paying attention to what you are saying.

Good luck in your new role.

Answer 9

If the project is really huge, they won't expect you to know it in two weeks, or even two months. If they do, then you are at the wrong place.

My latest position is one where a high degree of relevancy isn't expected on the actual product shipped for a year. To get up to speed I spent a lot of time reading documentation, just playing around with the product/hacking it, and asking a lot of questions. The first few tasks you get (bug fixes, minor changes) should start to get you up to speed with the project. Each one after that should bring more understanding.

I'm sure there is a process that you can have laid out and follow but, I've found it best to just keep plugging away at it. The more you do, the more you will learn.