Rants

Why agile software architects should write code

28 January 2017

No architect will ever admit to being out of touch with software development. However, unless you are writing code then it’s difficult to avoid becoming an ivory tower or PowerPoint architect that can only discuss systems in the abstract.

Forget code coverage – test design should be driven by behaviours

19 December 2016

Test coverage statistics are much loved by management teams and code quality tools. They tend to associate a high level of coverage with robust, well-managed code bases. Wrongly, as it turns out.

What’s in a name? Three-lettered acronyms and their impact on development culture

20 September 2016

Three-lettered acronyms can be a useful tool for providing brevity, but they can also give rise to a coded language that contributes to a cold and impersonal development culture.

What do we actually mean when we say business logic?

14 April 2016

In most cases “business logic” just refers to the poorly-defined “gloop” that sits between user interfaces and databases in layered architectures.

REST APIs don’t need a versioning strategy - they need a change strategy

27 September 2015

Change in an API is inevitable. Attempting to manage this change through version numbering usually creates more problems than it solves.

Most software architecture diagrams are useless

11 August 2015

The best architecture diagrams act as a map - if an architect can’t express a system clearly and concisely then they probably don’t understand it properly.

Can cross-cutting concerns really exist between services?

25 July 2015

You might be able to identify cross-cutting concerns in a monolith, but in a service-orientated world they should melt away into specific implementations.

The RESTafarian flame wars – common disagreements over REST API design

22 November 2014

Debates on the finer points of REST can bring out the worst in people as they seek to define what is and is not “RESTful”. In most cases the debate is unlikely to make the difference between success and failure for an API.

The problem with GUIDs…

3 October 2014

GUIDs do solve an important problem. It’s just rarely the problem that developers are trying to address…

The problem with tiered or layered architecture

9 July 2014

An architecture based on tiers or layers is too inflexible to deal with the more flexible demands of modern systems, particularly when you working with high-volume systems that require distributed processing.

Hackable URIs may look nice, but they don’t have much to do with REST and HATEOAS

21 April 2014

Structured and Hackable URIs are a staple part of SEO-friendly websites. Although developers generically expect to see them in HTTP-based APIs, they should be irrelevant to consumers of a fully RESTful API that leverages HATEOAS.

Here's the truth about CMS selection: It doesn't really matter...

27 March 2014

A lot of hot air is wasted on CMS selection. Having lived through many implementations, it’s not the platform decision that determines whether or not you will be successful.

Lean development’s “last responsible moment” should address uncertainty, not justify procrastination

21 February 2014

Deferring decisions to the “last responsible moment” can help you to adapt to the inevitable uncertainty that comes with agile development. The risk is that it can become an excuse for uncertainty that undermines development velocity.

Agile velocity is not a measure of productivity

12 August 2013

Agile does not necessarily lend itself to management reporting. The few metrics it exposes are designed to support internal planning rather than external measurement. It can be tempting to re-purpose velocity as a measure of productivity, though this will only distort team planning without saying anything meaningful.

A shared database is still an anti-pattern, no matter what the justification

22 February 2013

Shared databases risk turning into performance bottlenecks that encourage close-coupling and create a single point of failure. There’s no justification for using them to integrate processes and applications.