In my book, “C# Design and Development,” I propose a lot of management techniques that could apply to any language. In fact, I’ve used the techniques in this book successfully for years with Visual Basic, C#, IronPython, C++, and PHP, among many others. The idea behind the concepts in this book is to create code that performs well from the outset and is easy to maintain when changes are required. In today’s environment, you can count on changes at some point. There are many reasons to expect changes:
- The business is bought by someone else and the code must be integrated into a new system.
- A change in some other component necessitates a change in the application (such as the changes in Vista and Windows 7 security).
- The business has grown and now needs new features to support its customers.
- Modifications in the law mean changes to the way the application interacts with data.
- Technology changes in such a way that the application no longer works properly.
In fact, the reasons for change are endless. I could probably continue writing reasons for change for hours and not cover even a small number of them. The point is that applications will change at some point—it’s simply a matter of time.
If you’ve written code for any time at all, you know that feeling in the pit of your stomach when you discover the perfectly lucid comments you wrote at the time you created the application are no long lucid now. Worse still, the documentation you put together doesn’t tell you what you did and why. Still, after a few hours of looking at your comments and documentation, you can usually begin to fit the pieces together of an application you created because you can recreate the thought patterns you had when you designed and wrote it in the first place.
However, what happens when you’re part of a team or you’re working on an application that someone else designed? Now there isn’t any way to “get back into the groove” of what you did in the past. The thought processes are foreign, so the comments and documentation have to be as comprehensive as possible. Even with great comments and documentation, it’s going to take a while to get up and running with the code.
The longer it takes you to recreate the ideas that went into creating the code, the longer the project update languishes and the more extreme management’s position becomes. The only thing that management knows is that your application (the one you inherited from someone else) is costing the business money. Not only is there a cost associated with the update, but the delay costs the organization money too. Users who have to fight with an outdated application are always unhappy and aren’t productive. So, what techniques can you use to become productive as quickly as possible? That’s what I’d like to know as well. Obviously, reading the documentation and comments are two pieces to the puzzle, but what other techniques do you use?
I’m currently putting an article together that discusses this topic in detail and I’d like to hear about your techniques. If you’ve ever been frustrated by someone else’s code, write me at John@JohnMuellerBooks.com. I’ll let you know when the article is published on Software Quality Connection.