The Price of Chaos: Balancing Standardisation and Creativity in Software Development

As a software engineer, I once worked for a large organisation that was experiencing continuous growth. However, I found myself in the midst of a chaotic environment where every team was using a different programming language and framework. While the situation seemed exciting initially, it soon became apparent that it was unsustainable. As the number of projects grew, the cost of maintaining all these different technologies began to spiral out of control.

Photo by Tim Gouw on

As a solution, the company’s technical leaders decided to standardise on a single programming language and framework across all projects. The benefits were clear: reduced maintenance costs, improved collaboration and better knowledge sharing. It was a no-brainer, right?

Well, not quite. While standardisation can effectively reduce costs and improve delivery speed, it can also harm creativity and innovation. As software engineers, architects and technical leaders, we must know the potential trade-offs and take a measured approach when considering standardisation.

On the one hand, standardisation can help with cost reduction by reducing the number of technologies needing maintenance. But on the other hand, it can also speed up delivery by allowing teams to share knowledge and resources more efficiently. As a result, it can benefit large organisations with many teams working on different projects.

However, standardisation can also stifle creativity and innovation. When we limit ourselves to a single programming language and framework, we may miss out on new ideas and approaches that could lead to project breakthroughs. We may also lose talented engineers who prefer to work with different technologies. As technical leaders, it’s essential to balance standardisation and creativity.

So, what can we do to strike this balance? Here are a few tips:

  1. Consider your organisation’s needs: Every organisation is unique, and there is no one-size-fits-all solution. Consider the size of your organisation, the number of projects you have, and the resources available when deciding whether or not to standardise.
  2. Involve your team in the decision-making process: Your team members are the ones who will be working with the chosen technology daily, so involve them in the decision-making process. It will help ensure that the chosen technology is a good fit for your team and that they are motivated to work with it.
  3. Allow for experimentation and innovation: Even if you choose to standardise, it’s essential to allow for experimentation and innovation. Encourage your team members to try new tools and approaches and be open to new ideas and suggestions.
  4. Keep an eye on emerging technologies: The technology landscape is constantly changing, so keep an eye on emerging technologies that may be relevant to your organisation. Feel free to explore new technologies and incorporate them into your tech stack if they make sense.

In conclusion, standardisation can be an effective way to reduce costs and improve delivery speed, but it can also have a negative impact on creativity and innovation. As software engineers, architects and technical leaders, it’s essential to strike a balance between the two. By considering your organisation’s needs, involving your team in the decision-making process, allowing for experimentation and innovation, and keeping an eye on emerging technologies, you can find the right balance for your team and projects. And one day, you too will find yourself in a situation where you must choose between chaos and standardisation!

My Personal Kanban, new tiny application just released

I’ve posted about Kanban before (Free Kanban Board , Kanban), however this time I’ve created a little Kanban Board application that I started to use as my personal, sophisticated TODO list.

My Personal Kanban Screen
Example of a Board

My Personal Kanban is Free and Open Source for anyone to use.

More description of it’s functionality can be found here: and the source code in here:

Percent encoding in Groovy

I was writing some helpers for OAuth Twitter authorization. One of the problem I got was the encoding. OAuth is using UTF-8 and percent encoding (special style of URL ecoding).

I couldn’t find anything build-in in Java or Groovy so I wrote a very short little method that does it.

def encodeString(def stringToEncode){

def reservedCaracters = [32:1, 33:1, 42:1, 34:1, 39:1, 40:1, 41:1, 59:1, 58:1, 64:1, 38:1, 61:1, 43:1, 36:1, 33:1, 47:1, 63:1, 37:1, 91:1, 93:1, 35:1]

def encoded =  stringToEncode.collect { letter ->
reservedCaracters[(int)letter] ? “%” +Integer.toHexString((int)letter).toString().toUpperCase() : letter
return encoded.join(“”)

If you ever need something similar, use it 😉