Continuum Thinking: 4 Ways to Improve Your Thinking

(Warning: this might be a bit deep and meaningful for first thing in the morning.)

With all the complexities in our lives it often helps to sit down and mark-out even the seemingly obvious - a bit like going back to basics, making sure you have a firm foundation before going on.  One reason for this complexity is the organic nature in how things are related - there is often no clear delineation that marks where one thing starts and another ends, which can make it hard to see exactly how things inter-relate and react.

One technique I use to help my thinking is to think of things in terms of a continuum (a basic form of modeling).  The basic idea is to take the organic mess, isolate out specific bits of the greyness and figure out where the important relevant points lie so that I can more easily figure things out.

I find thinking in this way helps me to:

1. Figuring out who or where you are
2. Size-up / quantify something new or unknown.
3. Extrapolate and predict: work out where things might go.
4. Compare things.

So what is a continuum?

Wikipedia defines a continuum as:

“…anything that goes through a gradual transition from one condition, to a different condition, without any abrupt changes.”

To that I would also add that a continuum has end-points or extremes; and I find that being able to place things in relation to an extreme is helpful.  So:

• A continuum has two extremes – these are polar opposites: black and white.
• Between the extremes are infinite shades of grey.
• Some extremes are absolute (or practically near enough) [type 1].
• Some extremes are in flux [type 2].
• One extreme may be well understood, but the other yet to be found (or only exist in theory) [type 3].
• One extreme may be fixed and the other in flux [type 4].

Examples:

• Computer processor speed: relative [4].
• Possible application of Smart Phones [2].
• Software qualities like scalability and testability: relative [3]
• The limits of manned space travel are theoretically near boundless [3] but for time being practically limited [1 or 2].
• Breadth of technology use: relative [1] – if using only one vendor or technology is one extreme, what is the other?  The use of “all software in the world” is neither practical nor desirable and probably not easily defined (an example of [3]?) but once you go beyond a certain point the exact position of the extreme is academic.

Observations:

• If the extremes move you’ll need to re-evaluate your position on the continuum.  If an extreme is pushed out too far and your strategy dictates you need to be ‘middle of the road’ then you won’t be in the middle anymore.   Moving an extreme can also lead to an “arms race” when two continuums are related – such as “the internet” and organised crime (e.g. the advent of social networking pushes out the extreme in terms of how people can interact online, and therefore exposes new opportunities to criminals and pushes out their extremes of the continuums of ease, profit and risk).
• Reaction: if every action has an equal and opposite reaction, then it’s likely that being on the extreme will have extreme reactions (Apple and the iPhone, Open source vs. proprietary, and so on).
• Continuums can be visual – why write a thousand words when you can convey the information more effectively visually?
• Even if you don’t actually place things on a continuum, just working out what continuums are relevant to you can be beneficial.

Using Continuums in Practice...

Real world continuums

There will be a lot of these; whether they are explicitly stated as such will be a different matter, but one that is is the TOGAF Enterprise Continuum.

The TOGAF Enterprise Continuum is useful when considering how various architectural assets relate and thinking in terms of their potential re-use.  In the diagram above, items on the left are general progressing to more specific on the right.  Top to botom is standards progressing into implementations.

Figuring out who or where you are.

In the world of Data Architecture and system implementation there are basically too kinds of database: OLTP (Online transaction processing) and OLAP (Online analytical processing).  Let’s say that these are the opposite extremes of a continuum.

Both have strengths and weaknesses, and both are intended for specific jobs; as the name might suggest, an OLTP database is what you’d use to support an application that needed to support real-time interactions (where data is being added and changed regularly), where-as you’d use OLAP for reporting (where you’d have lots of data that you just want to read).  Both types have many subtle (and not so subtle) differences but one key characteristic they both share is that they are designed for good performance.

So, how does this relate to figuring out who or where you are using a continuum?

Consider a system you’ve developed - and the specifically the database you developed for it: is it an OLTP or OLAP?  Perhaps it has elements of both?  Let’s go out on a limb and assume that the database you’ve developed is for an application which allows users to add and manage some kind of data, as well as report on it in some way.

Overall performance of the system will be influenced by many factors, and it’s quite likely that your “all-in-one” database will suffice initially, but now think about scenarios where the usage is heavier: more users and more data (e.g.: at the steeper end of a use continuum).  If we accept the arguments such as Curlys Law and SRP (Single Responsibility Principle) then your database should only do one thing.

Taking this the final step, looking at the OLTP / OLAP continuum we might conclude that:

• Our database is transactional, so let’s focus on making that work really well (even if we know reporting is going to suffer, or vis-versa).
• Ultimately we’ll need to divide the database in two: one dedicated to being a fit for purpose transactional database, and the other a fit for purpose reporting database.

There are other variations on this that might be relevant to you, here are some examples.

Consider how dependant you are on a single vendor or technology stack.  Being dependant isn’t necessarily a bad thing if it’s done for calculated reasons: your solution might not run anywhere, but it might run extremely well on the specific platform(s) you target.

Regardless of how aligned or dependant you are with a vendor or technology stack, considering the continuums that are relevant to you may expose weaknesses or opportunities previously obscured.

Market analysis: use continuums to define your market and your place on it, identify the current extremes and where you want to be.  Consider your offering in terms of continuums and how they relate. 

User analysis: use continuums to define and segment your users, who are the main users and what are their expectations.

How to size-up / quantify something new or unknown.

Perhaps you’re a developer and you’re applying for a new job.  How can we work out how suitable we are, how do we get a more solid idea of the hiring companies expectations?

Let’s say that “the ideal candidate will have a sound understanding of Object Orientated Design Patterns”.  So what does “sound” mean?  If we evaluate this against a continuum we might get a better idea. 

The first thing I would do in this sort of situation is to try and identify the extremes.  Identifying the low end of the spectrum is usually relatively easy; in the current example one extreme will be a complete lack of knowledge of design patterns “Dependency Injection – is that where you shoot-up on drugs?”

Depending on the topic, placing the other extreme might be relatively easy or may involve some in-depth research – a quick way could be to talk to someone whose opinion you value and who may have some knowledge.  Another way is to look at other continuums and their extremes – try comparing and extrapolating out where the other extreme might be.

As far as the job application goes, the other extreme will be something along the lines of “you are Martin Fowler or Kent Beck”.  Obviously the idea is to map the “knowledge of patterns” continuum with the “jobs seniority level” continuum (which implies that you have actually defined those in the first place). 

• If the position advertised is a junior one then it’s unlikely they’ll be expecting Martin Fowler – as a junior you’d probably expect to be able to work in the confines of the pattern and gain an understanding of it.
• If it’s an intermediate role then you’ll need to be able to demonstrate a working knowledge of patterns that shows clear growth towards a senior level.
• For a Senior Developer role you’ll need to know the patterns well enough that you can explain it clearly to a junior, and you’ll need to know more than just one or two.  You’ll also need to be able to correctly identify where and when a pattern could be used appropriately.

How to extrapolate and predict: work out where things might go.

What is the natural / currently practical extreme as far as remote control aircraft go?

Well, we know that:

• Any hobbyist can build and fly a remote control aircraft, and in fact some nations currently use remote control drones for conducting operations in a way that is “non-trivial”.  So remote control technology has obviously reached a mature point as far as aviation is concerned.
• On the aircraft continuum we have (at the low end) paper darts, micro lights and so on; and stealth supersonic jet bombers and massive cargo planes at the other end.

So what is the current “state of the art”?  What is the high-end extreme in remote control planes?  You might be familiar with the drones currently in-use by the U.S in Afghanistan – but this isn’t at the extreme.  This (if you haven’t already) is where you map the two on top of each other and work out where the extreme is, and this is it: the U.S Navy’s X-47B carrier-capable drone (pictured below), which could (at least in theory) be used as a nuclear-armed drone called the “Nuclear-Dedicated Unmanned Combat Aerial Vehicle” or ND-UCAV.

For more on drones and advances in military technology see Wired's Danger Room.

Other examples:

• New York vs. Wellington: mindset of inhabitants, competition for resource – predict future trends in Wellington based on New York. 
• Moving into a new area (like running your own business), use continuums to predict scenarios you’re likely to face and possible outcomes.  For example: do you need venture capital?  How much and what for?  Is that amont of money extreme?  Will the venture capitalist think so?  If it is extreme then maybe you’ll get an extreme response.

Comparisons.

Another variation on the extrapolation theme is to take a continuum from one place and apply it to another: for example take something that applies to groups and try applying it to a person.

The fundamental foundation of agile methodologies is that a group of people is involved, but this doesn’t mean that agile development is restricted to groups.  Many of the agile principles and practices can be applied to a single person working on there own: embracing change, feature lists and burn-down charts to name but a few.

So, by using the “agile continuum” you get a measurement to which you can compare someone (such as yourself) and see “where you are”: are you embracing change?  If not - is that an opportunity or is that for a good reason?  Re-evaluate your assumptions – they may have changed.   If companies embracing agile are having greater success – does that mean that you can enjoy similar success by adopting agile yourself as a person.

Going one further: can you take the agile principals you use at work and apply them to your life?  It’s quite amazing how learnt behaviour affects every day things – many “agile” folks I meet may be great at agile development, but they don’t seem to apply the same thinking outside of development.

This is (I think) an example of continuum based thinking: taking a known quality and its extremes and applying or comparing this to something else.

But I already do that.

“But I already do that” you might say, and you’d be right, it’s something we all do naturally; the point I want to get across is that being conscious of this has advantages, and it can (and should) be used as a tool to help you know where things stand.

So regardless of whether you’re a developer, architect or anything else: with all the complexities in our life, it often helps to sit down and mark-out even the seemingly obvious.