We could postulate that there are two types of people in the world: those that plan, and those that don’t. The first type sees a task before them, and mentally works through the task on paper or in their head to its logical conclusion, considering each decision and consequent branch, and understanding the breadth and depth of the task to the extent possible. The second type deals with the issues in front of them one at that time, and works their way through issues ad hoc.
The world needs both types of people. The planners tend to do things the same way time and again. The non-planners (some call them creatives) do things different every time, occasionally with amazing results.
This is an unfair generalization, as most people are not one type or the other, but rather shades of gray in-between. And one type is not “better” or worse than the other, just different. Why then, do we make the point that there is a difference? Risk.
If you live one mile from a grocery store, planning your shopping trip for meals for the next day or week is not terribly important. If you forget something, you can just swing by and pick it up the next time you’re in the area. The risk of not planning is low. However, if you live twenty miles from the grocery store, forgetting an essential ingredient can be disastrous to an evening meal.
On the other hand, a good chef may improvise the recipe and take advantage of ingredients on-hand. In this case, you may discover a new favorite dish, but it won’t likely be what you were expecting at the start of the meal. So the first path is safe and predictable. The second has a higher degree of risk with potentially unexpected results.
If you’re managing a business for profit, which approach is preferable? If you’re risk-averse, you’ll take the first approach and settle for the safe and predictable outcome. If your budget and schedule have more flexibility, you may opt for the second approach and hope for something spectacular. As with all things, somewhere in-between the two is most likely.
When it comes to software development, the challenge of planning a task exceeds most people’s threshold for “reasonable”. The nature of software development works against reasonable planning as the software has not been previously written, the real requirements are rarely understood, and the very tools used for development make the planning process difficult.
If a software developer is given a task to develop a new piece of software (algorithm, utility, library, etc.), then by definition the requested software does not currently exist, or is not available. If the developer has created something similar in the past, they’ll have a head-start on the task, and may even be prepared to plan the whole task through deployment. This is the best-case scenario. It is much more likely that the developer is familiar with the concepts and technology, but will be required to learn details while en route to deployment. In this more typical scenario, the risk of unexpected results is much higher due to the greater number of unknowns hidden in the task.
Requirements is an ambiguous term. Loosely defined, it refers to the definition of a transformation of information or material from one form to another, or from one place to another. The lure of requirements is that they appear easy to understand from an individual perspective, but are insidiously difficult to relate between individuals for achieving consensus.
The tools in use by software developers focus on optimizing the turn-around time of making a change to source code, then compiling and testing that code. A good interactive development environment (IDE) in conjunction with automated testing makes code development seem easy, and in fact, it is. But that’s the lure of the siren song, leading the developer onto the rocks of failure.
Given an initial task definition, its easy to begin the development process and enter into a cycle of false productivity by generating tests, then write code to pass those tests. All without thinking about the task itself — the implicit and explicit requirements of the task, the tools and technology driven by those requirements, and the experience of the developer in the task domain.
To oversimplify, in the software development world it’s very easy to “do” before you “think”.
We understand the challenges of planning, and understand that 100% adherence to a process or method is as counter-productive as no process at all. We strive to seek a balance between the known and unknown to minimize risk to a project. It is always preferable to explore the real requirements and make them all explicit and communicable at the appropriate degree of ceremony. And then map the requirements into the appropriate technology for the experience and skills of an organization.
To oversimplify, it is always better to “think” before we “do”.