As a custom application developer working mostly with small businesses, users often look at “Why can’t the program do this?”, or “How about having the program add this, subtract this – when it’s this, then add a percentage…” yada, yada, yada. Perhaps you recognize the pattern. There can be arguments for doing much in the way of accommodating the requests, but in my opinion there can become a time when an application is too automated.
This tended to happen I believe in the early years of programming applications. The programmer provided 100% of the step-by-step sequence presented to the user – users couldn’t skip anything – they were tightly controlled. Today the user can go anywhere, and the program must accommodate such “jumping around”. Anyway, I have been working with some early 80’s era program source code – a custom application developed strictly to do the task required – without consideration of the requirement for minor “variations” in the performance of a task.
The more closely I look at the code the more areas I find that were obviously added into the processing as these “variations” in requirements arose. These variations might be triggered by different customer requirements – and they were “hard-coded” into the program – IF this cust, do this, ELSE do that. Further, these exceptions then became nested – IF this custid, do that, ELSE IF this custid, do the other thing. You get the picture (at least if you’ve ever worked with non object-oriented code).
Coming back to the idea of applications being “too” automated – I believe that many times in the development of an application not enough consideration is given to the nature of “exceptions” to the business process the application must handle. I would consider any application with specific processing coded into the app for a specific customer to be heading into the “too automated” category. Yet, building a process which allows for multiple “variations” into the application – in a horizontal manner rather than vertical is certainly appropriate.