Dear fellow Developers,

over the last decade I have been working as an iOS Developer in many different teams. While basically all teams described themselves as being agile, it never felt so. For most “agile” had become a meaningless word, just describing a marketing term for a certification industry.

But “agile” has meaning. Agility is the ability to respond to change rapidly. This actually means that all software projects start out agile, but we’ve all witnessed this ability decaying. But why does this decay happen? Why did management send all of you to expensive workshops, so that you are certifiable agile and still: It doesn’t feel agile. Your development speed is only accelerating in decreasing, your team’s estimates are so off that it might be more useful to come up with random story points. Who is to blame? or: What is to blame? Maybe it is your architecture, or the lack of it, or the multitude of half backed architectural ideas in one codebase. I met a team, which hadn’t been able to release a new version of their iOS app in response to breaking changes due to an OS update — even roughly a year after the initial developer preview and 10 months after the public release. Yet the team would still describe them as agile, as they were employing certain techniques usually tagged “agile”. But wearing Air Jordans doesn’t transform you into Air Jordan. Being able to buy a brush doesn’t make you Michelangelo. And if you can’t react to changed requirements rapidly, you aren’t agile — no matter the certification or tooling you use. So how can architecture help a team to become agile?

Introducing: Agile Architecture

I call an architecture designed to support agile workflows “Agile Architecture”. Such an architecture should support the developer by

• not getting in the way when using agile tools like TDD
• being easily used in CI/CD workflows
• letting the team keep the same development speed over the complete lifecycle of the project
• enabling more agility in inter-team processes, such as an agile UX design process

But most of all it should directly help you with your agile workflow. Like:

• easy testability leads to better testing
• better tests result in increased confidence
• predictable complexity leads to predictable estimates
• better estimates may reduce stress
• less stress -> higher perceived mental safety -> creativity -> performance -> higher speed -> …

I recently developed an Agile Architecture (working title: Core|UI) in Swift and started writing a book about this topic. If this sounds interesting to you and your team and you want to learn more about it: feel free to contact me.

«Being Agile» isn’t a marketing term — it is a strategic necessity

When I use the term “agile” I do not mean that you use a certain management system that labels itself agile. I mean it in the true sense of the word:

Being agile means: Having the ability to quickly respond to change.
In a highly competitive market this might determine who’s company will thrive — and who’s gonna die.

Changes might be needed and inflicted on you at any given time, like

• Changes in you business markets
(arrival of competitors, new devices)
• Changes due to strategic decisions by your company
(take-over, restructuring)
• Changes due to technological reasons
• Changes due to jurisdictional reasons
(new or changed laws)

Maintaining the ability for change at any given time is vital.

Core|UI Key Facts

Core|UI isn’t your next permutation of the letters M,V,P,R and I.

• Pattern-wise I would describe it as a Modularised Command Interpreter, in which the main module (AppCore) excepts commands coded as types (called Messages), representing it’s own DSL (Domain Specific Language). But also Features (Modules that communicate with the global message type) and UseCases (Modules that do contain the logic codes) follow the same pattern.
  In the different layers we use similar solutions — therefore I dare to call this code fractal.
• The UI is fully decoupled. This is — as we do know for half a century now — a requirement for a good architecture.
• Throughout the app Core|UI uses an unidirectional flow of data. This limits it complexity drastically.
• Compile-time messaging.
• The core of the app doesn’t change during runtime, reducing a huge field of possible null-pointer crashes.
• Test can be written in short and uniform ways.

In this article series I will also explore immutable state and unorthodox types for modularising your code.

Next…

This will be the first in a series of articles about Agile Architecture.

Part 1: UseCases

P.S.:

One thing, before you ask, as many do: I cannot answer your question if you can reuse portion or all of your existing codebase when rewriting your app in this or other architectures, as this exclusively depends on the spaghettiness of your code. If you and your team experience severe forms of non-agile development, yet you or your company resists a rewrite, you should consider if the Escalation of commitment pattern might be involved. Don’t be Kodak, don’t let sunk cost dictate your actions and inactions! If you find yourself in a hole, stop digging.