The story of four digging devices

There once was a digger device architect. This is the story about the first four digging device engagements he worked in.

Engagement #1 - Early success

A customer consulted with the architect and asked:

Could you build me a digging device, please?

The architect responded with the question:

Alright, what functions should this digging device perform?

The customer responded:

Why, that’s a silly question! It should dig, of course. That is my only functional requirement.

Awesome! the architect thought, I have seen a device that should do just that.

The architect goes into his shop and builds a digging device using the first digging device architecture they ever learned, and indeed the only one they had even heard of at this point, the shovel architecture.

The architect presented it proudly to the customer:

Here you go! Here is your digging device.

The customer took the digging device home. The customer successfully used his shovel to dig some holes for new plants in his garden at home.

Two weeks later, the customer reported back to the architect:

Wow! That was an amazing digging device. Thank you so much! I’ll tell all my friends about your business.

Engagement #2 - A first failure

Fairly soon, the architect got a second customer.

The second customer consulted with the architect and asked:

Could you build me a digging device, please?

The architect responded with the question:

Alright, what functions should this digging device perform?

The customer responded:

Why, that’s a silly question! It should dig, of course. That is my only functional requirement.

The architect, having built things that successfully dug before, immediately reached for the tried and true shovel architecture.

The architect presented it proudly to the customer:

Here you go! Here is your digging device.

The customer took the digging device back to his company. The customer, with high expectations, attempted to use this digging device to excavate the foundation for the skyscraper they had been contracted to build. After a day of frustration, he called the architect:

Come out here quickly! I am trying to use this digging device, which is not digging nearly as fast as I would like.

The architect visited the job site and tried all sorts of gimmicks and hacks to get the digging device to scale appropriately to the task at hand.

Ultimately though, the digging device failed; the customer asked for a return of the money they had spent and left a horrible review for the architect!

The architect was very frustrated with this shovel architecture. It just didn’t scale well!

Engagement #3 - More problems

Despite the negative review, the architect soon had another customer.

The third customer consulted with the architect and asked:

Could you build me a digging device, please?

The architect responded with the question:

Alright, what functions should this digging device perform?

The customer responded:

Why, that’s a silly question! It should dig, of course. That is my only functional requirement.

Now… the architect had heard this request before. This time would be different, though. The architect would not rely on that silly old shovel architecture. The architect had been to a digging device architecture conference last month and had learned about two things: a fabulous new architecture called a bulldozer architecture and something called non-functional requirements.

The bulldozer architecture was amazing! It could dig massive holes in no time and was easily controllable by a trained driver. The driver wouldn’t even have to break a sweat if the architect built air conditioning into it! Technically speaking, the architecture was much more challenging to construct than the shovel architecture, but the architect was excited by the challenge. The architect also knew that it took time to build things right.

These non-functional requirements made a lot of sense. The architect realized that the customer had only specified a feature digging and had not specified any non-functional requirements like:

  • Scalability - How would this device work when digging large holes?
  • Reliability - How many holes could this dig before it was repaired?
  • Performance - How quickly could the digging device dig the holes?

Thankfully, the bulldozer architecture made sure all these non-functional requirements were covered perfectly. The architect had heard from the presenters at the conference how well the bulldozer had worked for them and how they were using it to excavate skyscraper foundations in no time!

Armed with all this excellent information, the architect happily began constructing his first bulldozer.

Six months later, when the architect was halfway done, the customer came back and asked:

Are you almost done?! This has been a very long time waiting for a digging device.

The architect responded:

I’m sorry for the wait. It takes time to build things right. It will be another six months, but you are going to be so happy with this digging device when I am done. It will be worth the wait.

Six months later, the architect was finally finished! It was the most beautiful thing the architect had ever seen.

The architect presented it proudly to the customer:

Here you go! Here is your digging device.

The customer’s eyes nearly popped out of their sockets when he saw the bill. He paid the architect’s bill and paid for a tow company to bring the bulldozer home. The customer struggled for the morning on how to get the bulldozer into his backyard and eventually called up the architect and said:

The digging device you made me isn’t working! I can’t even get it into my backyard to plant the carrots. I want my money back!

The architect was very frustrated by this experience. The architect suddenly remembered the good old days when he could build a digging device in a couple of days and remembered how happy his first customer had been. Where had things gone wrong?

The architect decided to walk in the park to think things over.

A helpful encounter

As the architect was walking the sidewalk circuit around the local park. The architect noticed a man with a greying beard and loud, Hawaiian-esque business suit sitting on a bench feeding the birds. The architect was confused by the suit. The architect felt strangely compelled to tell this person about the digging device architecture problem.

The architect sat down at the bench and asked:

Do you know anything about digging device architecture?

The man responded:

Funny, you should ask; I’ve been doing it for years.

Excitedly, the architect explained to the strange-suited man the problems with the shovel architecture and the problems with the bulldozer architecture.

The man responded:

You need to get your non-functional requirements from the customer. Only after you have the non-functional requirements should you choose an architecture.

The architect thought this sounded good but had another question:

What if the customer can’t answer questions about their non-functional requirements? My customers are not digger device architects after all, and aren’t necessarily familiar with all our industry terminology.

The man responded:

You must focus on something called quality attributes first. Have the customer stack-rank the quality attributes in order of importance and be prepared with specific real-life scenarios to help explain what the quality attributes mean to your customer.

Your 1st problem with the shovel for the excavator was that you had a customer whose quality attributes were prioritized as:

  • Scalability
  • Performance
  • Reliability
  • Maneuverability

Your 2nd problem with giving the bulldozer to the home gardener was that you had a customer whose quality attributes were prioritized as:

  • Maneuverability
  • Precision
  • Ease-of-use

Another thing to help you identify the correct architecture is to spend the time to fully understand what your customer will be using the device for and what business risks they are hoping that the digging device will solve for them.

The light bulb went off in the architect’s head. This was genius! He furiously thanked the strange man who formally introduced himself as Vim JanderMey. The architect ran home, thinking the man’s name was just as odd as his suit and prepared for his next customer.

Engagement #4 - Success

It wasn’t too long after that conversation that the architect had another customer.

The third customer consulted with the architect and asked:

Could you build me a digging device, please?

The architect responded with the question:

Alright, what functions should this digging device perform?

The customer responded:

Why, that’s a silly question! It should dig, of course. That is my only functional requirement.

The architect now knew this wasn’t a good time to choose architecture. The architect had a much longer conversation with this customer than he had with his previous customers and discovered he had a customer wanting to plant some carrots in his garden at home.

The architect, smiling to himself and now confident in his decision, reached for the architecture that wouldn’t scale well and had horrible performance.

The architect built the customer a shovel.

Read More

ThingWorx local development environment with Docker - Part 1 Reading time ~3 minutes

[ThingWorx](https://www.ptc.com/en/products/thingworx) is a platform for developing "Industrial IoT solutions". They've......

Estimate, target, plan and commit Reading time ~1 minute

I've started into "[Software Estimation: Demystifying the Black Art](https://www.amazon.com/Software-Estimation-Demystifying-Developer-Practices/dp/0735605351)" by......

How to run multiple versions of React side-by-side using Single Spa Reading time ~2 minutes

This seems like it should be easy right? [Single-spa](https://single-spa.js.org/) is......