A Good Theory
Graham Oakes, 06/08/2010, posted in "Analysis"
Dr Graham Oakes is a highly skilled systems engineer and project manager with over 20 years’ industry-proven experience backed by a track record of delivering highly innovative and effective solutions. ...more info
Dr Graham Oakes is a highly skilled systems engineer and project manager with over 20 years’ industry-proven experience backed by a track record of delivering highly innovative and effective solutions. Graham helps people untangle complex technology, relationships, processes and governance. As an independent consultant, he helps organisations such as Sony Computer Entertainment, The Open University, the Council of Europe and the Port of Dover to define strategy, initiate projects and hence run those projects effectively. Prior to going independent, he held positions including Director of Technology at Sapient, and Head of Project Management for Psygnosis (a subsidiary of Sony). His book, Project Reviews, Assurance and Governance, was published by Gower in October, 2008. ...less info
“Theoretical” is a dirty word at my current client. If an idea can’t be translated into immediate action, they’re not interested.
Many organisations are like this. They like checklists of “best practices” that people can pick up and follow without too much thought. When developing systems, this mindset shows itself in the rush to coding – anything that isn’t expressed directly as code (requirements, architecture, design, etc) is seen as a preamble to the real work. People rush through it as quickly as possible. Or they abandon it completely.
This mindset also drives one of the big discussions in the Agile movement. What exactly constitutes “enough” design up front (EDUF)? When does investing effort to create a coordinating framework become over-investment in abstractions that will only need to be reworked as we learn more about the actual requirements and technical constraints? Up front, it’s almost impossible to know. But good architects are constantly asking the question: they can sense when to stop.
SOA tends to come from a different tradition. That community sees a lot of value in up-front analysis, both to identify the services which might deliver value and to create the infrastructure that allows us to realise value quickly. Abstract thinking, from this perspective, isn’t an overhead: it’s a necessary enabler for effective action.
I can see why the Agile movement (and my client) has reacted against this approach. I know several organisations that have indeed got bogged down in analysis paralysis, unable to commit to code until their models are “perfect”. Yet often you need to write some code in order to fully understand the problem – effective models can only come from action, rather than vice versa.
On the other hand, my client regularly runs into issues arising from their rush to act rather than invest time on “theory”. For example:
- Lots of stuff is reinvented across multiple teams. No-one is looking for and supporting the general capabilities that are useful everywhere, so everything has to be done (and redone) locally.
- When someone does try to reuse functionality that was developed by another team, they are surprised by the effort required. It takes work to adapt a component to a new context, especially when you have no clear picture of what constitutes core functionality versus local variants on that core.
- People act before they’ve considered the broader implications of their actions. This then leads to unintended consequences.
German psychologist Kurt Lewin said “There is nothing so practical as a good theory”. Theory and practice are not in opposition. They support each other – theory suggests useful action; action helps validate and refine theory. Organisations that reject theory are, ultimately, rejecting this learning feedback cycle.
Subscribe via RSS or via email
