On perceptions and paradigms as constraints
Good literature has this habit of turning assumptions on its head, explaining the limitations of perceptions and the ways in which we, as humans, maintain artificial sets of constraints even though we might be trying to fight those same obstacles. Pretty much the way Arendt was criticized, we lose our product vision, because precisely the way we have to fight the forces that push seemingly innocuous agendas on our plate. We have to regroup, reassess and act again.
These assumptions that so easily maintain the status quo, or impede the realization of our initial vision, also affect us, derailing our intentions and helping us, and others, into rationalizing the very same obstacles into being necessary.
For example, a process that has been unreliable, or a continuous rechecking and retesting, or a routine series of tasks that take resources yet are performed because that is the way that it has been done before, or because they are necessary to maintain data integrity on legacy systems, all seem to be valid uses of the time of developers and managers. The problem starts with reason for those routine tests and tasks in the first place: is the system getting into legacy mode? Are the input processes correct and updated? Is there a way to fix all these issues that pop up under use, and while the system is stress tested by changing business demands and requirements?
There is no correct answer here: the business evolves and changes requirements, the installed system becomes legacy, and resources and allocation are scarce; the legacy IT system is already established, the implementation of another system is dependent on business timing, i.e. you wonâ€™t change Point of Sale just before Christmas season, and recovering the existing knowledge to incorporate it into a new application is serious enough â€“ old, legacy work is knowable, routine and easily measured, although prone to errors and mistakes.
And that is where the vision vanishes, replaced by routine task management and endless quality control tasks that are precisely what has launched the new system implementation in the first place.
But who manages that implementation, and how does that proceed?