The common sense unit of work

"What if we were to model a typical software development lifecycle in code? The unit of work would be the fundamental abstraction. We'd build state machines and workflows around it, carrying it from specification to deployment through activities performed by product managers, engineers, designers, and others. The process could be customised to each team's needs, with all the bells and whistles. But fundamentally, its effectiveness and adaptability depends on how good this central abstraction is."

"Get this abstraction wrong, and complexity scales exponentially. All the processes built around it inherit the dysfunction. Planning becomes chaotic, progress becomes opaque, and coordination becomes an expensive mess. We deal with leaky abstractions by periodically refactoring them, so why not do the same thing with the unit of work? What makes a good unit of work? Let's walk through these familiar activities and observe the properties that emerge."

"We don't usually take on a full feature in one shot, it's "too big". Especially if it's complex enough to need some technical design and specification written along with it. We break it down into small parts that are more approachable for solving, and also give us a steady sense of progress. Now the product requirement is actually a hypothesis for creating business value, and we need to validate the hypothesis as early as possible."

The unit of work should serve as the core abstraction that travels from specification to deployment through state machines and workflows. Effectiveness and adaptability of development processes depend on the quality of that abstraction. Poor abstraction causes exponential complexity, chaotic planning, opaque progress, and costly coordination. Work should be broken into small, customer-valued slices rather than layers, while allowing independent technical tasks like bug fixes or refactors when appropriate. Prioritization and early validation of hypotheses maximize value. Periodic refactoring of the unit of work is necessary to keep the abstraction fit for purpose as teams and requirements evolve.

Read at Nilenso