Second Myth of Agile

Release little and often.

This is an important tenet in the manifesto, but by misinterpretation results in one of our biggest problems – the proliferation of software updates for users, and indeed other developers.

As developers, we need to understand the intention behind the statement.

• Release: What is released? To whom?
• Little: What is not enough, and what is too much?
• Often: Does time truly define what we need to release and when?

Dependencies

Dependencies are intended to make life easier for developers. Many platforms, like dotnet and iOS, allow developers to create and refine their applications more quickly than ever before.

For each release in a dependency, its dependents will also need to be updated. The updated dependents will also need to be released – not because they offer anything new, but because something underneath them changed. Therefore, frequent releases of a popular code library will force all its dependents to update frequently without necessarily adding any value for the user. Worse, in extreme (but common) situations, today’s popular code library will tomorrow become deprecated, unsupported or superseded.

Therefore, the complexity encapsulated by dependencies might be attractive to impatient developers. However, the effort saved by using a third-party dependency is subsequently transferred to managing that dependency. The transfer of complexity down the chain is like “value added tax” on the end user. All carry the cost of a change, whether they wanted it or not.

Balance the benefits of dependencies against their sustainability.

Agile Helpie

Bloat and Plague

Since the advent of the smart phone, I’ve been watching the updates for certain apps with interest. As an example, the Facebook app for iOS circa 2015 was about 90 MB in size. At the time of writing, this app is now over 280 MB in size. Every two weeks, without fail, Facebook release ever growing versions of their app.

Now, in 2020, it is large and slow. It is crammed with notifications, complicated controls and legal disclaimers. All for what is little more than a glorified bulletin board. Just how many “new features” can we add to this app? How many bugs are introduced for each iteration? What proportion of end users commissioned the changes? What is the urgency?

As engineers, we must be wary of over-engineering. As Agile developers, we are encouraged to embrace change.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Agile Manifesto

Agile encourages us to embrace change, but not to squeeze it to death.

Value is often more important than time.

Agile Helpie

Modern development tools make it (relatively) easy to build, test and release new revisions of software. In fact, it is notionally possible for there to be no human interaction between entering code and the updated software appearing on a customer’s smart phone. Fantastic though this capability is, does it really determine what is published and when?

Like with so much in life, with power comes responsibility.

Just because we can release software every two weeks, it doesn’t mean we should.

Agile Helpie

A focus group may endorse a new feature conceived by a clever product owner. Using the power of modern platforms, frameworks, automated testing and continuous integration, a small team of developers realise the vision of the product owner quickly. The new feature appears on users’ smart phones within a couple of weeks. As if brushing a fly from buzzing around their faces, millions of users accept the update. This minor irritation delays their use of the app (again), but it is apparently essential to “enrich our user experience”. The app crashes. Two weeks until the next release.

So what’s your point?

We need change like the police need criminals – change justifies our existence as developers. But welcoming change is very different to obsessing about it.

In addition to giving change a big hug, we also favour the art of simplicity. An over-developed app introduces more opportunities for bugs, more submodules to manage and maintain, more potential conflicts, and more impact on the end users.

A good solution solves a problem well. It doesn’t need to answer questions nobody asked. Similarly, a good design (i.e. the solution) balances form, function and the performance of each.

A beautiful user interface that is unresponsive or unnavigable is not a good user interface. An application festooned with features is powerful but hard to navigate and use.

An application that concentrates a large amount of complexity attracts bugs like flies to the proverbial poo.

• If we release little and often because of bugs, then we are just bad developers.
• If we release little and often because we have an endless supply of features, we are over-engineering.
• If we release little and often because Agile recommends it, then we don’t understand our product or its development.

I suggest that, as developers, we think hard about what is important to our users, and what we are capable of delivering. I suggest we release just enough, often enough.