Structural Imbalance in Software Systems

We come across many instances in the software industry where “code-lumps” get deployed as software services/products with beautiful User Interface included to cover up all the ugliness underneath. The design document too looks fancy with usages of software patterns & practices neatly listed in the glossary.

After all this marketing stunt by the business, these modules are observed to have a rather short life-span. Before long, there are in-numerous critical issues being raised triggering its quick death. Sounds like a typical Start-Up story ?

In the majority of these cases, product owners were forced into releasing these “code-lumps” that just weren’t ready, while in other cases the anointed “architect” had no clues to why the “code-lumps” existed and why the patterns were chosen. At the first look, the software does appear to function as desired with all the components “working” great during those first pitch demos.

How could these be avoided in the first place ?

Just like in typical broken unfinished buildings we see across the road, structural imbalance refers to modules that don’t make sense/fit together. Individually, these components / patterns sound perfect for the problem in hand, but they just don’t sync/gel enough well; structurally.

Right from a birds-eye/logical view to the drilled-down/technical view, it’s critical that a dedicated small team of senior engineers reach consensus on the many choices being made every day, with the “Architect” calling the shots. Engineers collectively must be able to vote for the changes regularly even if the voting process remains informal.

Only if the team of software had identified the applicable Non-Functional-Requirements (NFRs) and defined them in detail early. Architect and the team of software designers should have drilled down into the modules for a detailed design before coding. The design should have considered all the listed NFRs and clearly documented how the modules together solves the problem.

In an Extreme Programming (XP) fashion, the above cycle of design/code could continue for the same module in the upcoming sprints until the Architect says its done. Strongly believe that the first set of functional code you write should always be treated as the draft version only.

Though check-ins could be allowed from all engineers, none of it should reach the release pipeline until all the “code-lumps” were removed during the refinement/iteration. Architects & designers must agree that the code comply towards the agreed NFRs before promoting the code up its life-cycle.

Working closely with the architects, the product owner should now be more confident in communicating with the stakeholders that the product is ready.

Do look forward to the related article on “Why all software engineers must NOT automatically become an ‘Architect’ “ ; which in addition to looking at skill & interest, also touches upon the essential philosophical outlook required by any upcoming architect.

Software engineer at heart, with varied interests.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store