The simplest thing that could possibly work left me wanting more
One of the mantras of the Agile community is that you do “the simplest thing that could possibly work.” As I tried to follow this maxim when launching two personal projects (a batch job that sends tweets, and a web application for home use) I found myself wishing that I had done more. Such as:
Set up my router to allow remote ssh access.
This didn’t seem so important in development. But on the day that I realized while driving to work that I needed to manually run the batch job (due to an error I introduced in crontab), remote access seemed more important. And the day that I discovered a potential error as I was trying to leave town with my family for the weekend, I realized that remote access was completely essential, for any application in production.
Set up good logging:
For the batch job, it was obvious that logging was essential. But for the web app, I left it out. After all, when things didn’t work, I could always look at the console output. But as I considered advertising my modest web application to others that might find it useful, I realized that I would really like to know how frequently my application was being used, and by how many people.
Prepare to recover from errors:
During one of the first runs of my batch script an error occurred that left my application in an intermediate state. Fixing the error in the code and re-running the job wasn’t sufficient, since the database had changed. I needed to write an ad-hoc re-run script to finish the job correctly. Of course, since it is my production database that has this problem, I found myself testing that re-run script in production.
The common theme:
There are some other little things, but you get the point. So what went wrong? Is “Do The Simplest Thing That Could Possibly Work” bad advice? Or am I just really bad at determining what can work?
I think that it’s easy for developers to grab that mantra and do the simplest thing that could possibly work — in development. Some simple things that can work in development, simply can’t work in production. It’s an easy trap, because developers live in (where else?) development, where certain types of production issues never arise.
I still plan to do the simplest thing that could possibly work. First in development, and then in production … and both before initial deployment. And as I gain experience, I’m sure that my view of what “can work” will grow to the point where such mantras are in fact useful, and not merely a seductive trap.