I spend a portion of my time trying (read "failing") to keep up with the software applications available out there in the application domains that interest me. Bouts of applications research can be very intense. Sometimes it feels as if taking a break to have a cup of coffee will result in having to play catch-up when you get back to your desk. Our information tools bring information to us so fast these days, it is like drinking from the fire hose 24x7. (If you want to experience this research firehouse for yourself, try doing some research on, say, "content management systems" and see how long it is before you feel as if you have surveyed the territory.)



As a sanity preservation device, I have devised a little litmus test that I use when evaluating software applications. Applications that pass this litmus test merit another round of investigation. Applications that do not get zapped from my radar. It's not a perfect system I'm sure of that. Doubtless it has caused me to overlook interesting applications in the past but the benefits in terms of personal sanity are worth it.



Bear with me while I just blurt it out. Then I'll explain where I'm coming from with it:



Does the application make the simple things simple but the hard things impossible? If so, bin it. Is the opposite true? i.e. that simple things are not simple but hard things are possible? If so, bin it. Does the application have a useful middle ground between these two extremes? If not, bin it.



Let's break this down into sections. There is an entire family of applications that are designed to do a single thing well. They achieve ease-of-use by the profoundly practical approach of not trying to be all things to all people. Either the application does what you want it to do out-of-the-box or it doesn't. Period. From a software development perspective, the best way to build such an application is to "wire it". In other words, no attempts are made to generalize the solution or to parameterize it in any way. Doing so invariably complicates the application and makes the user interface less intuitive. This is the class of application in which the simple things are simple and the hard things impossible. When they work, they work great. If you need to tweak them in any way ... you enter a world of pain.



There is another entire family of applications that are designed to do a range of things well. They achieve this flexibility by the time honored technique of building in layers of configuration/parameterization/scripting. If the application does not do what you want out of the box you can - in theory - make it do what you want using the configuration/parameterization/scripting options provided. This is the class of application in which the simple things are rarely simple but, if you take the time to understand all the configuration/parameterization/scripting capabilities, the hard things just might be possible.



Both extremes are problematic. Applications that make simple things simple have a way of running out of steam after an initial period of irrational exuberance has passed. Applications that make hard things possible at the cost of making simple things also hard, are a tough sell and regularly never get past the evaluation phase because they are perceived as unnecessarily hard to use.



For these reasons, my favorite sort of application is one that finds some reasonable middle ground between these two extremes. These are the ones I tend to focus in on when doing applications research. I like applications that have sufficient "instant gratification" to allow me to explain them to non-technical folk yet have sufficient headroom to allow me to re-work them under the hood when the out-of-the-box functionality is found wanting.



A word of warning though. Although this sounds reasonable there are a zillion-and-one ways extant in the industry to try to find this middle ground. APIs, scripting layers, meta-languages for business rules, intentional programming, data flows yada yada.

The real challenge - not one I have made any great progress on to date - is to identify a workable litmus test for these.

ITworld.com

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine