A Process With the Right Degrees of Freedom - the Lagom Process?

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.

Comments

[Gabriel Gonzalez]

So here you propose that the process should be organize as a set of changes which would imply a visible progress in the life of the application or at least help trigger the next change. The process could then be modelled as an ASM and maybe take advantage of it.

That makes any sense?

[Raju]

I think, one of the beigest aspects that can control software complexity is “dependencies” between various “parts” in the software application.

It is extremely important that each “part” must have least possible dependency, so that, it requires least effort to remove it. So that it can be refined in full isolation and reintegrate it back in the application. Also, the dependencies must be readily identifiable. For example, if a “part” has dependency of just five-lines of code, what is the use, if it takes forever to locate the five-lines?

Mr. Christerson, I agree with most of your post. But, I think “dependencies” is yet another dimension, which must be addressed. Unfortunately, I have yet to find a consorted research effort that addresses this most important aspect.

This is continuation of my earlier post:
http://blog.intentionalsoftware.com/intentional_software/2006/04/we_are_hiring.html#comment-24216619

What do you think?

[Raju]

Mr. Christerson, It is possible to “Minimize Dependencies” (or Coupling) for each part in the software applications, which is nearly impossible in any engineering product:

http://www.cbsdf.com/service-access/3D-Board.htm

Many of us, software professionals, are jealous of other engineering disciplines and their plug-n-play parts. It is time for us to try to change that. What do you think about our process?

Regards,
Raju

[Casey Wimsatt]

I'd like to propose an extension, generalization and addition. First, I think a) the intent behind the final product as well as b) the forward progress are not all that should be captured. Invention is not always purely forward, and it is important to record the side avenues that were explored and why they were abandoned.

Second, I believe that the principles of "progress" and "harmfulness" can be generalized to a "symbiotic" principle. In particular, the measure of "progress" should be that it adds more than it takes, benefits more that it harms.

Finally, I'd like to propose a "bionic" principle. When the ratio of benefit to harm is highest, the benefits will be delivered invisibly/seamlessly, without any perceivable burden/distraction to the beneficiary.

Cheers,

Casey Wimsatt
http://www.symbionica.com