How a Lego challenge helps provide a new lens on OSS

Did you love to play with Lego as a kid? I’m going to go out on a limb and assume that since you’re reading a blog about OSS, then you’re probably leaning towards the technical end of the spectrum… and therefore probably did play with Lego. Perhaps you even crossed into Lego Technic that allows even more technical builds?

Before I take you on the journey of today’s story, I’d like you to cast your mind back to when you last played with Lego, regardless of whether that was today, last week, last month, last year, last decade or even last century!

Did you build according to the step-by-step guide that came with the kit or did you just take pieces and start experimenting?

I recently stumbled on the video below, which took me back but also took me forward. It combined a past (playing with Lego) to present and future (playing with OSS). There are a few different analogies between the two (yes, I’ve already written a few articles comparing OSS and Lego, including this one), but today I’ll take a different spin (aka turning circle).

Watch the short video and see whether you can predict where the story will go next.

Okay. What did you come up with?

It could talk about technical effectiveness and fine-tuning the engineering of the Lego / OSS. There’s an element of truth to that of course, and it’s kind of closely linked, but I instead was thinking about UI/UX/CX optimisation.

The first iteration saw a really neat piece of engineering that fit the design brief – to build a remote-controlled vehicle made of Lego that is able to turn in a circle. Kudos to the builder. I’d be proud of that build. But for the team at the Brick Experiment Channel, that’s not enough.

The initial design produced a wide arc of 88cm. Impressive, but apparently not impressive enough.

We then see extra iterations of the design that first brings the diameter down to 70cm, then 45, then 32, then 31, then 30. We seem to be approaching an asymptote here.

But then a totally novel approach is used at the end of the video, which brings it down to 18cm. [That’s nearing 80% reduction…. Percentage Decrease = [(88 – 18) / 88] x 100 =  79.55% ]

So let’s look at this through a couple of different lenses:

1. If you’re a developer, your first attempt was brilliant. It passed the design brief test requirements. You still have a long backlog of other requirements to build and have to move straight onto the next one as soon as tests are passed. You’ve built it to pass a “one-time use” test in a lab.  [Some devs are purists and don’t stop until they’ve optimised, but usually time doesn’t permit them to do so]
2. If you’re a product user, you will perform this task not just once, but often hundreds / thousands of times a day. An 80% reduction represents a massive efficiency improvement. This is why a CX designer is such an important part of an OSS development team. They’re considering the look, feel and efficiency of the tools being created for users / customers. They’re tasked with looking at the tools in real-world conditions, seeking real-world business improvements

If you’re a product evaluator (part of a bid team choosing between different products) or a product manager (choosing whether to release as-is) or an end-user (choosing whether to approve the User Acceptance Test [UAT]) then you have to decide whether to evaluate for #1 “one-time use” or #2 “use at scale.” It’s up to you to decide will 88cm suffice or will 18cm make a fundamental shift in business outcomes. Is the significant extra effort required to run multiple experiments to achieve the massive efficiency gains worth it?

This is a case-by-case decision. The problem though is that most people in the world of OSS simply don’t look past lens #1. They think functionality, not effectiveness.

We can bring it back to the long-tail diagram again:

• Is this feature out at the far right of the blue arrow and doesn’t really impact business outcomes (ie the height of the Y-axis)?
• Is this feature so important (in the red box) that it moves the business needle and is justify optimising from 88cm down to 30cm
• Or is it so market-shifting that it’s worth engineering in such novel ways (the green arrow) that a reduction from 30cm down to 18cm is totally justified?
• The further left this feature is, the more important it is to also use lens #2