Simpler Software Deployment
One of the more interesting differences in programming other than poetry of code is the management of the code and the software produced by that code. There are various theories on the deployment of software, but the one gaining the most steam recently has obviously been “less is more, simpler is better, smaller is better” careof companies like 37signals.
Most recently, I was on line (a physical line, not “online”) at my local post office. The lines are not uncommon at the post office for a variety of reasons, but today was special as a PO employee was informing customers that new software had been loaded into each terminal and that it was taking the clerks longer to complete the usual tasks as they were learning the new system.
This was interesting for a host of reasons. First and foremost, it was obviously a big upgrade. All of the clerks were closer to their screens, staring wide-eyed looking for the recognition of familiar buttons and functions. You could see their eyes scanning. In addition, each clerk had a printed spiral manual with icons and large quantities of text. It was easy to see the manual was useless given that not one clerk was looking at it - and who would want a clerk to pull up the manual and start reading the chapter in front of a customer?
It’s a small example of how big upgrades can have undesirable or unforeseen results and thus, in addition, to dealing with the usual details of a product launch, the larger the deployment means more things to worry about the users understanding. I remember the quote:
Build a better idiot-proof system, and someone will build a better idiot.
There’s a lot to read on this topic. Signal v. Noise certainly is a start. Search the archives, you won’t regret it. I’ve extended this philosophy to FileMaker with a number of techniques, all of which I’ll be posting up here in the coming days.
