The art of balancing buzzwords with reality
‘Agile development’ are two words that can strike two polarizing feelings in the hearts of developers. In one corner, it’s a sinking feeling of hell no’s with a bubbling sense of internal panic. In the other corner, a group of rogue and new-age devs jump with excitement and glee.
From experience, it’s hard to find a dev that’s in-between.
Why is there so much hate and love for agile? Especially in the software development scene?
In part, it’s because of how agile is executed — and how well the code itself is set up for agile development processes and thinking.
Legacy monoliths are not made for agile
The thing with legacy monoliths is that there is a lot of history involved in their creation. Upper management may be secretly emotionally attached to it. Users may feel like everything is fine and resist change.
The way legacy systems are built may be deeply entrenched in old patterns and processes that no longer make sense. For all we know, the packages haven’t been updated in over half a decade.
From a developer’s perspective, everything is a ticking timebomb — from feature extensions to security vulnerabilities. The technical code debt has spent whatever initial currency it came with.
For non-devs, they see software as an immutable object — that once it’s made, it’s a solid piece of digital structure that can just be extended. Sort of like adding features to a house. But you can’t exactly add a veranda and solar panels if the house itself isn’t capable of handling it.
Agile complicate things because it is often sold to management as the holy grail of speed — that by going agile, all your time-to-market issues will be solved and that your competitive edge will be sharpened x10.
But that’s not how things work. The idea of agile and the implementation of agile are two very different things.
How? And why?
Because ideas do not take into account the nuanced reality of most businesses — that they’re not young and unhindered saplings with a business to run. You can’t just wipe everything clean and come with a completely brand new exact replica.
Even without inspecting further, it’s already starting to hit on levels of oxymoronic.
Breaking up the app with a sledgehammer
But sometimes, things have to change and as software developers, it is our job to figure out how to balance the idea of agile with reality.
So how exactly do you break up an app with a code sledgehammer without breaking everything?
The answer is: go in with a renovator mentality.
The renovator mentality
When we think agile, we think greenfield projects. When we’re faced with an existing structure that needs to be agile, we need to think in terms of code renovations.
So how exactly do you apply a renovator mentality to your code?
- Draft a general architectural plan of what you currently have and section the app into distinct parts.
- Ring-fence it with yellow hazard tape and make sure everyone on the team knows where the boundaries start and end.
- Draw up what each ‘room’ is going to look like. Just the general gist.
- Build your new modules, components, APIs, and everything else you need out in the yard.
- Start with one ‘room’ at a time so your users still have other places to live in your hypothetical software/code house.
- Bridge and adapter pattern your code while you’re working on the rewiring.
- Migrate things into your room. Clear out the debris. Vacuum up the legacies. Ruthlessly throw out what you don’t need. Add new features and improvements while you’re there.
- Rinse and repeat with the other rooms.
During this renovation phase, you can add modularity, cohesion, and all the other key ideas of good code.
Communication and post-it notes
When it comes to agile, everything tends to be in a state of fuzziness. Stand-ups can get boring pretty fast, especially if it's the same thing reported every day.
To keep everyone sane and on the same page, the team needs to be aware of what everyone is doing and who depends on who. This is the minimum requirement.
It doesn’t matter how you do it — through Kanban boards, checklists, Trello, Asana, Jira, and whatever brand of project management you’re using. What matters is that everyone knows.
One of the best projects I worked on was managed through Google Sheets that everyone on the team had access to. There was one guy controlling everything and he disseminated the information to the relevant people in the right format.
What did this look like?
- the boss had access to the sheet and got a weekly rundown on the progress.
- the devs had access and could update their progress.
- the sub-teams knew who depended on who to deliver or else there would be a bottleneck.
- bottlenecks are monitored daily to make sure that they didn’t slow down the workflow. If a dev got stuck, other devs may be re-allocated to help out.
- no one was allowed to become emotionally attached to their code and moved around the different ‘renovation rooms’ consistently.
What did the result look like?
- new features shipped every two weeks between teams. This was alternating and on rotation, so it looked like we were shipping a couple of features a week.
Final thoughts: it’s all about the team
Agile is about managing the team workflow as much as it is about getting the code in the right state for it.
You can’t implement agile coding in the same linear and single tasked methods required by monolithic and water methods. To properly implement agile in code, the team needs to be comfortable with working in small and modular chunks rather than large sets of features that will be eventually released in a few months, if not a year’s time.
Agile is about speed — but it doesn’t mean that robustness needs to be sacrificed. When it comes to keeping your code intact, you need to accept that there will be a messy phase. It’s unavoidable — especially if you’re going in with a renovator’s mentality.
