Development process

April 3rd, 2017

Architectural governance can be used to foster innovation. No really.

Governance doesn’t have to be all about byzantine process and suffocating approval boards. It can be used to provide clear permission for teams to innovate.

September 20th, 2016

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

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.

June 28th, 2016

Should microservices share technologies and platform capabilities?

Should agile teams be encouraged to share capabilities or be given total autonomy over their technology choices? For larger organisations this can become a trade-off between economies of scale and speed of delivery.

May 22nd, 2016

How do you foster “technical excellence” in an agile development culture?

Technical excellence is one of those slightly nebulous phrases with many different interpretations. In an agile context this means removing constraints and it is more than just a team responsibility.

May 5th, 2016

Managing services that don’t have clear code ownership

How do you organise code ownership for services that do not align conveniently with team or organisational boundaries?

January 18th, 2016

Informatica Cloud development best practices

Informatica Cloud is a powerful environment but a pretty unforgiving one. Here are some best practices that I have picked up from implementing the platform.

August 11th, 2015

Most software architecture diagrams are useless

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.

June 12th, 2015

Deploying a Windows Service remotely with Powershell

As with any deployment automation, there’s a fair amount of duct tape and chicken wire involved in deploying a Windows Service remotely.

April 6th, 2015

Using logstash, ElasticSearch and log4net for centralized logging in Windows

The ability to collate and interrogate your logs is an essential part of any distributed architecture. This generally involves stitching together different technologies via configuration.

February 21st, 2014

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

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.

August 12th, 2013

Agile velocity is not a measure of productivity

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.

June 4th, 2013

Sharing web services and APIs in an organisation: challenges and pitfalls

Sharing services and APIs can appeal to a desire to reduce duplication and improve development efficiency. It’s a worthy ambition though the journey there can be littered with costly traps for the unwary.

January 15th, 2013

Sharing code between geographically distributed development teams

Large-scale development increasingly involves distributed teams as organizations seek to manage costs and leverage resources on a global scale. However, sharing code between distant development teams gives rise to problems that can only be addressed in part by processes and tools. You also need teams to communicate directly and build trust.

September 3rd, 2012

How to manage down the payments on your technical debt

Technical debt may be a great metaphor to describe the corrosive effect of quick and dirty design decisions, but it can be difficult to identify, measure and manage.

April 30th, 2012

Why refactoring code is almost always better than rewriting it

Developers and architects like to build things, so their initial impulse is often to flatten the place, lay some stronger foundations and build something impressive. It can be difficult to get them excited about incremental innovation, even when this is generally the most sensible approach from both a technical and commercial perspective.