Ceterum censeo, Carthago delenda est

I changed a password to “ironic”, and now I keep forgetting it.

It makes me smile every time.

Proposal: The effort required to make simple changes to a software system is a performance test for a software development processes.

Hypothesis: When a technically simple piece of work becomes become prohibitively expensive due to software process, the software development process is objectively wrong.

Example: Project Overhead
Obtain an estimate for a trivial application that could be completed in less than an hour (e.g. record how many times a button is pressed). The estimate should cover all standard stages (e.g. architecture approval, estimation, management review, deployment, etc). The final cost will be the overhead, a cost incurred by every project, regardless of the project itself. What does it cost the IT team to do anything?

Example: Change Requests
Raise and estimate a change request to do something-simple-and-straightforward that achieves some-small-but-worthwhile-result. The change request evaluation should include all standard processes, such as review committees, documentation updates, impact analysis or process revisions. The process costs are effectively a fixed-rate change tax. A high tax cost can readily kill business cases for minor enhancements.

Theory: The software development environment has become resistant to change. With high overheads, only major projects can be approved. Small change requests are still desired, and stakeholders save them up and attach riders to whatever major project does finally get through. Already large changes will get larger. The difficulties inherent in large projects create further problems. A vicious cycle is started leading to further resistance to changes.

For the apt pupil: Will this test cross all processes and contexts? That is, are there contexts where it is right to have processes that make simple changes costly? This means not simply necessary, but right. A credible practioner must be able to stand up and say “I am proud of the costs in our process, and I will repeat them in the same context.”

Toyota (and Japan generally) has a practice called nemawashi. Broadly, this means that before asking for a decision to be made, each stakeholder is consulted beforehand. The stakeholders give feedback, which leads to corrections. The proposal evolves, acquiring depth. The final decision goes through easily, because everyone is informed, concerns have been answered, and everyone already agrees. (Also, when a request won’t get approved, it doesn’t get put up in the first place.)

Of course, this sort of pre-approval isn’t uniquely Japanese by any means. It’s simply a matter of preliminary briefings, or pre-meetings, or laying groundwork. Savvy operators anywhere will confirm or consult before important decisions. What is new (for me at least) is turning this into a formal process. Items for decisions aren’t allowed on agendas until nemawashi is complete.

Now this sort of ground work is all well and good, but it does mean that getting a decision made takes an awfully long time. Sometimes it feels like proposals go in circles for months, while new stakeholders are informed, brought up to speed, raise the same objections and concerns, and are consoled in the same ways.⁽¹⁾ Especially in software development, where just about everything is a decision involving many parties. Everyone has to be heard.

Which, to make a random comparison, feels a lot like democracy. There are endless discussions to have, interest groups to be heard, trade-offs to be made, and agendas to be uncovered. It feels slow and inefficient and draining. Too much talking, and not enough doing.

Extend the comparison, and we note that there is a common meme that rejects the endless talking of democracy as weak, and wishes instead for a benevolent dictator. Such a strong man would make decisions quickly and fairly, stop the endless talk, and make the trains run on time… that sort of thing.

And in fact, the Agile model for the customer does have some characteristics of a benevolent dictator. From more-or-less the first search result I find, The Poppendieck’s give 7 principles of lean thinking (pdf):

1. Eliminate waste – only add value, not inventory.
2. Amplify learning – iterate.
3. Decide as late as possible – defer commitment.
4. Deliver as fast as possible – Pull value and eliminate delay.
5. Empower the team – train, trust, and lead.
6. Build integrity in – both customer perceived and conceptual.
7. See the whole – avoid sub-optimizing.

In most of these principles there is a dislike of early compromise and decision making. Acting on these principles in typical Agile time frames (i.e. a few weeks) needs a customer with freedom to act, which typically comes from authority.⁽²⁾ Mid level minions are bound by previous commitments and deliverables. They cannot authorize changes for fear of breaking promises.

The stories that developers tell amongst themselves about customer “oddities” have as a root cause the need to negotiate with other parties, in arenas the technical team doesn’t see. (For example, a customer rejects corrections to provably wrong formulae because the signoff process was so hard to achieve.) The final decisions look arbitrary, because the compromises causing them take place on a different stage.

