Tuesday, August 19, 2014

Thinking No Computers

The other day I happened to see a curious exchange in one of our businesses. The cashier swapped a torn, but carefully restored by taping it together again, Euro bill for a new one with the manager. Inquisitive, I asked the manager what he was planning to do with that Euro bill. "Once a month, I take all those ripped up or badly worn bills to the National Bank, and trade them for new ones. All you need is one piece of the bank note for them to give you a newly printed one."

While he started taking care of some other paper work, my mind started racing towards how the National Bank made this system work. I had noticed before that bank notes have an identifier on each side. I figured the National Bank probably stores the identifier of each note they trade, so people don't go ripping up bank notes with the intent of trading them twice. That seems easy enough, no?

Once the manager finished up his paperwork, I wanted to confirm my idea and asked if he knew how that system worked. How do they avoid people cheating? "It's really simple actually, you need to own more than 50% of a bill for it to be tradable."

Well... that's a much simpler solution. No need to store all the traded notes somewhere, you probably don't even need a computer at all.

I catch myself regularly defaulting to wanting to solve problems using computers. While taking a step back and thinking of how it would be done without, often exposes a simpler model. Sometimes you will realize that you don't need a computer at all. If not that, you get to steal from models that have been molded and battle tested for years.

Look at existing organizational structures and search for boundaries. You might find that aligning your software with existing boundaries makes the pieces of the puzzle fit. Learn how departments communicate; passing forms, by phone or by email. Maybe it shows that you need synchronous communication with strong consistency based on a formal protocol or that you might just get away with asynchronous communication with a less strong schema. Go through paper work, formulas, legislation, research papers, books and what not, and that hard to crack nut might become a bit softer. Look at where people are making decisions and how they are deciding on them, do you spot the patterns?

People have been solving problems for hundreds of years, tinkering with and perfecting models, way before computers were a commodity. Natural selection made sure only the strongest made it this far. Those solutions didn't stop working all of a sudden, nor should they be discarded as a whole. A great deal of them will likely survive another few hundred years, in one form or the other. 


  1. great post! Many of us fall into that trap once in a while I guess.

  2. Nicely said, great story!
    Isn't that the whole point of DDD - designing your computer system by looking at how different departments and people within one or many organization talk to each other, perform daily business tasks? Procedures, information flows, responsibilities, that kind of stuff.
    But from my limited experience of transferring business knowledge to an app, even it's the simple straightforward business procedure, finding all information needed for modeling it can be quite a challenging task.
    Back to the bank example: even this example it really simple and logical, whole banking business is probably just a bunch of simple scenarios, and that is what it makes it complex and hard!
    Think there's a few books about that also:)

  3. Great post! I have a tendency to do exactly what you've described here and similarly have to remind myself to think in other ways.

    It also reminds me of something I've been advising businesses that I talk to of late, which is that, when commissioning the automation of a business process, they should do their best to optimize whatever they're doing manually first. I've seen a lot of line of business type projects fall apart because the underlying process was kind of stupid. If you automate stupid, you just get faster stupid :)

  4. Hey Jef, great post again!

    Reminds me of a factory where once in a while, one of the boxes would contain no contents. Management made a budget available to investigate, but after spending 80% of that the engineers could still not find the cause of this problem. As a last resort, they installed a scale at the end of the assembly belt that would weigh all the boxes, and if one box had below average weight, the assembly belt would stop, an alarm would ring and an employee manually had to remove the empty box, then start the assembly line again.

    First day with the new system started, the bell rang about 50 times, a worker would remove the empty box and restart the assembly line. At the end of the day, 100% of all boxes were full ones.

    Second day with the new system, the bell hadn't rang until noon. Wondering if their new system was broken or had been deactivated, the team of engineers walked to the assembly line. There they found that the worker had placed a $25 fan that would blow against the belt. If a box was empty, the fan would blow it off the belt before it reached the weighing scale. "I got so sick of having to get off my seat", said the worker that brought the fan.

    Moral of the story: if all you have is a hammer, every problem resembles a nail ;-)

    Keep up the great posts


    1. Love this story, pretty sure it will stick too. Thanks!