Switching Projects

I've had to work on a couple of different Software solutions in my 5 year career. Each time I've made the transition I've felt like a fish out of water for the first couple of months while I learn what the software does, how the code works, and what processes and tools the team uses. In order to save some hassle during the next transition, here are a few tips and suggestions for transitioning to a new role to maintain an existing application.

1) Read through any documentation that the client is expected to read. This will give you an idea of how the product works (helpful in recreating/unit testing later) and introduce you to the terminology used by the software team and clients (useful in communicating with others).

2) Walk through the software and play around with it. As mentioned above, you will eventually be expected to navigate around the software to unit test it and to recreate defects. The more you become familiar with the project at the beginning, the easier your task will be later. But remember, when doing your testing, make certain you do so on a stable build. Encountering defects while you are still learning the system can be confusing.

3) Setup your development environment and download the source code, following any documentation that your team might have. I really like the suggestion Joel Spolsky made on the StackOverflow podcast #80, if the documentation is inaccurate, fix it. If it isn't detailed enough, add to it. If it doesn't exist at all, then write it yourself.

4) Are there any special design documents, a wiki, or some other supplementary documentation for the code? While these documents are rarely kept up to date, they may explain how certain key features of the software work.

5) Learn the basic structure of the code, and learn what the key methods and classes are. It's best to try to learn this on your own, but if you make an effort to learn the code before asking another member of the team for help, most of the times they will be happy to help you.

6) Learn who the key people for the project are. There's always key people for any project, the project leader, the lead developer, and often there's a business analyst, and a lead QA Engineer. It is important to know who these people are and understand how you will be expected to interact with them on designs, code hand-offs, and defects.

7) If there are any Third Party utilities used by the software, learn where they are used and make certain you understand how to use them. Some may be as simple as an external library, while others may as complex as Document/Report generation tools or Business Logic tools. It would be foolish to expect you could become an expert in these tools, but you should at least know what each do.



This should provide you with a rough outline of what to do when you are assigned to a new project. Depending on the work load you are given, you may not be able to accomplish everything on this list, at least not initially, but everything on this list is important and should be done eventually if you want to be able to contribute to the project at a high level.

The current state of your Development Team

If you're a manager of a software development project, how do you gauge the morale and mood of the team? I mentioned in a previous post that my boss recently took the direct approach and asked us all to answer a series of questions relating to our morale and such.

For this approach to work though, I'm pretty certain everyone needs to be honest. Given the current working environment (high unemployment, worry of layoffs, pay cuts, etc.), its unlikely that many, if any of the team members provided accurate results. There's just too high a risk that the information could be used maliciously. Personally, I provided a lot of well thought out responses that are true, but I certainly didn't share all of my thoughts on the questions and I carefully edited the responses. Wouldn't you?

I suppose the answer to that question is “It depends on the situation.” What kind of work environment is it, what's the culture of the company, what's the history of the company, what is the management team like, and how the question was asked. In some corporations, the level of distrust between management and employees may be too high to get useful responses from an employee directly.

But surely there are other ways to find out the current state of your team besides asking the team members directly? None of my other managers has ever asked the team what their morale is directly like my current manager, but surely they still had a good idea of what the team's morale was like?

And I think the answer to that is quite simple; all of my previous managers tried to engage the team members in meetings or in hallways. By talking to each members of the team on a regular basis over a long period of time, they were able to discern when the attitude of the team had turned sour and try to improve it when needed.

But as a manager, asking employees directly is probably not the best approach unless you're certain your team trusts you enough not to use the information maliciously.

Recommended Reading

Here's my recommended reading list, with computer science or computer engineer students in mind, as well as junior Software Developers.

Code Complete by Steve McConnell
A must read for all Junior programmers, Code Complete covers everything you need to get started in professional software development. My College education was very heavy on the theory and didn't cover much of the actual practice of Software development. This book helped bridge the gap and should be required reading for seniors in a Computer Science program.

Design Patterns by Gamma, Helm, Johnson, and Vlissides
This is the ultimate book on software design. Its over 15 years old, but it is still packed full of useful information. You'll find that many of the common libraries that you come across use some of the patterns laid out in this book, and it is helpful to understand their convention. I've always found this book to be a little difficult to read because all of the code samples are in Smalltalk, but if you can learn enough
Smalltalk to understand the samples, this book should make sense to you.

Refactoring by Martin Fowler
If you've done maintenance programming of any kind, you'll have an appreciation for the principles and steps defined in Refactoring: Improving the Design of Existing Code. This book explains many common Refactorings, reasons why you might want to do them, and suggestions on how to perform Refactoring on large projects.

Refactoring to Patterns by Joshua Kerievsky
Ideally, you should read this book after reading Refactoring and Design Patterns, but I actually read Refactoring after this book. I was still able to understand this book, which is a huge achievement both for the author of this book, Joshua Kerievsky and the author of Refactoring, Martin Fowler, who came up with very simple and easily understood names for his common refactorings. With better examples then that provided in the original Design Patterns book, I was able to fully understand the power and beauty of the Design Patterns.

Web Technologies by Jeffrey C. Jackson
If your College experience is/was like mine, then you covered regarding Web development. With nearly everything on the web these days, understanding the technologies behind it is essential. This book covers many different Web Technologies, including HTTP request, HTML, CSS, JavaScript, Java Server Pages, and Web Services. This book serves as a good introductory or intermediate text book on the Web.

Mythical Man Month by Frederick Brooks
This is the quintessential book on project management. The lessons taught in this book are so important, that you may have already learned them from others or through other books, as this has been a very influential book. But just as you might choose to read Poe's The Raven despite having seen it parodied by dozens of cartoons and shows, so to is it important to read the original source for many ideas in project management and software development.

201 Principles of Software Development by Alan M. Davis
I've just picked up this book a few weeks ago. It is a very simple read. Each of the principles takes about just a few sentences to explain, and then the author provides a link to the original source of the principal. If you've run out of books to read on software development, this one just might point you in the direction of a few other great books.

Dreaming in Code by Scott Rosenberg
All of the other books are pretty technical and can be difficult to read. Dreaming in Code reads like a story because it is one. It is the story of a software project named Chandler. The book follows the course of the project for the first couple years after its inception. The book outlines delay after delay, and gives an insite into the software development process and shows that even the smartest programmers may miss the mark.


I have a few other books I'm currently working on, but reviews of them will have to wait for a second installment at a latter date.

If you are looking for a good introductory book for a particular language for cheap, Barnes and Noble used to publish and carry a series of books on different languages, but they do not appear on their shelves. Since I live next to a Borders, I rarely find myself in a Barnes and Nobles so I haven't verified that they still carry these books.