It’s far easier for the technical team to have a well-informed project champion who can say “Let it be so!” The development team can take these decrees, and set about building valuable software, without being delayed by the difficulties of building consensus. A cynical side note: the dictator is excluded from technical issues. They can’t mandate estimates. They shouldn’t mandate designs (at least, not beyond well justified non-function requirements). Agile roots are from technical teams, and the Agile social contract puts limits on the dictator.

Of course, the benevolent part is very important. The dictator must fairly balance all needs, and make the right decision for the greater good. This leads to an application that delivers business value. No-one wants selfish dictator, who puts his own agenda first. That would be wrong.

---

(1) Sometimes these extra stakeholders raise good points. I hate that, especially when it happens late in the merry-go-round. I can’t help feeling it’s rude.

(2) Note that authority can be hierarchical, but it can also be from earned respect, or even assumed by a sufficiently large ego. The source of authority doesn’t really matter to the technical team, so long as it is someone who can in good conscience be treated as gospel.

There is a style of game design called sandbox design. The game creates an series of areas where the player can do stuff. The player remains in each area until some point. Once achieved, the player moves to a new sandbox.

The contrast is with games designed in a more linear fashion. In these cases, the player triggers a series of events. In extreme cases, they have no ability to trigger a different event… it’s always do this, then do this, then do this. It creates a very static world, with little responsiveness. When a game is designed this way, the player can storm an enemy stronghold, kill half the inhabitants, go home, have a nap, and return later, refreshed, to find that nothing changed while you were gone.

(Game developers have reasons for doing this… flexibility has a cost. Not only is it easier to make, but it’s also easier to predict situations. The more flexibility a player has, the more likely they are to do some crazy stuff. This is hard to design for, and hard to test.)

Anyway, I’ve been wondering if the sandbox model would help to document requirements for a business application. The idea would be to define a domain, set the rules, and then leave the dev team to develop the solution.

Here’s how I imagine it would work. First, start with a process flow. Divide the flow into major areas linked by the domain. Each section becomes a sandbox. For each box, define:

• domain objects
• ways to interact with the domain (e.g. login, create orders, etc)
• ways the domain responds to user (e.g. verification, validation)
• one or more exit criteria (event + conditions)
• destination sandbox (if Exit Criteria A = true, then more to sandbox N)

Here are the possible benefits:

• strong focus on business process
• strong focus on domain rules
• manage nesting conditions and branching narratives
• avoid premature screen design
• applications with a very flexible very of user interactions

Now, I’m thinking this would be used for user requirements, mostly because that’s where I spend my software development time. Maybe the approach might be useful in later stages, if it is handy to divide the application up in this fashion.

Now, this is a crazy idea at the moment, so I’ll try a couple of examples to flesh it out.

Example: Blog Entry Sandbox

This sandbox covers the creation and management of a blog entry. It does not cover the viewing of a published post… that would be a different sandbox.

Domain

• Post - must have a title (a string), and a main body (a very long string with HTML allowed). May have a summary (a string with HTML allowed). May be linked to many tags. A post may be either published or unpublished.
• Tags - a short string
• Comments - must have a comment text (a string). May have author details consisting of one or more of name, email, address. A comment may be pending, approved, denied or spam.

A post has zero to many tags.
A tag describes zero to many posts.
A post has zero to many comments.
A comment must be about a single post.

Actions
The user can set the current post by creating a new post, or selecting from all unpublished posts. (some more stuff about authorised access to posts.) Whenever the user changes the current post, the user is first prompted to save the current post.

The user can edit the elements of the current post.

The user can save the current post even if it does not have a title or body. The system will automatically save the current post every 3 minutes.

The user can delete the current post. Deleted posts are immediately removed from the database.

The user can view a preview of the current post.

The user can publish the current post if it has a published post must have a title and body. When the post is published:

• a RSS summary of the current post is distributed to the recorded search engines.
• The system changes the current post to a empty post.
• The user can unpublish the current post.

The user can link or unlink a tag to the current post. The user can create new tags.

The user can view all entered comments. The user can change the status of all comments.

Example: Application sandbox

This describes a much larger sandbox, which “contains” many smaller sandboxes. I’m using this as a host for non-functional requirements.

Domain

• Menu -a set of predefined menu items
• Menu Items - must have a text and a destination sandbox. May have a subset of menu items.

Actions
This application is a web based application.

The menu is always visible. The user may click on any entry. This will move the user to the relevant sandbox.

