Intelligent Solutions Matter

If you ask a solution provider, any solution provider, if their solutions were “intelligent”, you can bet you won’t get a single “no” answer. Consequently, every solution out there is intelligent, right? But is it?

What is an “intelligent” solution?

I don’t think this question can be generally answered. A solution is intelligent (or dumb) only within the context of the problem it solves (or attempts to solve). However, intelligent solutions do share some common distinguishing characteristics.

[toc style=”margin-left:18em; margin-right:18em”]

From Requirements To Solutions

The process of shaping a solution starts very early, when gathering requirements and deriving features from them. It continues with selecting technologies on top of which the solution will be built, evolving an architecture for the solution, and designing the structure of the software.

One utterly important step upon which a pre-selection between intelligent and not-so-intelligent solutions is done, is the transition from requirements to features.

It’s a process called requirement analysis, and it is mostly done wrong. Well, strictly speaking it is hardly done at all: In the vast majority of cases, requirements are “translated” 1:1 into features.1

This is due to two factors:

Firstly, the way requirements are gathered is mostly a mere collection of “feature requests”. A “feature request” tends to be kind-of partial solution draft prescribed by the client.2 As such, it lacks one important property: Purpose.3 Without knowing the purpose, you can neither question nor improve upon prescribed solutions. However, developing true understanding for the purpose behind the user’s solution fantasies4 is a skill not everybody can call their own.

Secondly, it’s an art of own to map purpose onto features. Mmmm… I see, this will take a bit of an elaboration…

Intelligent Engineering

The process of solution engineering takes place in the space between

1. (purposeful) requirements,
2. (carefully designed) solution concept, consisting of (conceptual) solution features
3. technical concept / technology / implementation

I can give a fresh example:

For my Sliding Notes plugin, there have been several request to have “only one note open at a time”. Proposals were to have an option to control the behavior. But as it stood, this did not match the concept and purpose of a Sliding Note well.

As it turned out, the purpose behind “one note open at a time” was the desire to achieve an accordion effect. But if I just directly translated accordion-style behavior into a feature, its realization would have been so fundamentally different from the Sliding Note’s technical concept, that it would have ended in two entirely different products packaged as one. Clearly not a desirable state.

I almost got into designing a new, separate accordion plugin, when it hit me that, if I just translated the “accordion” request into a “note grouping” feature, it would (a) satisfy the purpose of the request, (b) fit smoothly into the existing Sliding Notes concept, (d) be more generic (and hence more powerful) than an accordion, and (c) be fairly easy to implement.

A single idea and decision had turned a seemingly difficult requirement into an elegant and easy (hence inexpensive) solution. The rest is history.

Inside Intelligent Solutions

Interestingly:

1. A grouping feature has never been explicitly requested as such. It was the result of a requirement analysis that took both, purpose, and underlying technical concept, into strong account.
2. A grouping feature allows for more things than requested5: It allows for a free arrangement of alternately expandable notes, and is as such more powerful than an accordion.
3. Nonetheless, the feature has been easier (read: less expensive!) to implement.

To conclude:

A solid solution provides features that match user requirements 1:1 (but nothing more).

An intelligent solution provides features that enable users to do things that go well beyond the explicit requirements; they match their purpose, not merely their wording. And it does so by providing less (but more powerful) features.

In short:

Intelligent solution = more value for less money

If we defined a solution impact as the value a solution provides relative to its overall (short and long term) cost, then we could also say:

Intelligent solutions are high-impact solutions.

The Secret Behind Intelligent Solutions

The secret behind designing such solutions is in the ability to raise one’s consciousness to a level higher than the problem level (where the requirements are defined).6 It is common in software development to decrease the abstraction level along the way from requirements to implementation (a legacy from top-down / waterfall approaches of the past). But mapping requirements to (conceptual) features is a process that requires the opposite direction – raising the abstraction level.

Not everybody is naturally prone to this. Key is an open mind – a mindset that naturally strives to discover potential and create options. Later down the road, especially along low-level design, coding and testing, a closing, selective mindset might be more appropriate to actually get things finished. But that’s exactly the wrong mindset to get things started on the right foot.

I just happen to have inborn such a mindset. Options and potential reveal themselves naturally to me. Try me out, see for yourself! 😉

1. Hence the term “feature request”. [↩]
2. Due to the client’s lack of technical knowledge necessary to design a sophisticated solution, a feature request is often enough but a mere solution fantasy 😉 [↩]
3. Greetings from the Merovingian. 😉 [↩]
4. Due to the client’s lack of technical knowledge necessary to design a sophisticated solution, a feature request is often enough but a mere solution fantasy 😉 [↩]
5. albeit in a more indirect way [↩]
6. As Einstein said: “No problem can be solved from the same level of consciousness that created it.” [↩]

Comments are closed.