Get certified - Transform your world of work today

Software Is Made of Learning

07/26/2013 by Duncan Evans

In this article I explore the relationship between knowledge, skill acquisition, and building software. Compared with other types of projects, such as construction, I propose that software development may be highly biased toward team members learning the problem, and that building the software is a tiny fraction of the overall effort. If so, then we should approach software development projects to maximize learning and pay less attention to tracking build tasks.

Consider the following established ideas:

  • It's better to start building a complex new system and fail a few times than to spend the same time investigating and producing specifications.
  • Most developers could recreate yesterday's work from scratch in a more cohesive form in about half an hour the next day.
  • If you tell one-half of a pottery class to focus on quality and the other to focus on speed, the people who focused on speed will produce the highest-quality pots.
The following anecdote appears in Chapter 2 of The First 20 Hours, Josh Kauman's book on rapidly becoming competent at any new skill with 20 hours of focused practice. While advocating the use of quantity and speed during practice rather than ensuring absolute quality in whatever you are practicing, Kaufman cites an experiment done in a pottery class (taken from Chapter 3, Art & Fear, Bayles and Orland):

"All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality."

The end results may be surprising to an art teacher, but perhaps less so to anyone who has been involved in an IT project involving complex architecture and design:

"It seems that while the quantity group was busily churning out piles of work and learning from their mistakes, the quality group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay."

This example brought to mind numerous planning meetings at the start of projects, where it was argued that the framework must be nailed down first, or the overall design must be decided upon. How many projects have been canceled with nothing more than theories to show for them? I also remembered the maxim from my time as a developer, when it was often said that during your most productive days of coding, you could almost always produce a higher quality, more cohesive version of the same code the next day in about half an hour. On a day in which five hours were spent coding productively, that might indicate that 90 percent of the work is actually learning. Bringing these threads together, I propose a model:
  • The start of a new software project can be defined by the existing level of features and knowledge.
  • The cost of implementing additional features is proportional to the knowledge the team has about the general and specific problems.
  • Learning general software principles plus specific implementation could potentially account for 90 percent of the effort on a typical software project.
If this model is correct (which is yet to be established; the pottery evidence is anecdotal), then it would make sense to start a project with an emphasis on gaining knowledge about potential technologies and the specific needs to be satisfied. It has been demonstrated that we learn best by doing, failing, and adapting, so rather than spending three months in meeting rooms poring over architecture and considering what might go wrong, why not hack together a few working systems and feel good when you throw them away?

Established views from project management in other fields is that a certain amount of design must be carried out up front, and that while Agile is great for existing products, it's bad news to start a new enterprise system without a strong understanding of the overall architecture. Fears that development will be wasted if we have to start again are common. Here is the counterargument:

A month spent developing a system with the wrong architecture represents valuable learning by the team about the specific problem being solved. By seeing why their first design is unworkable, they will have learned a great deal about how to build a system that will satisfy customers' needs. This is not development thrown away; it is learning accrued. The challenge is to make this learning as visible and tangible as tasks ticked off on a project plan.