Wednesday, December 28, 2016

Well-Written Scrum Stories

I work in a domain where Stories in the sense of Well-Written Scrum Stories don't always work well. Think this is heresy? Read on.

My domain involves the construction of a system. Part of my team's responsibilities include writing software for business logic but it also includes writing software for control elements within the system. For example, we might be asked to integrate a new sensor into our application and that sensor might affect the user's work flow or we might integrate software in the support of mechanical elements (such as motors).

Stories for the sensor integration typically don't sit well with me. The reason for this is that I emphasize user value for my stories. In simple terms, my customers won't pay a sensor. They will pay for the utility provided by the work flow change that the sensor enables.

My emphasis on user value has worked well in other domains. I worked on the integration of Cilk Plus into LLVM. We were able to define stories that embodied user value. For example, one user story included the introduction of a for-loop supporting parallelism into the compiler and subsequent stories included the introduction of different stepping increments in the for-loop.

My current domain doesn't have that luxury. Or at least I haven't mastered this domain to that level.

The best description I've seen relating to my problem with stories in my domain comes from Bertrand Meyer. In Agile! The Good, the Hype and the Ugly, he describes how stories are not useful for describing situations with multiplicative complexity. That is things where all of the key elements of a system must be taken into account at the beginning.

So I live in a world where I use user stories focusing on user value for the business logic level and use another solution to handle the multiplicative complexity of the system. The other solution currently relies on traditional methods for requirements and design.

In effect, I am liberal in what constitutes my product backlog. It's not just user stories.

Thursday, December 22, 2016

Code Inflation in /bin/true

A friend provided a pointer to Code Inflation, published in IEEE Software (March/April 2015). It's an look at the growth of software and highlights this growth through the use of /bin/true and /bin/false over a twenty years or so. The statistics are staggering.

This article introduces some laws:
  • Software tends to grow over time whether or not a rationale need for this growth exists.
  • All nontrivial code contains defects.
  • The probability of a defect increases with code size.
And some wonderful advice: Instead of just adding more features to the next version of your code, resolve to simplify it.

This article references a paper by Rob Pike and Brian W. Kernighan, titled Program design in the UNIX environment which discusses the problems with the growth of cat in 1983. Pike and Kernighan discuss the style and use of UNIX:
... the UNIX system provided a new style of computing, a new way of thinking of how to attack a problem with a computer. This style was based on the use of tools: using programs separately or in combination to get a job done, rather than doing it by hand, by monolithic self-sufficient subsystems, or by special-purpose, one-time programs.
This paper contains insight on the style and design of cat and points out how important identifying a single function for each tool is and how doing so leads to the creation of a computing environment that supports a level of flexibility and utility that are simply profound.

It is the single function and purpose of these tools which embodies their power and more importantly their inability to astonish during one's use of these tools. The inability to astonish here is important: the tools work as advertised with no surprise. That's a critically important quality. This leads to another important observation in this paper:
The key to problem-solving on the UNIX system is to identify the right primitive operations and to put them at the right place. UNIX programs tend to solve general problems rather than special cases. In a very loose sense, the programs are orthogonal, spanning the space of jobs to be done (although with a fair amount of overlap for reasons of history, convenience or efficiency). Functions are placed where they will do the most good: there shouldn’t be a pager in every program that produces output any more than there should be filename pattern matching in every program that uses filenames.
A simple read that takes a similar stance is a book by Kernighan and Plauger called Software Tools (and an updated edition titled Software Tools in Pascal). Software Tools provides unique insights into the same philosophy of functionality and combination that made UNIX work so well.

Some different perspectives on UNIX philosophy: Simplicity isn't simple.