Why reusable code is a myth

„Synergy“ is the term that gets them. Every time. Virtually every business owner or executive I have worked with got somewhat hooked on the idea of reusable software, creating module-like chunks of code that can be rearranged to make the creation of the next big application a breeze. Almost like building a Lego house, easy as that.

Managers love to prioritize projects that claim to make everything reusable. And while there are some valid benefits of reusable code, there are also limits. Let’s have a look at an example of how reusability plays out in the real world.

Building software is nothing like building Lego. It’s the end product and what it does for the user that counts.
(Photo by Karolina Grabowska from Pexels)

So, it is 11.53 a.m., I’m conferring with my development team via MS Teams (as is the norm these days). I’m explaining why our users need a slightly different layout for their data management than in the sister applications of our app suite.

„We have to do it all the same in every layout“, my team claims.

„Why?“, I ask.

„Because our goal is a unified approach for every bit of software we build, to make it lean and efficient“, a designer explains. „Our users expect to experience exactly the same behaviour everywhere.“

I’m still not convinced. „Will that really improve usability in this context?“, I ask.

„The company expects us to build everything only once. You see, it’s like in MS Office: Users want to have the same print dialog in Word and Excel!“, another designer claims.

At this point, it dawned on me what we were really discussing here.

No, the user does not want to have the same print dialog in Word and Excel. Not at all!

Now, if you describe the print dialog as being the „same“ by looking at the colors of the Background and the style of the buttons, then this statement would be true.

But if you look at the designs needed for a Word and Excel print dialog, then those are fundamentally different. Because design is how something works, not how it looks.

The majority of the work of a software team should go into satisfying the underlying needs of the customer.

Let us take a look at the MS Word vs. Excel example:

Word vs. Excel print dialog: The buttons and colors are common, reusable elements, but at the core, the dialogs are very different.

Word is a document authoring tool. The workflow begins with selecting the desired paper size. The product created by the user is organized in pages, designed in the way it can later be printed. All pages have the same size. Overflow will be cut off when printing.

In Word, there are needs such as:

  • „Print an exact rendering of my document“,
  • „Print all pages with remarks made by colleagues“ or
  • „Print a preview of my entire document“.

An Excel document, however, is usually not created with paper size in mind. It is meant to calculate numbers. Work is organized in sheets, but data may grow over time, causing the sheet to spread in width and height. The size of different spreadsheets in the same workbook will usually vary. The print function tries to squeeze all content on paper, no cutoff.

In Excel, there are needs such as:

  • „Print all data so that it is well legible“,
  • „Print just one spreadsheet“ or
  • „Print all data so that it is still legible, but consuming as little paper as possible“.

To create a satisfying print dialog, I must design my solution in regards to the user needs, ask myself again and again whether the user goals can be achieved with my solution, even if it feels uncomfortable to never have a perfect answer. There is also no „design manual“ which will just give the answers.

So, is reusability of code possible?

Yes, reusability of code is absolutely possible. Using the same buttons, colors and borders in those two example dialogs is desirable. Software teams should not build the same solutions for sanitizing inputs, creating ribbons or buttons or previewing documents again and again.

However, a common design is mostly a hygiene factor. The real design effort will lie in the core of the dialog, not in the outer frame. The paradigm of reusability might lead your developers to believe that they are done with their work when they have created a reusable outer frame. However, the real work only starts here. The use of common elements must end wherever the user experience cannot be perfectly achieved with standard elements.