I am not a big fan of boring, mind numbing, repetitive tasks. I remember my early days working with word processors and spreadsheets. If you needed to do a task more than about 10 times, it usually made sense to write a little macro to do the task so you could then invoke it over and over again.
I am a VERY lazy person. I have no interest in spending days of my life writing similar code over and over and over again. For my entire consulting career (almost 20 years now), I have always thought that it was better to spend a little time improving the efficiency of the process each and every time I do anything.
One of the big surprises has been that the time spent improving the processes used on a project has also paid off within the project for which it was developed and not just for future projects. The point is that doing it “right” has always been cheaper and more efficient than just doing what you have to do to get something done.
Recently, we have been working on a project for the US Air Force that would allow applicants to fill out their own applications (a task traditionally left recruiters). There are about 3000 pieces of information that must be collected from each applicant. The application had to be very user-friendly and “cool looking”, could not require any training or support, and was required to guide the applicant though the entire process.
Once we came up with a design, we found that each of the 3000 pieces of data required about a page of code to build. Each data field included help text, error text, several images, some complex behavior and had to be bound to the database.
Writing 3000 pages of code seemed like a really bad idea. So, instead we created a repository to hold all of the metadata for each data item. Then, we wrote a code generator (a program that writes programs) to build the 3000 pages of code.
Using this approach, not only were we able to stay within a unreasonably small budget, we were able to get the application written in a few weeks rather than many months. We can generate the system, decide taht we don’t like some aspect of the user experience, tweak the generator, and run it again.
Best of all, we now have a new, really fast way of building very attractive data entry-intensive web based applications.
Being lazy is sometimes a very good thing.