If you are a software engineer, you may move from project to project over the time. How to quickly ramp up with a new project is always a challenge. The term “new” I use here does not mean that the project is new and you need to start from scratch, but that the project is new to you.
Although we all like to start from scratch, the reality is that 80% of engineers are actually doing maintenance works on existing projects: fixing bugs, adding new features, etc.
Bothered by SLOW Web UI to manage vSphere? Want to manage ALL your VMware vCenters, AWS, Azure, Openstack, container behind a SINGLE pane of glass? Want to search, analyze, report, visualize VMs, hosts, networks, datastores, events as easily as Google the Web? Find out more about vSearch 3.0: the search engine for all your private and public clouds.
When you move to a new project, you have to get familiar with existing project before you can contribute. So the ramp up time should be as little as possible. Some people think reading architecture documents and source code is the highest priority. After working on many different projects from Z80 based control system all the way to Java applications, I realize that is not the most efficient and fastest way to get onto a new project.
Here are steps I usually take when coming to a new project:
1. Learn how to build the existing project. This involves steps like syncing code from your source control system, running compiler/builder in your IDE or build tools. You may have to install source control client, IDE, build tools if you have not yet had them on your development machine. This seems easy but may take a lot of time to get right.
2. Learn how to run and debug the project. Here you know what command line, parameters, topology in order to run the system. With these in mind, you can then move onto debugging system with entrance point, breakpoints, stack trace, etc. By this far, you can even start to work on fixing minor bugs.
3. Learn how the system works. One obvious, but often forgotten way by software engineers, way is to play with the system as a typical user. It not only helps you to understand the key concepts and terminologies, but also the flows a user use the system. This is the big picture you should learn before diving into source code. After playing with a software system, I can typically guess out what subsystems and components should be there in the source code.
4. Learn the software architecture. For a new system, I expect to learn the deployment topology, subsystems, interfaces and protocols, object model preferably with UML class diagrams. Ideally you will have an architecture document explaining all these. In reality, you will be surprised to learn the documents are versions behind the current system or there is no such a document.
5. Browsing source code and API reference doc. Before diving into specific source file, you want to understand the overall packaging structure. You should leverage the IDE features like calling hierarchy, reference analysis, etc. Also, don’t expect yourself to read all of the source code. One reason is that there may be too many lines of code to read. More importantly it’s not very productive to read source without a specific goal in mind.
After finishing these steps, you should be comfortable with fixing bugs. Along the way, you should be more familiar with the system and ready to take on challenges of adding new features.
Well, this is only the technical aspect. You have to work on other aspects as well: collaborating with other team members and even customers, understanding project management process, etc. These are all very important, but beyond the scope of this article. I may discuss them later.
What are your experiences and thoughts with new projects? Feel free to share your insights here.