The user must be authenticated by a login and password. Authenticated users must be identified for the entire session. Anytime an unauthenticated user attempts to enter any sandbox, the user is directed to the Login sandbox.

Unless specified elsewhere, all screens use the admin style sheet, as defined somewhere else.

Response times are less than 1 second. For any process taking more than 1 second, an interim indicator must be shown.

All application HTML must be XHTML compliant.

The application features are to be tested on IE 6, IE7, Firefox 2.1.0, and Opera 7.

Closing thoughts

Writing those examples did feel very different to writing a use case… much more declarative. This could be a weakness, if you lost the idea of the sandbox scope.

I can see some developers getting annoyed at the results, for being insufficiently precise. I think there would have to be a technical spec style artifact explaining how each sandbox is realized. This isn’t a bad thing in itself.

The application sandbox appeals to me, because it brings non-functional requirements onto an equal footing. In fact, since it would be presented first, it might give a priority to the non-functionals.

I didn’t really have exit criteria, because I wasn’t working on a full system. *meh*

I periodically get into arguments about Wikipedia and it’s reliability. In these arguments, I typically lean heavily on studies which show the accuracy of Wikipedia is comparable to other encyclopedias (in particular, the Encyclopedia Britannica). Here are the actual studies, for future reference.

Nature, 2005

The first is a study by Nature, published 15 December 2005. Unfortunately, the study is in a pay zone, but there is an editorial about the article:

But as an investigation on page 900 of this issue shows, the accuracy of science in Wikipedia is surprisingly good: the number of errors in a typical Wikipedia science article is not substantially more than in Encyclopaedia Britannica, often considered the gold-standard entry-level reference work.

Editing pages is not always straightforward, as some users may disagree with changes. In politically sensitive areas such as climate change, researchers have had to do battle with sceptics pushing an editorial line that is out of kilter with mainstream scientific thinking. But this usually requires no more than a little patience. Wikipedia’s users are generally interested in the reasoning behind proposed changes to articles. Backing up a claim with a peer-reviewed reference, for example, makes a world of difference.

Nature would like to encourage its readers to help. The idea is not to seek a replacement for established sources such as the Encyclopaedia Britannica, but to push forward the grand experiment that is Wikipedia, and to see how much it can improve. Select a topic close to your work and look it up on Wikipedia. If the entry contains errors or important omissions, dive in and help fix them. It need not take too long. And imagine the pay-off: you could be one of the people who helped turn an apparently stupid idea into a free, high-quality global resource.

Britannica complained about the study. Nature posted a response (pdf):

In Britannica’s statement of 23 March, the company also addresses specific errors identified by our reviewers. Britannica has examined these points, and claims that some of them are not errors at all. It is worth noting, though, that of the 123 purported errors in question, the company takes issue with less than half, and that Britannica has subsequently corrected many of the errors that our reviewers identified.

First Monday

There is a second study was in First Monday:

No difference was found between the two group in terms of their perceived credibility of Wikipedia or of the articles’ authors, but a difference was found in the credibility of the articles — the experts found Wikipedia’s articles to be more credible than the non–experts. This suggests that the accuracy of Wikipedia is high. However, the results should not be seen as support for Wikipedia as a totally reliable resource as, according to the experts, 13 percent of the articles contain mistakes.

Now, First Monday “is one of the first openly accessible, peer–reviewed journals on the Internet, solely devoted to the Internet”. It is a little unsurprising that the review is so positive. I’d want some concrete examples before a bias claim, though.

Larry Press

I came across another study by Larry Press:

So far, 50 respondents have evaluated a Wikipedia article in an area of their expertise. Of those, 76% agreed or strongly agreed that the article was accurate and 46% agreed or strongly agreed that it was complete. Of the 50, 18 compared the article they reviewed to the article on the same topic in the Encyclopedia Britannica. Thirty four percent of those people found the Britannica more or substantially more accurate and 39% found the Britannica article to be more or substantially more complete.

Larry Press is a Professor of Computer Information Systems at California State University Dominguez Hills. Frankly, I didn’t much like his survey, because of heavy use of a Likert scale. He does have a nice collection of links on the subject, though.

Other things

Wikipedia has an entry on Wikipedia, describing process and community.

There is also an entry on Criticisms of Wikipedia. I quite liked this image, and the equivalent in French.