App Retirement Party

Today marks the beginning of retirement for one of my apps--this one, in fact. As its Viking funeral ends in it sinks beneath the surface of the inky black waters of oblivion, I take a few minutes to ponder its useful life and its lessons.

Given its original mission, it was an astounding success: it allowed Outreach to dramatically grow its volume while greatly lowering the processing burden on the hospital lab.

Its secondary goal of paving the way for software in the draw station was also achieved, since rolling out its replacement was a fraction of the pain of introducing software to them in the first place.

Its tertiary goal of providing hard numbers with which to manage the collection operation seemed to be a glorious success, but since the organization did not bother to replace this functionality when they retired this app, perhaps this was as obviously valuable as I thought?

As an exercise in customization to support operating procedures, it also seemed to be a great success, but many of the most popular and most effective customizations are not being re-implemented, so their value was lower than it seems to me or their cost in the new environment is too high. The whole "this is better, because it cost more" movement baffles me and perhaps this is part of that.

The customizations which people most complain about losing are these:

• the ability to automatically cancel ordered tests, with an explanation, of those tests are not going to be done anyway per Lab policy
  
• the ability to automatically change  an order for an obsolete test with an order for its replacement, with documentation, if an equivalent replacement has been defined
  
• the ability to handle clinical trials and research draws, to ensure anonymity and proper billing

Rest in peace, app: you did all that we asked and more.

Godspeed, former users: may your manual work-arounds be as painless as possible and your upgrades lead you, eventually, to the level of efficiency you once enjoyed.

Still No Silver Bullet

I recently got re-acquainted with Ruby-on-Rails and this made me think of software building tools in general, which reminded me that I like to rant about how badly we creators of software classify, describe and choose our tools when confronted by a new task. This is that rant.

We do a horrible job of assessing our options before we start, explaining our choices to our colleagues (and bosses and clients), reacting to feedback as the project progresses.

Once upon a time, shortly after I got out of college, someone wrote an  excellent paper on a timely topic: software programmer productivity. The time was 1986, the author was Fred Brooks and the paper was "No Silver Bullet — Essence and Accidents of Software Engineering".

(For the Cliff Notes version, turn to Wikipedia: http://en.wikipedia.org/wiki/No_Silver_Bullet. The paper is worth a read on its own, but who has time?)

The summary in the Wikipedia page is very good, and I will be stealing from it liberally in sum future rant about how badly managers tend to manage programmers and how badly programmers support their management. But you should read it now before the rant really gets going.

This is my banal insight: so little of the fundementals of creating software has changed in the intervening decades since 1986 that sometimes I want to cry. So much has changed about the incidentals that sometimes I want to cry. After 30+ years in the business, I was hoping for more improvement, not more novelty.

And boy, do we have novelty. We love novelty. We worship novelty. Take web UIs as an easy example: we have so many ways to make web pages, my head spins.

• Want HTML with embedded code? Try PHP!
• Want code with embedded HTML? Use Perl/CGI!
• Want an abstract environment which separates HTML and code nearly completely? Ruby-on-Rails is for you.
• How about an end-to-end integrated code & HTML environment? Microsoft Visual Studio is just the thing.
• Want to try to side-step HTML and have some portability? Java, in theory, can do that.
• Want to develop HTML with code woven into it? Why, Javascript was created just for this purpose.

I do not have a problem with more than one way to do something, especially if the ways have pros and cons. I am not an operating system bigot: I used VM/CMS for large batch jobs. I used VMS for file-oriented processing. I used Unix for distributed systems. I used MS-DOS for desktop apps. I used OS/2 and then Windows for snappier desktop apps. Each had its pros and cons and its appropriate uses.

The same was true for computer languages: I have used BASIC for matrix math, I have used C for file I/O, I have used Lisp for list processing, I have used PL/1 because IBM required that I use it.

Then somehow this idea of appropriateness faded away from computing: desktop=Windows, server=Unix. Then server=Windows Server for some, Unix for others. C++ or VB as the one-and-only programming language. Then other contenders for the one-and-only programming language.

We all understand that hammers are good for driving nails and screw drivers are good for driving screws. It is clear that screws are better connectors in some situations and nails in others. Who would hire a carpenter who only used one or the other?

But we hire "Drupal Shops" and "C/Windows Shops." We hire "Unix guys" or "Windows guys." We pretend that there is a single best tool for all jobs--and then argue pointlessly about which tool that might be.

Consider this statement from the creator of the Ruby programming language: (full text here: http://en.wikipedia.org/wiki/Ruby_%28programming_language%29)

Matsumoto has said that Ruby is designed for programmer productivity and fun, following the principles of good user interface design.^[33] At a Google Tech Talk in 2008 Matsumoto further stated, "I hope to see Ruby help every programmer in the world to be productive, and to enjoy programming, and to be happy. That is the primary purpose of Ruby language."^[34] He stresses that systems design needs to emphasize human, rather than computer, needs:^[35]

A single tool to help every programmer in the world to be productive and happy? To me, that seems insane and it seems to reveal a worldview which I cannot support: the idea that there is a single best tool for all people for all problems in all environments. What hogwash.

I applaud the goal of creating good tools and making programmers in general more productive but I reject the notion that this job can every be done with a single stroke.