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.
Part of being a good developer is keeping up
with the field. There are a lot of resources out
there on the Internet that will help you do just
that. This month I want to point you at a few
of my favorite places to visit for thoughtful
writing about software development.
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:
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:
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.
About the Author
Mike Gunderloy, MCSE, MCSD, MCDBA, is a former MCP columnist and the author of numerous development books.