We have discussed a few times earlier the need to use the right abstractions, or the right degrees of freedom, to solve a problem. The best solution is something that exactly fits the problem domain, being it the right size screwdriver, a software platform or a programming language. Often times our languages, tools and platforms have too many - or even worse too few - degrees of freedom and we have to put in extra work to compensate for the superfluous or missing degrees. To quote from our earlier posts:
So to generalize the “harmfulness” theory, we need to refer to the degrees of freedom in the problem statement, in the domain intention. A programming feature is harmful in proportion that it has more degrees of freedom than in the domain intention that it is used to solve. By degrees of freedom we mean the potential parametrizations (arguments, properties, attributes, or parameters) for the abstraction and the gamut of their values. This latter is determined by the parameter type: the range of possible parameter values can be small for enumerated types, or very large, for example the “parameter” is a statement list as in a loop. Harmfulness is related to excess degrees of freedoms: more parameters than necessary, or larger parameter types than necessary for the purposes of the problem intention.
We can expand this idea to also apply to the actual process being used. If a process adds more steps, tasks, deliverables – in summary more work – that is required, we think of the process as getting in the way and not helping. The process is causing extra work, it causes errors, and it adds complexity. In fact a lot of the processes that are popularized today is actually compensating for missing degrees of freedom in other areas. We need to work around the lack of power by copying information, reworking and repeating. For example, because we have no good way to transfer the domain intentions between the domain expert and programmer, the industry has come up with many ways to compensate for this problem in the process. Examples include modeling, customers on site, prototyping, iterative development, storyboarding, meetings, specs, use cases and user stories to name just a few.
What are the right degrees of freedom for an ideal process? It could be something that helps make the right tradeoff of change and progress. In other words, when a change is needed, we not only allow the change, but also implement the change in a way that ensures progress. Here we use “a change” fairly broadly. From the dictionary:
A transformation or transition from one state, condition, or phase to another
A change early in a project could be from an idea of a new product to something tangible, for example a prototype. A change later in a project could be to refine the functionality of a user interface. The tradeoff between change and progress is important because we need to organize the work so that every change also ensures progress. We wrote earlier about a process idea from Christopher Alexander that is now surfacing in a different field, namely architecture. Alexander suggests a new type of process he refers to as “making” where the customer, architect and builder are collaborating during the entire process and refines the degrees of freedom continuously to make something that exactly fit the customer’s needs.
Jimmy Nilsson has some similar ideas. He argues that Extreme Programming is sometimes perceived as too rigid or too extreme. Rather, he suggests a “Lagom Process”. (Lagom is a Swedish word that means something like “just right for this situation”. He describes the process as “It's probably influenced by Agile, but it's built up of the pieces that together form a mix that is lagom for the team and project at hand. That's it.”
On a similar topic, Jeremy and I met with Ivar Jacobson last week. Ivar described how he is now rethinking the whole Unified Process approach into something completely different. It is clear that over the last few years it has been a challenge to separate the domains, or concerns, of the Unified Process. Per Kroll, who is responsible for the Rational Unified Processes, and his team is also trying to address this. Reading the current process is like reading source code. We compared source code in a previous post to encryption – contributions from multiple separate domains are intermingled together in the description – and the result is very hard to read, understand and maintain. Ivar has some new ideas that separate the domains of the practices from each other. A practice is described using a set of process cards each including activities, competencies and artifacts. It is great to see that separation of domains is also finding its way into process thinking. And hopefully as we strive for radical simplification in the way we build and use software, our processes will also be radically simplified.
Recent Comments