Software Developer's Resource Guide

Good developers make it a habit to keep up with the vast developer resources on the Internet. Here are a few of my favorites.

• By Mike Gunderloy
• 10/01/2001

Alistair Cockburn has written a great deal about software development on his Humans and Technology site. His primary interest is in trying to determine what works and what doesn't work in large software projects. Much of his work has involved studying the methodologies used on actual projects, making this site a great place for "tales from the trenches." Cockburn also has a gift for summarizing results simply:

Software development is a craft, it is an engineering discipline, it is mathematical, it is a mysterious art. It is like getting a whole community to write poetry together. There are temperamental geniuses, hard requirements, communication needs, and, under it all, humans working together building something they don't quite understand. Done well, the result is breathtaking. Done poorly, and the result is assembly-line material.

Speaking of methodologies, Extreme Programming ("XP"—nothing at all to do with Windows XP or Office XP) is the hottest new methodology to come along in years I'll be looking at XP in this space next month. Meanwhile, you might try the Extreme Programming FAQ, An Introduction to Extreme Programming, XProgramming.com, or the Extreme Programming Wiki to get started with this methodology.

One of the techniques promoted by XP advocates is pair programming. In pair programming, two developers work together on writing code. It sounds like a surefire way to cut productivity in half, but in fact productivity stays high and people working together make fewer mistakes. If this sounds interesting, take a look at Pair Programming and Strengthening the Case for Pair Programming. The biggest problem with pair programming will probably lie in convincing your boss to let you try it.

Another influential idea in recent years has been that of software patterns. The notion is that there are structures that are repeated over and over again in software, and that by recognizing these patterns you can implement them more correctly and more quickly. A good place to start reading about patterns is the Patterns Home Page, which has links to many other pattern-related sites.

One of the simplest things you can do to make software development more productive in any organization is to settle on shared coding standards. Unfortunately if you try to do this you'll probably run across maverick coders who think they don't need any stinkin' standards. In Defense of Coding Standards is a short essay arguing for standards because they help make software work, and it might convince some of those holdouts (especially if you adapt the minimalist approach to standards suggested in the essay):

The third rule is to encourage a culture in which standards are followed, not because Standards Must Be Obeyed, but because everyone realises that things work better that way.

And if one informal essay wasn't enough for you, hop over to Tom Van Vleck's page on Software Engineering, which holds lots of wisdom from someone who's been in the field for a long, long time. A small sample:

We know about as much about software quality problems as they knew about the Black Plague in the 1600s. We've seen the victims' agonies and helped burn the corpses. We don't know what causes it; we don't really know if there is only one disease. We just suffer—and keep pouring our sewage into our water supply.

Another essayist well worth reading is Joel Spolsky. An escapee from Microsoft who's now running his own small software company, Joel's ruminations on the development process are always interesting. His series on user-interface design has turned into User Interface Design For Programmers, a book from APress. Check out Joel on Software to see what he's been thinking of lately.

When you're ready to move from informal to formal, you might tackle some of the old standbys in the software engineering field. These organizations go way back, and have made serious studies of the development process, usually in the mainframe world. You need to use some care in applying their conclusions to rapid development in the PC world. But these sites are still worth a visit:

• Center for Software Engineering at USC
• Software Engineering Institute at Carnegie-Mellon
• Software Engineering Laboratory at NASA
• Software Program Managers Network at the Department of Defense

When you start working on large projects, you'll find that you have to think about keeping track of code even more than you have to think about writing it. If your organization is just starting to use source code control and other code-management practices, take a look at the Perforce white paper High-Level Best Practices in Software Configuration Management.This will probably save you time and trouble as you try to produce code with more than on developer.

An interesting backwater of software engineering is literate programming. The idea of literate programming is to craft your source code for reading by human beings through proper use of comments and formatting. If that sounds interesting to you, you'll want to check out the Literate Programming—Propaganda and Tools page.

There are also sites out there that belong to consulting organizations that will help you improve your process. Some of these folks offer interesting newsletters and articles, though of course they also want to sell you their service, so you need to be a bit careful about taking their advice at times. Worth visiting in this category:

• Construx Software
• Process Builder
• Process Impact
• Trends in Software Engineering Process Management

Finally, sometimes you can learn more about writing good code by thinking about bad code than in any other way. Plus, you can have more fun thinking about bad code. Two sites to check out when you're in this mood are Big Ball of Mud and How to Write Unmaintainable Code. From the latter site:

Recycle Your Variables: Wherever scope rules permit, reuse existing unrelated variable names. Similarly, use the same temporary variable for two unrelated purposes (purporting to save stack slots). For a fiendish variant, morph the variable, for example, assign a value to a variable at the top of a very long method, and then somewhere in the middle, change the meaning of the variable in a subtle way, such as converting it from a 0-based coordinate to a 1-based coordinate. Be certain not to document this change in meaning.

Of course, the biggest truth about the Internet is that it is a big, big place that no one person can completely explore. So it's certain that I missed some very worthwhile sites in this short listing. Did I miss your favorite site? If so, drop me a line at [email protected] and tell me about it. I'll report back with reader suggestions in a future column.