I want to show you how I solve problems.
I’ve noticed that people tend to honor formal agreements far more often than informal ones.
Let’s start from a basic proposition and work our way back to that observation. People seem to want and need things. People tend to cooperate with others in order to fulfill most of their needs, wants, and desires. Some cooperation is immediate: it occurs at a time and place without prior coordination or formal agreement. Some cooperation is eventual, that is, people participate in a sequence of mutually beneficial activities. In the case of eventual cooperation, it is common for participants to agree in advance about the sequence of events. When the stakes are high, details about promises and consequences of breaking them are formalized. Quite often, skilled practioners create and negotiate those formal agreements. This tends to be expensive. Sometimes, it is worth it.
Shouldn’t it be easy by now to create formal agreements? It’s not like the agreements most of us make are novel. Sure, the parameters of any one agreement are virtually infinite, but the variety of forms of agreement I typically enter into with other people are fairly conventional. However, taking the time to formalize things can be a total waste without assurances that the agreement is valid and enforceable.
Why
I’ve picked this problem because it is real. It’s also familiar and well documented. That means we can really focus on the problem solving process as we work through the problem without getting too bogged down in learning an esoteric field.
There is substantial inherent complexity present here too. For me, understanding complexity is much more important than understanding how to apply the latest tech to a problem. What complexity is, where it comes from, and what we can do about it is both durable and essential knowledge.
However, I am not trying to build a viable product. If I were, my approach would be completely different than writing a sequence of articles. Also, please don’t take anything I say here as legal advice.
How
We’ll take things in small steps. In each article we will make some meaningful progress. In general, the goal is to break things up into small steps that can be made in about 4 hours by a skilled practitioner with domain expertise… or about 4 days by an unassisted novice without.
Our general approach will be to gradually improve our understanding of the problem domain, create something tangible (at least) and functional (at best). Dave Thomas describes this approach in Time to Kill Agile:
- Find out where we are (orient)
- Take a small step towards the goal (move)
- Adjust our understanding based on what we learned (adjust)
- Repeat
Where Are We?
We want to learn something about how to build a system using contemporary techniques. Complexity is something we expect to encounter and we want to learn how to deal with it. So, we’ve selected a problem domain that is well documented and technically solved.
Our Small Step
There is a now an article – a tangible artifact – that explains what we are setting out to do and not to do.
Adjust Our Understanding
We may make potential adjustments to our goals, anti-goals, and overall approach.
Left Field
When I’m getting to know people that write software, I like to ask “What makes building software difficult?” It ain’t typing the code!
Ben Moseley and Peter Marks, the authors of Out of the Tar Pit have this to say:
“The biggest problem in the development and maintenance of large-scale software systems is complexity — large systems are hard to understand.”
If you agree with this observation and you happen to be building software in any sort of competitive sense, what you do about it can give you a very sharp edge. I’m curious though… what is large-scale?