Violation of Expectation
Nov 19th, 2011 by Alex
As I tweeted, change may violate design of a program, but changes to implementation that violate our expectations are worse.
In software development, the design becomes useless if the user elects not to use the application. You might have the most amazing and thorough design, but if it doesn’t attract and entice users to use the thing, what’s the point?
In configuration management, process can help cover all the documentation needs, but if it’s so much that a developer strays from the process entirely, what’s the point?
But these are often just academic exercises…
Suppose a meteor landed on your house. Assurance from your neighbor that everything will be alright — while correct in emotional terms — isn’t as good as their offer to pitch in and help clear the wreckage and salvage whatever precious goods may have survived.
But that’s just a hypothetical…
In employee relations, consistency is key when working with employees. People in general, really. If you tell someone that they matter, actions that suggest that they don’t will breed skepticism and distrust. An employee may be fine in the knowledge that they’re an entry in a profit/loss ledger so long as their financial needs are being met, but once expectations are raised and the employee feels valued, actions that make them feel undervalued are a violation of expectation.
In a labor-based economy, employee knowledge and expertise are considered precious goods, but more important is what the employee is going to be capable of in the future. When policies that affect employees change in ways that could be construed as inequitable, pleasantries won’t be enough of a consolation to mend that tear in trust.
That isn’t to say that design isn’t important, but design for the sake of design is foolish.
I would think, though, our greater problem of violating expectation stems from either a.) not setting them appropriately in the first place and b.) not engaging all stakeholders in the entire process from end-to-end. In other words, making individuals feel participatory by, in fact, participating, helps to build trust and dialog and allows for more organic processes.
Let’s take your configuration management “academic” exercise–I would argue that it is not an academic exercise given my day job, but I digress. Perhaps the issue of onerous process and documentation requirements would not be perceived and strayed from if we engaged developers to understand end-to-end processes. I have seen that the larger problem is the deliberate obscuring of whole processes in order to just focus on the part of the process required to do one’s job in fact creates a lack of situational awareness. In other words, we have deliberately created the problem of not seeing the forest from the trees.
This gets further complicated by creating different requirements for different classes of things, for lack of a better term. This requirement applies if this meets these n conditions, while this requirement does not apply if it meets these x conditions.
At my heart, I am an operations guy, and I see why process is needed. The reason why process is not adhered to stems not from how onerous or obstreperous it is but from how we have participated in the process or been engaged in it. To make this analagous to your design argument, I would ask if the user was engaged fully as part of the design process. If not, and someone emerged Oz-like from behind the curtain with software designed with you in mind, in all likelihood, the use of your application will be an abject failure, no matter how well-designed it is.