Crossing a River

Introduction

For those who are not in the software development business, I have tried to create a parallel to an engineering task simple enough that most can see what some of the issues are.

In this story we have a customer who wants to cross a river. He has seen other people using boats to cross the river, but he doesn’t know anything about boats, he simply wants to be able to carry some merchandise from one shore to the other without getting it wet.

The software developers he hires have no business insights into the river crossing domain, but they do know that they can solve almost every problem.

Customer: “I want to cross the river without getting wet. I’ve seen boats, but I can’t be bothered with the hassle of sailing one.”

Developers: “River? Wet? Boat? What are those things?”

Here the customers animosity towards the apparently completely stupid developers germinate.

Customer: “Don’t you know anything? The river is this flowing barrier. Boats float somehow and can be rowed across using muscle strength. But as I said – I can’t be bothered with the hassle of sailing one.”

The developers taking note of the animosity don’t want to ask more questions trying to keep up appearances they conclude that they have sufficient information to start work and their own preliminary investigations on the subject.

Version 1.0

The developers set up an investigation on the objects mentioned. They get that wood will float, and that apparently the river flows carrying the wood downstream, which means that there is a possibility of some kind of raft can be carried across using this flow.

Another team tests the best launch site of the raft within the river to the highest probability that it can land on the other side. They conclude that starting close to the middle of the stream has a high probability of keeping the raft in the middle of the stream.

The developers come up with the following solutions covering all of the customers needs.

Initial design for crossing a river

Proudly they show this to the customer, who in turn is thrilled to see it in action. Though after getting to the other side he’s a bit stomped, and asks the developers: “How do I get back then?”

The developers are fluttered. There is no mention of getting back from the other side, just a simple crossing.

The customer argues: “But that goes without saying. If I take my merchandise from one side to the other I have to get back to resupply.”

Version 2.0

One developer suggests reversing the flow of the river. Naturally you can’t do that thus he shows the lack of domain knowledge of rivers. But if it was possible to reverse the flow, then this would be a viable idea.

Whether the customer is informed of this idea or the developers try it out for themselves, the result is greater animosity or wasted effort.

While the reverse solution seemed stupid, another developer reflect upon the concept and the original idea, then gets his Eureka moment: We’ll just add another dock on the first side further downstream – it’ll be the same as going from the first to the second side, just reversed.

The developers proudly present version 2.0

Getting back to the first side again

The now wary customer is thrilled that he can get back home, but now there’s an issue with reuse. “I want to be able to bring another shipment, but now the raft will just continue down the river.”

Version 3.0, 3.1, …

After mentioning that this was another thing not in the specification, the developers come up with several suggestions for solutions.

  1. Repeat the success. Build more docks alternating sides. While this works for a few round-trips the customer finds that the way back home becomes excruciatingly long. Or they end up wherever the river flows to.
  2. Skip the surplus docks, just keep the three from the second solution. Build new rafts at the start of every round-trip. While this works, and the way back home is constant, the price for a raft: Materials and time spent. Soon becomes unfeasible.
  3. Drag the raft from the last dock to the first. This can be done either by the customer or some other power source, e.g. a horse.

Dragging the raft back to the beginning

While the customer now has a reusable way of crossing the river, there are better alternatives.

Some of the downsides to this solution:

  • Cost – the developers worked on several solutions. If they got to version 3 above before multiple docks or rafts, they would at least have saved a lot of time and resources.
  • Time – while time is a cost, then time spent crossing the river in this fashion seems wasteful
  • Parallelism – everyone crossing must depart at the same time or wait a full revolution of the raft. Naturally more rafts can be issued, but then there’s another problem of cluttering up the river.

The “correct” solution would have been to build a bridge crossing the river.

Crossing the river using a bridge

While this should seem like a no-brainer to us, then there was a first bridge at some point.

The “funny” part is that this could be achieved at 2/3 the cost of the final solution as the docks are going halfway into the river.

Another “funny” part is that most likely then the developers analyzing the flow and suggesting the launch site to be he middle of the river, would probably have build a tiny bridge crossing the entire river from which they could launch probes. Quite possibly they would have build another bridge to measure where the probes went.

The bridge does have a drawback, which the dock solution doesn’t have: Tall things can pass through the river without tearing apart the solution.

To keep with this parallel. A new developer company – a set of bridge builders – shows up telling the customer that there is a better way to do things, namely a bridge. But the customer is quite happy with his solution. It might not be the best, but it works, and the cost/benefit of the current solution is still in the red.

Summary

So – what to take away from this story? First off, this is an extreme simplification of the issues in software development. It would probably have been more correct if the customer had been blind, as most software customers don’t understand the code making up the solution. But then some of the developers would have had to be blind, deaf, mute, and forgetful.

The customer is most likely the best candidate for an expert in the domain for which the developers are building a solution. On the other hand, then developers should be experts in the solution cracking and development domains.

Animosity and trying to keep up appearances are detrimental to the solution at hand. It is quite easy for the customer to think that the developers are stupid when they don’t know what he is trying to communicate. On the other hand, then the developers quite easily find themselves on a death-march project where it seems the customer keeps wanting more features for free.

The unsaid, not written down expected parts of solutions are always there – they may be given for those knowledgeable in the domain, but probably aren’t for others.

Anchoring terms in the conscience of anyone is dangerous if you want something completely different.

Communication is difficult

Comments are closed.