Problem-driven development?

Another reflection after listening to Seddon on “Rethinking Lean Service”

Seddon argues that you need to let the actual problems (that disrupt your delivery of value) dictate what activities you perform, and what processes you set up. This implies that you need to be brave enough to allow problems to occur (and have a way of catching and solving them). It means (in software terms) that you must not pre-optimize (of course!) but also not pre-solve, problems you haven’t yet had (even if these occur in 90% of similar projects), and also not pre-create functionality you haven’t yet found a request for (again even if these occur in 99% of similar projects). This is related to the software principle of YAGNI (You ain’t gonna need it) and DTSTTCPW (Do the simplest thing that could possibly work).

This problem-oriented flow is similar to the principle that Seddon characterizes as “Demand-driven” development, for which he stipulates that it is critical to differentiate which kinds of demand represent value, and which actually flow from “defects” and represent waste. For me, in software design, this is an understanding of user/customer/client requirements - these are demands, and some of them follow from the need to generate extra user-value (a needed feature), but some of them actually indicate defects in the existing system. It’s critical as a software designer to be able to differentiate these two, or you may end up building a monstrosity where new features are introduced to correct old mistakes. (I could give common examples but instead will choose one that I find really instructive: the example of the No Kahuna team who chose to remove a feature to fix an apparent defect in their webapplication - This is the right and brave decision even if I personally relied on that feature, and my team didn’t see a defect - and as Nathaniel pointed out in his comment - a very rare event in software development)

(adapted from part of my post on The Connected Republic)