Saturday, March 15, 2014

There are several traits of this DevOps inclination that are compelling to me. One is the kind of intellectual promiscuity involved; that is, to combine perspectives of perceivably dissimilar roles in an indiscriminate way. Doing so would enhance the architectural acumen for design decisions by widening the span of attention to even more relevant matters involved is software execution.

There are a number of cultural obstacles to tackle in order to get such acumen in a software provider organization; for example, the obstacles to freely share the hard-won personal technical expertise on the sole premise that doing so is good for the project as a whole, not just good for political exchange of favors among individuals.

Another grievous obstacle is philosophic and scientific illiteracy in the midst of project leaders and team members. Such illiteracy worsen the chasm between the way words are used to map reality in the architectural drawing board, on one hand, and the daily operations room, on the other. A better awareness, for example, of how language can be used in an operational way to build meaning would help decrease the blaming noise and gibberish like ‘our system is down’ or ‘the system does not allow me to give you service’.

Language can be a tool for a clearer thinking, not just a noisy instrument for obscure utterances. A proper use of technical language is important to enhance quality by means of building meaning with sets of operations. That is, of course, there are multiple legitimate ways to use language, but teams using technical language could benefit a lot from the philosophical and historical reflection of the use of language in the sciences. More on that here: Operationalism