Sashimi

he book Agile Project Management with Scrum discusses the concept of Sashimi where software functionality is implemented as tiny packets of micro-features. This struck a cord with me.

The idea is that each small chunk of functionality is completely implemented end to end, including

• tests,
• documentation,
• data migration,
• and deployment mechanism.

Done, done, done in agile terms. Each micro-feature needs to be completed before moving on to the next sashimi slice.

In the bad old days I used to concentrate on getting the mechanics working and leaving cosmetic issues and documentation until later. By the time I finished the mechanics of a cluster of features I would have a long list of lower priority tasks I would have to work through.

Often I would be pulled off in the middle of a project to deal with a high priority task which in turn was interrupted by even higher priority task.

The backlog of partially finished work often became unmanageable. I tried to resolve these issues by breaking tasks into smaller pieces and limiting the dependences between the new functionality and the old so I could switch in the new feature seamlessly.

After reading Lean Software Development's comparison of partially finished work to inventory, I started reducing the number of tasks I had open at the same time and reducing the size of tasks even further. After reading the extreme programming material on Ward's Wiki I redefined my definition of 'Done' and my definition of what was important, to include everything that was necessary to deploy to the end-user.

This did not happen overnight but was an evolution driven by hard won experience and encouraged by exposure to ideas that resonated with that experience.

With the concept of sashimi I have another idea that resonates with my experience, and that helps me bring into sharper focus the direction in which I wish to improve my software development processes.