Two Weeks?!! Embracing Architecture within Agile

Two weeks -- the duration of most Agile sprints in companies today. It’s also the length of time that each reno phase was promised to Walter Fielding. Walter was the character that Tom Hanks played in the decades-old comedy The Money Pit. Trying to maintain sanity in their lives and their relationship, he and his partner Anna (Shelley Long) waded through the project from hell.

"Two weeks?!!" Walter screamed in exasperation. Bludgeoned into reality, he found that “two weeks” had as much credibility as did “90-day implementations” promised to CEOs by enterprise software sellers. But that industry-wide frustration (festering, long lead times) begot innovation, and Agile came to revolutionize development. Welcomed as a breath of fresh air to the laborious “wait and see” of waterfall, Agile’s software philosophy delivered. We were now able to witness progress with regularity.

But progress atop a murky, disheveled basement is not progress at all.

Falling Staircases and Crumbling Code

Your software product evolution is not as zany as Walter’s property experience (well, better not be) but his falling staircases, crumbling chimneys, and decrepit wiring are metaphorical to your own programming. Bugs, small and large, can be corrected – from minor syntax issues to fatal errors in handshaking.

They are reparable.

But reparation isn’t a “two week” fix unless the house infrastructure or the software design pattern is visible and explicable.

When your home contractor installs electrical wiring along the housing perimeter, is it ever left to you in a blueprint? Does the project lead ever discuss the living room GFI outlets in terms of their pathways to the breaker box? I doubt it. Actually, if I’m wrong then I’d love to have your contractor’s name.

As leader of software development, institute and embrace architecture in action. Demand that your software architecture can be illustrated before, during, and after compiling, and that developers can articulate how their development aligns to the design philosophy.

You are teaching a way of thinking, a mindset of quality, scalability, and speedy delivery.

The best code is easily traceable and understandable.

Architectures on the Shelf

In another essay I spoke about the architect as a people person who ties together the vision through customer collaboration. The architect is also the blueprint maker and the standards tracer, whose foundation supports all coding layers within.

We are in the Agile world, whose philosophy is replete with collaboration, team-oriented interactions. So it goes without saying again -- the architect is that “people person.”

Thinking of the architecture of the house, we sense its foundation. Everything built, tacked on, expanded, fixed, refurbished is dependent on that foundation. It’s layered and is devised according to the building type being created. This is the same with your development architecture and associated architectural patterns. Like carpenters, plumbers and roofers, there are standards by which they build their product. And for the software engineer, there are standards for a variety of design dilemmas.

However, my point isn’t to list the dozen or so most common design patterns. I encourage something more fundamental, simpler, and often ignored – citing the software architecture during the presentation of your “two-weeks!” deliverable.

Your engineers know the nuances of C++. They already know how to retrieve the expansive libraries in Python. Those are table stakes for the dev team.

But too often they are not expected to articulate external data paths used in their scripts. Too often they are not expected to explain their class blocks and how they correspond to your software architecture. Are they easily traceable and understandable? The code set is not some ancient riddle whose mystery awaits deciphering by some future excavator among the ruins.

Invest now in architecture and avoid having to invest later in archaeologists.

Pit Stops Along the Way

One of the marvelous concepts within Agile implementations is the pit stop, the antidote to money pits. Making real the idea of team-oriented communication and collaboration, technical stakeholders validate your design architecture and adherence to scalability. Don’t omit the sprint retrospective, but know how to lead it.

The opportunity for all development team members to share improvement ideas is the underpinning of the Agile philosophy. In the retrospective, inefficiencies should be articulated by all team members. Capture the stumbles in the story development; identify the misunderstandings between product manager and QA.

But most importantly, please elevate the conversation again toward the architectural blueprint.

In a development snafu, I once worked with a team who attempted to pinpoint a data-handling error, seemingly simple but strikingly elusive. Of all things, the issue came down to a versioning problem with the middleware. Now before we start to discuss change control, architecture 101, and basic IT housekeeping, as well as wrongheaded “how could anyone be so dumb?” commentary, there were plenty of reasons why this was a hard nut to crack.

But my disappointment was about something else (more significant) during the troubleshooting SWAT effort:

The software engineer used the whiteboard to draft the multi-tiered architecture and the flow of the consumed data.

I asked if we could instead, please, present the official architecture on the 50-inch display for all to see. I respectfully asked for the standard, formally designed, illustrated, explicit, computer-graphically-generated architectural baseline.

Crickets.

Because there was none.

It was in everybody’s head.

Yet these folks were amazing programmers! That is a sincere and genuine observation. I wish I beheld a tenth of their programming athleticism. But the fundamentals in building that software house were disregarded; there was a misinterpreted value of “fast-paced.” Don’t allow those kinds of ill-advised shortcuts.

That time was yet another experience in my career where I heard the “We already know that” when I stated we should socialize and mandate foundational blueprints. We might have “already known that” but we sure as hell didn’t do it.

“A Consultant’s Dream”

Without thought of maintenance nor scalability, many old houses delivered you water. As consumer, like The Money Pit’s Anna, you only cared that the water came from the faucet. You didn’t care from where the pipe traveled or how the plumber deployed the hot water heater. In some of these houses (sadly I know from experience), the pipes looked like the famous “Three Stooges” scene, when Curly moronically attempted to cap an open pipe with other open pipes, trapping him in a cage of copper.

Your software flow requires clean code and understandable code. It shouldn’t be hard for a senior software engineer to track the pipes -- the software logic -- in your program. Everything is dependent on a shared understanding of your major classes and tiers.

And shared means explicit and visible and documented.

If you are a Software Principal or Senior Developer you are already expected to have impeccable language fluency and clean code. Say you leave the firm and embark on other adventures, or start your own company. Are you leaving behind not just commented code but, rather, transparent schematics that can be readily understood? Are you leaving behind code that at least is rationally (and visibly) aligned to the architecture?

During a presentation for an enterprise implementation on Financial analytics, a delivery team was illustrating the data flow from external entities, and attempted to explain how this data would be incredibly useful to all stakeholders. It made Curly’s plumbing look like an architectural masterpiece. The dismayed CEO, staring at a mesh of crisscrossed lines and all inconsistent CI’s (configuration items) blurted out, “How can you follow this?! You know what this is? It’s a consultant’s dream!”

He was not being complimentary.

Worse, there was no reconciliation of the data flow to any software architectural blueprint.

How much of your code set is independent of the software architecture? None of it.

The Way Forward

Top CTOs will challenge themselves and their teams, and their partners and suppliers, to reconcile any design to the architecture.

A solid, well communicated, shared architecture is the key to creating, repairing, scaling, and adapting.

Human failings might trigger rework; the hazards of unaccounted risks contribute to mistakes; communication shortcuts provoke untold stress. We are not perfect. But the shared frame of reference, the commitment to architectural alignment, can rescue any project, and promise a happier future.

As The Money Pit neared its conclusion, the perceptively sensitive project manager (also named Curly, played by the late, terrific character actor Philip Bosco) showed the empathy and the wisdom of the best Scrum Master.

Ever positive, he looked around again at the renovated home, inspiring the exhausted homeowners to rediscover their personal way forward:

“This wasn't an easy one,“ he sighed, “but the foundation was good, I'll say that. And if that's okay, then everything else can be fixed.”