Two Kinds of Developer Tasks
There are two basic kinds of developer tasks. Those that take a linear amount of time to complete and those fall into the nonlinear classification.
The basic difference between the two is how predictable they are or are not. A linear task is one whose time to completion can be reliably predicted. Conversely, a nonlinear task can not be estimated with a high degree of confidence.
Linear
Of the two kinds of developer tasks, linear ones are the least interesting. This is where the drudgery lives. Moreover, we didn’t get into this business because we like going through the motions on solved problems.
Sending emails, attending meetings, writing documentation, and some coding tasks are primarily linear tasks. These are things whose time to completion is highly predictable if not particularly enjoyable.
To illustrate, if you’re answering an email there is little chance it will take you much longer than you think. Likewise with documentation or simple one-line code fixes. It’s just a matter of spending the time to complete the task. Dragons are highly unlikely to be hiding in these contexts.
Nonlinear
Solving nonlinear problems is where we deliver most of our value. Mapping real world business processes onto a digital medium is extremely challenging. While our tools have improved over the years, business complexity has increased markedly as well.
This increasing complexity has certainly been good for our job prospects as developers. Though it also means our jobs are becoming more difficult on the whole. With the raft of technology changes it means we’re regularly solving novel problems in new contexts. Hence the increasingly nonlinear nature of our work.
This is why estimates are increasingly difficult. As we’re faced with more nonlinear tasks, it’s inherently more difficult to know how long it will take to solve them.
Implications
The implications of this task duality for developers are many. Raise your hand if you’ve ever been pressured to provide an estimate for a nonlinear development effort by a manager or product owner. Everyone, right? It’d be far more surprising if you haven’t experienced this with regularity as a developer.
This very situation leads to the common practice in the IT World of taking a developer’s best estimate and arbitrarily doubling it. It’s done as a means of protecting against the nonlinearity of the request. Human psychology surely plays a big role too as it’s perceived as far better to beat an inflated estimate than miss a tighter one.
The Agile methodology really shines is this area. By insisting on sufficient granularity we can break down many nonlinear tasks into linear ones. It then follows that our ability to accurately estimate improves dramatically and it’s easy to make management happy with more reliable information. This assumes a fully empowered Agile team of course which is not always the case.
Summary
Developer tasks fall into two basic categories, linear and nonlinear. Linear tasks are easy to predict because they simply take time to accomplish. They are procedural.
Nonlinear tasks on the other hand are likely to contain unknowns. We can’t routinely predict them accurately because the problems may be unknowable until we’re solving them and they are revealed. Simply put, they contain emergent properties.
We as developers implicitly know the difference between these two kinds of tasks. However, non-developers will not always appreciate this and can sometimes conflate the two.
This leads them to mistakenly believe nonlinear task estimates are wildly inflated. Though usually these estimates are simply an acknowledgement of the dragons that are likely to be hiding ahead.