Sufficiency Development

I recently wrote a post on <a href="http://www.afterecon.com/other/7-techniques-to-conceptual-engineering/">7 approaches to conceptual engineering. This article discusses one particular approach in greater detail, or perhaps arguably outlines an 8th approach altogether.

Conceptual engineering is planning the way you are going to implement certain features into a product. The concept applies to all sorts of things including physical goods, but I often call to mind web or software development.

In digital development we first obtain requirements then we decide on an approach before we can make a project plan and actually get to work. Of course, we could just ignore all the planning and get to work.

During the part where we decide on the approach we are engaged in conceptual engineering. I discussed 7 approaches in the previously mentioned article, but I was not content with my description of the guess-and-check approach. This approach is one of the two most common in my experience, the other being brainstorming.

The problem is that in the real world guess and check is much not really an approach to conceptual engineering at all. It is more like a choice, consciously or not, to skip the planning phase entirely and just get to work. Basically it's the approach we take when hacking, as opposed to a more formal method.

This approach can be called hacking or guess and check, but perhaps it is best described as sufficiency development, or sufficiency oriented development. This approach values rapid deployment at sufficient performance over slower deployment at optimized performance.

Instead of thinking through all the possible next steps and selecting the best option, an individual following this approach will attempt whatever potential solution first comes to mind. If it works we move on. If not we try the next thing that comes to mind.

Only if we exhaust our own ideas do we then pause and shift into a more serious research mode where we look through documentation or online information, specifically looking to anyone who has run into our particular problem or a related problem and looking for less specific information if needed.

It is really a great example of <a href="http://www.theguardian.com/books/2011/dec/13/thinking-fast-slow-daniel-kahneman">Kahneman's modes of thinking. Hacking occurs in system 1 and we invoke system 2 only as needed, rather than entering into system 2 from the beginning which would be done in a more formal approach.

Sufficiency development is, I think, a better way of looking at how the guess-and-check approach works in real life. If many things don't work then we can look back and retroactively say we were experimenting with different approaches to find the best one, but that isn't what we were intentionally doing in the moment. Let's be honest. We were hacking and looking for the quickest solution which met our performance threshold or functional need, not necessarily the performance optimized or best solution.

Does this make sufficiency development bad? Not at all. In fact, by looking for the quickest solution which might work we are performing a sort of optimization. This optimization is a matter of development speed optimization, not product efficiency optimization. We are attempting to get the product out the door ASAP. Sometimes this results in a sloppy product, but sometimes it is just what we need. We could even strategically avoid a lengthy planning process for this very reason. Perhaps we want a working alpha or minimum viable product ASAP and we will improve it later. This is a valid candidate for approach in some profit-maximizing businesses.

Hacking can theoretically be bad by increasing odds of error, but as mentioned it can be good for speed. It might also be the case that over a given period of time hacking produces the best result because by month 3 the hacker is onto the 3.0 version while the traditional maker is onto beta deployment. Hacking has a couple other benefits worth mentioning.

Hacking can be great for the development team as a learning tool. The traditional way to learn programming is to go through school then get an entry level job and work your way up, with most people doing the minimum amount needed. Hacking allows you to gain knowledge and experience simultaneously and I think it is also associated with a self-driven personality which is a key skill of grit and success.

It is not clear whether a person becoming a hacker is a result of already having a self-driven personality or if hacking causes improved self-dependance, but my suspicion is that the answer is both to some degree. Hacking, then, is at least a signal and at best a cause of outside the box thinking and reduced social dependency. Interpersonal compatibility is good for businesses and individuals, but interpersonal dependency can be very harmful both for individuals and business productivity.