Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Seven Techniques for Better, Faster Development  : Page 2

Improve your development productivity by adopting this expert advice.


advertisement
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?



Richard M. Marshall writes, presents, and consults on software development, methods, and project management. He holds a Ph.D. in Computer Science from the University of Edinburgh in Scotland.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date