When buying software, buy multiple products and glue them together
Why custom software only creates a headache for a city
When buying software, we often try to buy one system that solves all our needs.
The problem is that there rarely are “silver bullets,” which means you can’t buy, but need to build. As a non-technical organization, that means we procure an agency to build a custom software solution fo us.
At first glance, custom software sounds like a good idea — like a wedding dress, perfectly fitting and just the style you want.
There are two aspects with software that make them different from a dress or a shovel.
It’s a donkey not a shovel
Software needs to be compared to a donkey rather than a shovel. Software is a living thing, not something you buy and are done with.
We face constant change and therefore nurture our tool otherwise it will die. For software that means making sure that it is compatable with new versions of browsers, fixing security vulnerabilities,new devices and integrating into other services.
It’s expensive but it scales
The other aspect is that software takes time to build, which means it is expensive if we are the only one to bear the cost. On the other hand, software has virtually no increase in price depending on usage — it “scales well” and there is no ware or tare.
So, if we get anything custom built every hour of product improvement and maintanance needs to be paid by us. If we buy software as a service solutions or leverage open source software the cost of developement is instead distributed between a multitude of other cities or companies investing in the same tool.
1+1 = 3
From the perspective of the ones who create software, products should ideally “do one thing and do it well”. Instead of looking for the “silver bullet” or going for custom built, we need to break our problem apart and combine services to solve it.
Use glue
The only thing, ideally, which is custom made is the “glue” between the products we buy. Glue is programmer slang for all the things that make two things work together — like sharing data or working on a unique context only our organization has.
Let’s look at two projects where we used this method. The first one is “Felanmälan” (that Rikke Koblauch has covered in a blogpost) and the other the HR-survey.
Error reporting
For the error reporting prototype aka “Felanmälan”, the job to be done is to help citizens report issues in the city, such as a hole in the street, a fallen tree, or dangerous trash lying openly.
Instead of procuring a complex solution, or even building one of our own, we used a chatbot platform called Chatfuel for the logic on top of Facebook Messanger, the UI. Whenever people wrote to it, it merely pushed that into an Office365 Excel sheet as our database.
HR-survey
For the HR-survey, the city wants to evaluate employee happiness within their respective team. Historically, it had been an analog process with printed papers sent around. There are plenty of survey tools, but as the old, paper survey, had a dart board, somehow that requirement had been presented to procurement.
We settled for a custom-built interface for the survey summary but built it on top of an existing survey solution, which made the final solution easy to maintain and cheap.
To summarize
Your own custom software is a bad idea. All problems can be divided into small parts, each which a product solves well. The only code to be custom made is the glue between products or in most extreme cases a user interface. This makes it cheaper to buy, easier to maintain, and possible to in the future add more products to the mix that works with the earlier ones.
