Luke Hohmann talks with Bill Venners about entropy reduction, the cost of change, and programming as choreography.

Read this Artima.com interview with Luke Hohmann, the author of Beyond Software Architecture:

http://www.artima.com/intv/entropy.html

What do you think of Luke's comments?

The "bumpy cost of change curve" that Luke Hohmann sketches doesn't look right to me. It also doesn't quite match his descriptions, IMHO.

The scatched curve keeps rising higher and higher with every bump. I think that Bumps do appear, but the curve flattens again after I did the change. So the bumps don't keep rising, but they fall of again.

The curve would look more like this:
(the ASCII-art turns out more )

cost of
change
 ^
 |                        /---\
 |                    /--/     \--\            /---\
 |                   /             \      /---/     \
 |         ---------/               \----/           \---
 |     ---/
 |  --/
 | /
 |/
 +-------------------------------------------------------> t
        |       |       |       |       |
      rel1    rel2    rel3    rel4    rel5    ...

Greetings,
Malte Finsterwalder

> The scatched curve keeps rising higher and higher with
> every bump. I think that Bumps do appear, but the curve
> flattens again after I did the change. So the bumps don't
> keep rising, but they fall of again.
>
The difference is probably due to differences in interpretive detail than in substance. I think the idea is that once a cost is incurred it stays incurred and can't be 'unincurred', thus the graph always rises since the y axis measures the cumulative cost of change.

You're interpretation appears to be that changes later in the system can cost less than changes earlier in the system (because the improvement made by the earlier change makes later changes easier). In this case the y axis is measuring the individual cost of each change.

The catch with the latter model is that the later change may be cheaper because the earlier change made the system better able to accept the change. So it can be misleading to consider the cost of each change in isolation.

Vince.

Yes, I indeed interpret the curve as the current cost of a change, not the accumulated cost of change.
And I would also argue that interpreting it as accumulated cost of change doesn't make sense.

Interpreting it as accumulated cost of change would mean, that making changes later is actually cheaper, since the additional cost of change is almost nothing. This obviously doesn't make sense.

Malte

Entropy Reduction
There's 30 years of measurement and research on anti regressive activity in software development.

"Anti regressive activity is defined as activity that appears to have no immediate market value, no direct value to the user or, more generally, to the system stakeholders. What it does is to ensure that, as the name suggests, the system will continue to have value in the future."

FEAST/2 Final Report
http://www.doc.ic.ac.uk/~mml/feast2/papers/pdf/683.pdf


and many more publications: http://www.doc.ic.ac.uk/~mml/feast2/papers.html

Mr. Hohmann's books are great. I may not always agree with him, but there is a lot of valuable information in them, and he makes me think. For example...

RE: Choreography versus Architecture

My wife is a choreographer; I've worked with her, and watched her work with others, for over 18 years now. And while I think the idea of Alexandrian patterns are often misapplied, that doesn't invalidate them. He's talking about "patterns" in design, not structural implementation details.

Choreography is not just "dancing free-form on a bare stage". Good choreography is as carefully orchestrated as a complex piece of music and has to fit within bounds and constraints (style, scenery, costumes, ability). Of course there is Jazz in music, and there is improvisation in some dance; the architectural equivalent being, maybe, a camp-site. :)

What I do see as a distinction is that dance is perhaps a better metaphor for "loosely coupled" design. But there is flexibility in all this, just as you can have a post-and-beam house (where interior walls are not structural and may be move, or removed) you can have a precision military drill (where a wrong turn by one person can cause disaster).

Adding Choreography to our arsenal of design metaphors is a good idea, but it will be misapplied by some people just as Alexandrian patterns are. Ultimately, it's all about communication.

Like so many of the articles in this series, Entropy Reduction is about the things that need to be done Organizationally that the manager (or the PHB) may not not know about. Certainly there was nothing about this in school when he or she got that MBA.

All disciplines have specific things that need to be done that are simply unknown to newly-minted general managers (or good old boys on the board of directors), of course. Ditch diggers need to actually sharpen their shovels with grinders or rasps. Physicians sometimes need extra time to consult or just listen to the patient. And so on.

Software development has weird organizational needs that should be in the domain of advanced technical leadership, but that leadership is often lacking, and what we are left with is managers who are mere customers, who only understand what they can see today on the screen or printout.

There is are real arguments, you see, for not "Fooling around" with working software by "Refactoring" it or "Reducing Entropy". You don't know what bugs you have introduced unless you have tested it thoroughly and and probably beta-tested it with live customers. And live customers will refuse to beta-test unless there are new features. So you end up debugging your newly-introduced "Fixup" bugs along with the new features of the next release.

And system testing the new software might entail a small army of testers who have other things they ought to be doing. Some system tests involve setting up networks of computers and having masses of data pumped through the network. And any change at all to software build could conceivably change the tests, even though you are just "Refactoring". Because when you are refactoring, you will come across terribly illogical things in configuration files or in temporary files or in progam inputs and outputs that just cry out to be changed. Especially if you are "Reducing entropy" and not just formally refactoring. But the test team has set up special configuration files and inputs and outputs that no longer will be relevant after the "Harmless changes" you make.

So you had better be sure that the next release will really truly benefit from the "Fooling around" you are doing "Off budget" and between releases. Because you will be blamed for any bugs that show up.

And of course when the bug reports start flowing in, you will be pulled off of refactoring to fix bugs. So you do both and account for it as bug fixing!

Not that reducing entropy is wrong, and certainly refactoring is not wrong. But these things have costs that need to be considered and managed in the light of the overall budget and whatnot. And if your budget-level management simply cannot imagine what the hell Refactoring or Entropy Reduction is, because they are not now and never have been software developers, decisions will be made without rationality. Unless of course the software developers actually know how to communicate with human beings, which is, shall we say, not guaranteed.

One result of all this is that management complains that managing programmers is like herding cats. The Human Oriented Architecture has to include the suits, too. Now with lots of software development being done offshore in India, does Conways law change it's impact? And is managing underpaid Indians like herding cats? Will they refactor more or less?

Or will my whole thesis be blown out of the water because, in an era of a glut of software engineers, all the IT managers will also be experienced developers all over the world, and not just at Microsoft and IBM and parts of the Aerospace industry?

"Entropy Reduction" is a misnomer and an inane buzzword(s).

Entropy in the informatic sense is well defined by Claude E. Shannon in his famous 1948 paper `A Mathematical Theory of Communication.' A proper literature review would have revealed this, full stop.

It is disappointing when management consultants such as Mr. Hohmann's use well defined terms and mangle them for fuzzy spin.