User Manual Driven Development

One of the best jobs that I ever had was back in the mid-80's working for Scott Cutler at Tandy Electronics Research and Development.  I worked on the team that built the DeskMate II GUI shell and its associated applications.  This was back in the glory days when many vendors were still pushing their own graphical environments - Apple clearly in the lead - Windows not yet quite measuring up - Atari and Digital Research's GEM still viable contenders.

We wrote everything in C and 8086 assembler... Life before objects: Smalltalk was around but too much of a resource hog  for the Tandy 1000  (256K of RAM and a 5 1/4" floppy).  C++ was just a rumor as far as we were concerned... Structured programming was king.

Our development methodology was simple but effective... the marketing group wrote the deskmate user manual and we built the applications to match the manual.  To be more precise, the marketing group would write a proposed manual, we'd negotiate with them over what could and what couldn't be done, and then we'd build to the manual.

I guess you could call this User manual Driven Development, and I think that it still can be a very valid approach.  In most respects User Manual Driven Development is very close in spirit to Test Driven Development - The function of the software is clearly defined, so it's very clear if the software doesn't do what it is supposed to.

Some time between the 80's and now we mostly abandoned the idea of User Manuals.  Let's face it... few users ever bothered to read the manual (Leading to the ever present RTFM reply on many support forums).  Few companies even bother much with online help... Users are mostly encouraged to just play with the software and learn by doing.

I'm not advocating a return to User Manuals... but I do advocate tailoring our development methodologies to return the programmer's focus back to the users.  The prime objective is always to satisfy the needs of the users... The users really don't care about object hierarchies, they don't care about Java vs. Ruby.  They care about being able to do what they need to do.

I think most of you will agree that some of the best software that you can find is software that is primarily used by programmers.  Eclipse, NetBeans, Visual Studio...  This comes as no surprise:  Programmers understand the needs of other programmers.  Since I understand the purpose of the software, and I know how I would like it to work, then I am extremely qualified and motivated to develop the application.

It always stuns me when I encounter an engineering manager who believes that his staff doesn't need to know how to use the product that they are developing.  I've heard people say "Just give us the requirements an we'll build it".  I simply cannot agree with this philosophy... Requirements are never enough.  Ever.

To write great software, you have to put yourself in the shoes of the user and walk a few miles.  Perhaps it's a bit like method acting... Unless you "become" the user you're just going through the motions.