hen AT&T assessed the performance of their engineering teams, they discovered that their top-ranking software developers were as much as 10 times more productive than their colleagues. There are several reasons behind this astounding range in performance. Besides intelligence and aptitude, of course, basic work patterns make a huge difference. I’ve tried to distill these patterns down into seven basic techniques that you can apply daily.
Before I describe each individually, it’s worth remembering why you are reading this. You want to become a more efficient developer. To succeed, you need to strive for three key objectives:
- Produce applications that better meet the needs of users
- Introduce fewer defects
- Spend more time enjoying your job
And now…the seven techniques to help improve your day-to-day development efficiency.
1. Understand your users and their needs.
It’s unlikely that you pay yourself to develop software for your own use, so the ultimate purpose of your efforts is to serve others. As developers, we seem to have difficulty projecting ourselves in the role of our users. Yet it is important for us to do so.
The first stage in any project ought to be to understand and document your end users’ requirements. Although you may already do this routinely, especially if you’re part of a larger team, there are always ways to study your documentation results further or to get to know your users better.
Being in tune with your users’ needs should help you determine what to build and, perhaps more importantly, what not to build. Whether you call these needs “requirements” or “specifications,” they should be the guiding light for all development.
2. Understand your whole code base.
Few projects have the luxury of starting from scratch. Chances are, you’re usually scouting about for scads of existing code. That means spending too much time chasing back and forth between code modules. You can reduce the need for such code hopping by familiarizing yourself with both the logical and file-oriented structure of the code tree. Get one of the old hands on the team to give you a guided tour of the code and explain how it is structured. That’ll help you find material faster later?especially since you’ll have picked up some of the anecdotal history of the development work along the way.
3. Work well with others.
Most likely, you often work with other people on the same project. To achieve high productivity levels, it is important to develop team pride and communal ownership of your work. Try to build a sense of community, so that the entire code base belongs to the whole team; no area is private property. This cuts down on rework and duplication.
Group pride and peer pressure work to ensure consistently high quality. I mean, no one wants to be targeted as the joker who checked low-quality change into the master source tree, right? Group pride can also mean better adherence to coding standards because everyone has bought into them.
Don’t get me wrong. Uniformity of coding is good, but uniformity of thought is not. Perhaps the most difficult aspect of being a true team is that you must welcome bad news as well as good. If a team member thinks something is wrong and points it out, the rest of the team must listen. Pointing out problems is all too often dubbed as being a “poor team player,” when exactly the opposite is true.
4. Know whom to ask.Knowing the answer to every question is ideal. The next best thing is knowing who has the answer. Develop the self-assurance to admit not knowing something?a useful skill to acquire. Don’t struggle for hours in front of your screen, scratching your head; ask someone else. Whether you send e-mail, post a request on a bulletin board, search the Web, phone someone, or just shout across the room, it will save you time.
While this might sound obvious?even trivial?research at AT&T found this to be one of the most significant performance differentiators. The recognized high-flyers cultivated a network of peers they knew they could consult if needed. Everyone else battled on without seeking help, reducing their productivity.
5. Inspect your code.
The best way to avoid finding and fixing bugs is not to put them there in the first place. Sounds smart, right? Code inspection is one of the best ways to achieve it. You can inspect your own work, but your buddy can inspect it better?and for really thorny problems you can gather a small group to work through your changes.
I’m a great fan of buddy checks. They’re cheap, efficient, and generally a lot of fun. Basically, you show and explain your code changes to your coding buddy before you check them in. Chances are, you’ll spot any mistakes as you explain what you’ve done. If not, you’ve got a second pair of eyes on the case.
6. Test and fix as you go.
It’s no fun testing all your code in one big batch at the end of the game. Nor is it very effective at finding problems. Because of this, many projects test their code continuously?usually every time the code is built or at least once a day. Tests can even be written before the code, a practice recommended by adherents of Extreme Programming techniques. But even if you don’t manage to test ahead of time, you can still write tests for each chunk of code once it is more or less complete. A completed check-in should consist of both code and the corresponding tests.
The other part of this process is fixing the bugs you discover. That should go without saying, but what happens if you spot a problem in an area of code that you aren’t actively testing? Or what if you spot a problem while trawling through some code looking for something else? Truly efficient engineers fix the problem there and then, or at least report it to someone else for fixing if they are too deep in their own work. The plodders who just leave it there for someone else to find lose the company time and money in the process.
7. Know your tools.
The classic project management book, The Mythical Man-Month: Essays on Software Engineering by Frederick P. Brooks, Jr. (Addison-Wesley, 1995), talks about the need for a language lawyer on each team. This is the person who knows the implementation tools inside out?the person who understands what “double inheritance in C++” actually is, or the precise semantics of a “Java-frozen declaration.”
Development tools have evolved since that book was written originally in 1975, so the scope of the language lawyer has widened to cover many aspects of not just languages, but also APIs, tools, libraries, protocols, and all the other paraphernalia of modern software. How often have you worked for hours crafting a truly cool routine, only to find the following day that the standard runtime offers something not just equivalent, but better? Or how about that neat little function under the Tools menu that is just perfect for that repetitive editing job?
Taking the time to learn about your development environment means discovering these things and saving yourself time later. You can do this in many ways, from exploring the dark and dusty menus you don’t normally use in your IDE to buying some of the myriad books on each development tool. Even if you find just one tip in a book, it’s worth the purchase. Don’t forget the Web, either; it’s full of information, hints, and tips.
Which takes me nicely back to Item 4: knowing whom to ask.
These seven techniques are interlinked. Once you get used to using them, you’ll find they work well together, forming a framework for efficient development. Some things will work better for you than others, but we can always improve how we work, can’t we?
