dev.hel.fi

The City of Helsinki is Finland's biggest employer with about 40,000 employees. This is mostly due to the city's extensive services in the health care, social services, and schools. But how many code fellows does Helsinki employ?

There are now six of us.

Why should the city hire software developers and programmers? Is this really the core mission of a local governmental organization? Shouldn't the city direct its funds to more directly benefit the public and let private sector information technology companies take care of creating software products?

I am glad you asked! There are several long-term trends which make in-house development absolutely worthwhile for a government organization. They are

1. the digitalization of society,
   
2. embracing change in software, and
   
3. the breakthrough of open source software.
   

1. The Deepening Digitalization of Society

In the old days, any organization's activities consisted mostly of people communicating with each other through paperwork and in meetings. The first step of digitalization meant replacing letters with emails and paper documents with Word documents. The quality and contents of the processes didn't change so much as the speed and perhaps the amount of communicating.

A deeper digitalization however has already begun. This second step of digitalization has taken the form of interactive multi-user network applications which manipulate structured data. In a setting where the network has become ubiquitous and mobile, the benefits are far reaching. This finer-grained digitalization enables us to automate tasks that are possible for computer programs to handle and leave the meaningful parts for humans.

Looking at the bigger picture, information technology permeates society's processes making government already thoroughly embedded in software. Developing governmental processes requires developing software and vice versa.

But we have also entered a stage where new technological realities have started to affect what kinds of processes are possible in the first place. Existing organizational processes can no longer dictate what it is that we implement in software. For example, completely new kinds of participatory collaboration methods are starting to emerge -- partly because it is now possible to implement them.

But how do we develop governmental processes and the software it requires?

2. Specific but changing needs

There are many reasons why change is so central to most software development. This has given rise to development methods which embrace changing requirements. In a nutshell, software is developed incrementally, so that we gradually grow a bigger and more complete product which can be tested and validated with users from the earliest stages. Feedback from users and stakeholders affects the direction the development takes next, and feedback is frequent to avoid the risk of ending up in a completely wrong destination.

Handling requirements would be simpler if the processes we need to encode in software were clearly defined and cut in stone. Typically they are not:

• Software requirements are complex. People cannot articulate and formulate them correctly and completely without a functioning system or prototype against which ideas can be examined in proper context.
  
• People might not originally even know what they want, which is not a shortcoming, but often an opportunity to approach software development as a study in the problem domain. Also, unanticipated effort saving solutions in software prototypes might give new incentives to streamline the underlying processes.
  
• Laws and regulations, along with local culture and norms affect the requirements. They also change over time, as do political realities, values, and goals.
  
• The technological landscape itself changes, making previously high-effort tasks trivial, opening up completely new possibilities, and making existing solutions obsolete. This also changes people's expectations of software services, especially from a usability viewpoint.
  

These realities make it impossible for a public organization to just buy their software off the shelf -- in so far as the software will be intertwined with their intricate local processes, and will need to evolve over time. The software will have to be customized to the needs, and this is best achieved with an incremental process with a tight feedback loop.

The tightest loop is achieved when those who deliver the software are part of the same organization as those who will use it, sharing domain expertise and the same general goals.

Of course, agile software development services can also be bought from outside consultants. However, procuring agile development requires a high base level of technical expertise at the buyer's end, so a core in-house developer team is highly useful even then. It is needed so that the buyer can realistically evaluate solutions, proposals and estimates given by partners. The two parties can negotiate and collaborate on an equal footing, in the same language, and without intermediaries.

3. The emergence of open source

Creating new software takes a lot of resources and time. Starting from scratch, it would hardly be cost effective or even possible with a small team. Luckily we can stand on the shoulders of open source project maintainers.

It is easy to underestimate the effect free and open source software has had on information technology. For example, we might not realize how virtual servers and the cloud would never have hit mainstream if Linux hadn't commoditized the computer operating system and if license costs restricted our server deployment options.

Put simply, open source is what enables the work of the dev.hel.fi Code Fellows, by giving us a vast collection of mature and production ready web frameworks and libraries, and the underlying stack, on which to build our services. This gives even a small team a velocity which would have been unheard of in the past.

Open-source development is a prime example of how a new technological tool (the Internet) has fundamentally transformed an existing process (software development) into something arguably new (massively collaborative development and maintenance of a shared asset). Software developers have been the early adopters of such a model, but we are already seeing it adopted in domains closer to traditional city government, like cartography. Other similar domains will surely follow at some point.

I find it highly appropriate that public sector organizations contribute to existing open source projects and publish their own new code as open source. Participating in maintaining common free information infrastructure is something that aligns very well with the basic task of government in a more traditional sense: to provide basic infrastructure like streets and to act as an underlying enabler for citizens and businesses alike. Also, using open source software doesn't exclude any potential partner from collaborating with us in our projects and doesn't tie us in with any single partner.

Conclusion

In conclusion, the activities of the City of Helsinki (or any organization) are increasingly manifested in software. To make these activities more efficient and evolve them flexibly according to changing goals, we need a fast moving team which develops the software while embracing change. And open source software is the underlying force multiplier that makes this magic happen in the first place.

By the way, we are not alone.