As I’ve mentioned before, I’ve been reading Joel on Software. The book itself really isn’t aimed at my profession per se, but it does give some useful advice and insight on how to wrangle developers and management. The phrase “pushing on a string” is used more than once, and I think it’s a perfect analogy for how some things happen around here.
There are also some excellent suggestions on ways to improve your process that apply to things outside of software development:

• Write specs for projects

Not just for coding projects, for everything. This forces you to think about the steps required for doing the job, detailing every minute step along the way. Who knows how many “Damn, I never thought of THAT happening” late night/early morning panic sessions could be avoided just by writing down and running through paper writeups of the process.

• Use source control

We’ve been trying for years to get our developers to see the power of source control (even if it is just Visual SourceSafe). It’s a mish-mash of forcing “no making changes in production without scripts/code/etc being in sourcesafe” and general habit forming that is slowly dragging everyone over. Now if Visual Studio.NET would just integrate better with VSS, we’d all be happier.

• Tossing away the entire old codebase isn’t the solution

Okay, I’ll admit it, this one is pretty much programmers only. But, there are some applications to real life here. Would you junk your 5 year old car just because it needs new tires or a new water pump? Depends on the car, I know, but in general, small maintenance is better than large, delayed outlays giving your competition time to run over you. Rewrite large chunks of code if you feel the need, but don’t toss all the code out just because you wrote a bad sort function 5 years ago. I’m just as guilty of this as everybody else.

• Neutralize the bozos

If you’ve got dead weight on your team (and you can’t get rid of them), give them some small, easily accomplished sub-project to work on that might take them months. Best case? They actually finish it, it works and you can integrate it into the big picture. Worst case? They are hopelessly lost for several months and you end up handing that task off to someone more talented to do in a few days. Win/Win in my book…

• The customer never knows what they really want

Taking a page from Office Space, you should just accept the fact that the customer only knows how the interface should look, not how the code under the hood should actually work. We’ve got at least one ongoing project where this is painfully true. The interface is implemented in what I like to call “so, this button goes here” and the business logic was decided, and is constantly re-decided, by strings of emails between non-technical Important People, non-technical managers and technical programmers.

• The Zone

I know lots of people have told you this before, but Joel brings it out in a way that makes you able to show your manager that being “in the zone” is a good thing and supplying all the things needed to get you there is good.

• Examples, Examples, Examples

This isn’t really something that’s in the book, but it’s how I translated the spec writing suggestion into my job: Anytime you suggest a change, give as detailed as an example as possible. If you can’t go back and read an email 2 days later and understand exactly what you meant because you were so far “in the zone” on that problem at the time, saving your old mail as a reference isn’t going to help much…

There are some things I’d like to start doing at work from this book, but who knows if I’ll actually have the time or the energy. The most visible one would be to put together a “What did Housing Network Engineering do this summer?” entry for the intranet.

Some back of an envelope items for that list:

• Student Computer Sites
  • Installed 110 new workstations
  • Installed 4 new color laser printers
  • Reinstalled the operating systems on all 380 workstations
  • Deployed Windows Server Update Services
  • Updated the virus scanner to McAfee VirusScan 8.0i
  • Replaced a proprietary conferencing server with open source solutions (yes, you old RSC people, FirstClass is no more)