Thinking Inside a Bigger Box

On JavaZone (which was an huge success, IMHO), Richard Stallman was the guest of honor. He talked about the four freedoms which free software gives you, how the Sun Java implementation is not free, and why that might concern us. Then, he talked about something that should concern all of us, even if you think Free Software is bogus: software patents.

As I understand Stallman, if software patents become law, you can violate a patent without knowing it. Also, based on an inspection of source code, he made a back-of-the-envelope estimate that Linux contained somewhere between 10,000 and 60,000 patent violations. This means that your program probably contains thousands of patent violations.

This means that any program is succeptible to patent lawsuits, and any patent-holding organisation has a way of attacking corporate rivals. This means that in the future the number of lawers in a software development organisation will exceed the number of programmers.

If this is a future you don’t want, you should oppose software patents.

More info

• Examples of software patent:My favorite “Quicksort implemented using a linked list of pointers to the objects to be sorted” [#5,175,857].


• FFII: Software Patents in Europe

I am currently reading Hackers & Painters by Paul Graham. It contains many brilliant essays, but it also has a few not so brilliant ones. In “Mind the Gap”, Graham proposes the idea “in a modern society, increasing variation in income is a sign of health”. The rationale for this is that some people have the potensial to be more productive than others and by rewarding them proportionally, everyone as a whole would be better off. “I am not saying that if you let Henry Ford get rich, he will hire you as a waiter to your next party. I’m say that he’ll make you a tractor to replace your horse”.

At the fundamental level, I have no problem with Graham’s argument. But I see two problems undermining his argument: First, Graham says: “As [technology] seems to increase the gap in income, it seems to reduce most other gaps”. That is, we are not concerned about relative poverty, only absolute poverty. Second, Graham posits that the rewards a Henry Ford, a Wozniac, a Gates should get should be propertional to the wealth they generate.

On the subject of other gaps than income gaps closing, this is only true to some point. Modern societies seem to have an increasing problem with real poverty in the last decade. I don’t know where to find statistics for this, so I will have to go off an anectote. I live in Norway, one of the more socialist democracies in the world. We pay high taxes, we have socialized healthcare, socialized higher education, public housing, good unemployment benefits. Yet we have more poverty than we should have. Living in downtown Oslo, I occasionally witness such poverty. Yesterday was such an occasion. While walking the dog, I came across a collapsed man in a small public plaza. I called the police. “Oh, he’s still there? He’s a junkie, if you nudge him, you’ll see that he’s alive. He won’t freeze, so we can’t really priorize it. He’ll be fine”. It seems to me that here is clearly a problem of poverty that could be solved by throwing more money at it, in a “socialist” fashion. I know I would be happier if I know that more people like this were taken care of. I think the portion of people living in poverty in Norway is increasing. I think the US is even worse in this regard.

So much for the other gaps being reduced. On a whole, more wealth is generated, but I believe the level of poverty is increasing. This is obviously a bad thing for everyone.

Secondly, I agree with Graham that productive people should be rewarded handsomely. But this does not mean we must be rewarded proportionally to the wealth we generate. The more money you have, the more you are able to enjoy even a small increase. If your regular expenses are just paid off, a 10% increase in income is a 100% in disposable income. A steeply progressive tax regime could still maintain the incentive to excel. And the general rule, the more wealth you generate, the more you are dependent upon the estabilished infrastructure to produce, market, and deliver that wealth to your customers. The more customers you have, the more you are dependent upon your customers level of education, amount of spare time, and income in order for which others have paid.

I believe there is such a thing as Society with a capital S. Society’s interest is to generate maximum wealth, and distribute it in such a way to create maximum happiness (that is, the largest ratio of people being well off, not a few being exceptionally rich). In order to generate wealth, productive people have to be rewarded, as Graham describes. But in order to reduce poverty, to create good consumers and workers, to address the real cause of crime, Society should redistribute the wealth to a greater extent than what Norway or the US are doing today.

(If you want to improve the state of the world, close the tax loopholes for companies and individuals who flee a country for tax reasons, but still make their furtune on the infrastructure that country has created. This is as close as you can get to the old way of generating money that Graham describes: Stealing it.)

When I look back at the lessons from User Stories Applied, I realise that many approaches to requirements muddles different purposes of requirements together. There are three things requirements need to address in one form or another:

• First, the development team needs an understanding the needs (requirements) of the user.
• Second, the project needs a specification of what is inside and outside the scope of the project, as well as the priority and status of different deliveries.
• Lastly, the developers and testers will need to know detailed information about a requirment to implement it correctly.

RUP’s approach to Use Cases, tries to capture all of these aspects of requirements, and fails somewhat in all respects. The User Story approach is different, and I think, better:

• Understanding the real needs of the system users is defined as outside of the user story approach. I like to call the deliverable fullfilling this role the product description. Mike Cohn, the author of User Stories Applied suggests using User Role Modeling or Interaction Design to document this. I think this is essential. There is a very proficient field of usablity experts out there, but RUP largely ignore this body of knowledge. For understanding the needs of the user, the rule is that less is more. The most important attribute such a description has is that everyone reads it. Thus it needs to be readably. For projects that are subcontracted out however, the description may need more detail. On the other hand, if there is extensive knowledge about the problem domain on the team (Customer on site), the description can be very cursory. In general, one size does not fit all.
• Specifying and tracking the requirements for the project mandates a manageable requirement list (Crystal Clear). These requirements should obey William Wake’s INVEST guidelines. The main purpose of this list is to control and monitor the project. On most projects the list can be kept fairly agile, but it needs to be well managed at any point in time. With classical user stories, the list is the stack of cards. Use cases often do not pay sufficient attention attention to the Independent, Negotiable, Estimatable, or Small recommendation of the INVEST guidelines. Unless this is kept in mind, Use Cases are not necessarily the right tool for this job. Also remember that on an agile project, items on the requirement list may be split, joined, added, or deleted, even far into the project.
• When a system requirement is implemented, the team will require a lot of information. “How often”, “how much”, “what format”, “what business rules”? However, and this is important, these requirements are generally not necessary in order to estimate the work reasonably accurately. The information can be extensive, time consuming to gather, and hard to predict up front. In extreme programming, the detailed requirements are discovered incrementally through conversation with the Customer and documented with Acceptance Tests. RUP seems to want to include this information in the up front requirement gathering (Supplementary Specification) which can lead to a very front heavy process.

For a good incremental approach, it is imperative to avoid mixing the detailed system requirements into the other sets of requirements. The reasons for this are:

• The extra amount of work in the beginning of the project will delay feedback and thus increase risk.
• Due to the amount of information, having the information be recent in the heads of the people implementing the requirement is a major boon
• It is almost impossible to get the detailed requirements complete. This leads to a risk of “extra detail being mistakenly associated with extra precision.” (Mike Cohn, User Stories Applied). This is the main reason for the Negotiable guideline for user stories.
• The extra “weight” of the requirements will make them harder to change, even when changing them would be preferable.
• The desire to specify all the details in full can very easily lead to “Analysis Paralysis”.

I am just now discovering the separation between these concepts. The separation shows both the need for interaction design/usability as a more extensively used discipline, as well as the danger of confusing the different level of requirements in practices such as use cases.

As a conclusion: If you use Use Cases, especially from RUP, be aware of the different levels of details and make sure to avoid having the initial requirement analysis delay the start of the project too long to provide effective feedback. Develop a sufficient model to understand the needs of all the system stakeholders, create an initial list of deliverable requirements, and get some real feedback.

I bought User Stories Applied to get help with practical problems with writing good user stories and requirements in general, but it ended up changing the way I think about requirements and tracking them.

The book first fullfills one very important mission. It answers “what is a good user story” with a mnemonic rule: Independent, Negotiable, Valuable, Estimatable, Small, and Testable (INVEST). Cohn refers to William Wake as the source of this mnemonic, but expands further upon how to achieve it. For me, the most useful parts of the book was the explainations of some of the more difficult points of extreme programming’s Planning Game, such as how to split up large stories, how to estimate the effort, where to get the stories from (Cohn’s suggests using the technique User Role Modeling), and how to deal with a lack of a “real customer.” Towards the end, Cohn compares User Stories to Use Cases. For me, the discussion revealed some of the weak points of Use Cases. Based on User Stories Applied, I feel confident that the Planning Game from extreme programming addresses requirement management sufficiently for very many projects.

Reading the book made me realise the different faces of requirements and where user stories fit in. There are requirement types for which user stories may not be appropriate, but they will probably still help. More on this in later.

If you are managing requirements, especially in an agile context, this book is a must-read.