The 3 biases of Software Development - Number 3: Modularity

Once we understand that the whole is a sum of its parts, we tend to focus on completing individual parts. But do we know everything about these parts?

What is the Modularity Bias?

So far we talked about Stratification and Chronology, and we moved from the “Mario Bros approach” where we’ll always develop level 1-1 before level 1-2 to the “Megaman approach”, where we have more flexibility and can develop our modules in any order.

Did you notice I just used the word “modules”? That’s the problem we are about to tackle in this post: if we consider that a given part of our software is done, that means that part isn’t flexible anymore. If Stratification is about layers and Chronology about sequence, Modularity is about the boxes we put our code in - and sometimes, those boxes become prisons.

Understanding the Modularity Bias

When you beat a boss in Megaman, you gain access to a new weapon. A complete and functional weapon, but also a weapon that will never change. In software development however, if we try to finish a part of our software and state that we will never be touching that area of the code again… Well, let’s say it just doesn’t work like that. Sorry, Megaman.

So, which game could we use as an analogy on how to improve the MegaMan approach? Planescape: Torment! (Or any other Classic RPG for that matter).

In Planescape, every time you accumulate enough experience you can upgrade your character by adding points to his Strength, Wisdom, Intelligence, Dexterity, Charisma and Constitution. You gradually improve these stats, but you never complete any of them: you can always add more points to a given stat during your next “level-up cycle”.

Think about Megaman: when you start to play it, you can chose one of 8 stages to play. But every time you beat a stage you have less options on what to play next, up to a point where you’ll have no choice because you’ve beaten 7 stages and there’s just one remaining. You start flexible, but you lose that flexibility along the way.

In Planescape we don’t acquire new “modules” to our character. We improve their characteristics according to our needs, and our needs change as we advance through the game.

Enough about games. Let’s talk about software!

Well, technically these games are also software, but I get the point. :)

Let’s go back to the example we had in our last article: a Hangman game. While breaking the Chronology bias we decided to postpone the development of a “Dictionary Module” by just implementing a function that always return the same word: ELEPHANT.

By doing that we were able to focus on more interesting things such as the game mechanism without spending much time with the dictionary. If we think about our next step, one could say that we could implement the actual dictionary next and give our Megaman a new weapon. But by doing so we would hinder our ability do adapt to customer feedback as we reduce the amount of possibilities we could develop in the future.

unless we're willing to discard some of our work and redo it according to the feedback we receive, of course. It’s actually not a crime to do that, but this kind of waste can be drastically minimized if we instead of implementing the Dictionary we ask ourselves the following question:

How could we upgrade our Dictionary by a single point, like in that game Planescape?

Maybe we could create a list of words and pick a random word each time the function get_word is called. This is simple, could be done in a couple minutes and would greatly improve the game.

Notice that we didn’t implement the API integration initially shown on our last post, but we can do that in the future if we think it’s a good idea. Or not.

Benefits of breaking the Modularity Bias

Let’s say you’re developing that Hangman game using the MegaMan approach and you’re part of a Scrum Team. During the Sprint Review you show your customer what you build and you ask for feedback:

So customer, we finished the Interface and the Dictionary. What do you think we should do next?

Well, what’s the point of asking feedback here? If the customer asks us to change something related to the Dictionary or the Interface, we’ll waste a lot of the work we’ve done, and if they limit their feedback to the remaining areas of the software we aren’t benefiting from the whole Scrum thing.

Now, imagine you with the Planescape approach. You improved our Dictionary and our Interface, but instead of finishing them we used the remaining time to come up with a simple Scoring System:

In this scenario, you would be able to ask your customer a different question during the Sprint Review, such as:

So customer, we based in what you saw, where should we allocate our next 3 upgrade points? And what are we trying to achieve by doing that?

Notice the difference? The customer has keeps their options and even if they ask us to improve something we already worked upon, we don’t throw work away. At least not that much.

Also, maybe we won’t have to implement that API integration right now as the customer decides to enhance the Scoring System and implement Hint Mechanism. Meanwhile we won’t have to worry about how many API calls we’re making during the development process, create mocks and stubs to test our game or create a configuration option to make our game deployable to both staging and production server.

The waste we minimize isn’t just related to customer feedback, but to the entire development process.

Maybe we’ll never use that API. In fact, while developing this Hangman Game for a Certified Scrum Developer course I was teaching, my wife played the game and came up with an interesting idea: since the course was about Scrum, we should use words from the Scrum Guide, and by doing that we ended up with a static dictionary that had 802 different words. All related to the same subject: Scrum.

How can we avoid that Modularity Bias?

I’ll be direct with this one: Use the Hamburger Method. I know I could ellaborate more, but in my experience there’s no better way to tackle that bias as team than using that method. You can read more about that method here: https://gojko.net/2012/01/23/splitting-user-stories-the-hamburger-method/.

It’s also a great way to deal with dependencies, which often pushes us towards the Modularity Bias.

There’s still one more thing we need to address here: The Planescape: Torment approach isn’t even our final destination. That’s because in that great game we’ll always have the same 6 stats to upgrade throughout the entire game. And if you truly break this Modularity Bias, you’ll be able to discover new areas to explore as you move forward.

This post is too long, could you summarize please?

Yep! Before declaring any part of your software 'complete', remember: even the most powerful RPG character can still level up.