When building a solution with tech, firstly analyze the present situation to understand how it works and what solutions are already in place. We want to learn from this and inform the next solution.

In many ways, like doctors take a hippocratic oath, technology workers can also pledge that they a) will not build a hammer and then look for nails, we will take an approach whereby the needs are understood firstly and b) we will use our knowledge of data, security and access to enforce the rights of users in an ethical way.

The sensitivity of the do no harm principle extends into understanding the meaning that technology has to users. Firstly, we build it based on their needs, secondly we test it with them to get their acceptance. Adding technological layers can easily be a tempting ride whereby unnecessary data and procedures are added. In programming, we apply the principle of YAGNI (you aren't going to need it), same principle is relevant when we build a user experience.

It’s much like Occam’s Razor, the less we assume about our user’s needs, the more likely we are to have identified the correct solution, as in the combination of user experience and technology stack that’s most efficient on both a short and long term.

But when we look for simplicity and meaning, we need to be aware that users are different and social interactions can be complex. This doesn’t mean necessarily that Occam’s Razor isn’t true, but we need to account for everything. Or as Einstein said: Everything should be made as simple as possible, but not simpler.

Open Source contains a moral of giving back. It's not that we need to give away useless source code or expose sensitive data, but more that we understand that the tools we are given for free, obliges us to take part in something bigger.

As a publicly owned entity, this has become an overall thinking that includes using the enormous capacity of the public sector to participate in Open Source. In fact, this is already known to be beneficial to build sovereign systems and as an economically superiour model. On all levels of the public sector, it makes sense

As one of the many concepts that have evolved in the push for more Public Code, is the Open Source stewardship. As much as we believe in sharing code, we believe in sharing experiences. The idea of stewarding open source, is not one of being in power or control. It’s based on principles of taking responsibility to make sure that a project uses existing experiences and tools to emerge.

Once the strategy is in place, software designers and developers can benefit from guidance at the inception of their project and along the way. We want more than just a LICENSE file in the repository. We want documentation, stakeholders and community around the project that can ensure its sustainability.

Code and technology indeed withers over time when it isn’t cared for. Software projects build up technical debt naturally, and the question is when that technical debt becomes an existential threat.

One of the reasons for minimizing a tech stack or being fairly skeptic about technologies is to ensure the longevity of software. A great software platform doesn’t look outdated a few years down the road. You know that if you have used software with a very strong and relevant concept.

Sharing contexts means to take part in the world of users and other stakeholders.

There are several reasons why it makes sense for developers and designers to share as much context as possible with other stakeholders, especially users. Firstly, it makes developers able to become designers and make more qualified proposals. But secondly, it also helps to prioritize in harmony.

Co-realizing is also said to grow the “design space”. This means that by directly sharing technical understanding with users and vice-versa sharing user experience with developers, everyone’s understanding and ability to generate relevant ideas grows.

The idea of “rapid development” has a long historical run-way, leading up to ideas like “ship early, ship often”, agile programming methodologies etc.

As with co-realization, in our understanding of rapid development, we place the developer in the context/domain that the software seeks to solve problems and create value in. The developer needs direct feedback from seeing the software in use.

The short and tight feedback-loop enables developers to act as designers and to generate instant feedback for new features.

This in turn saves costly interactions and translations across actors. By fixing the problem here and now, we don’t risk that the context is diluted, nor that elements are lost in transmission or translation between designers and managers. By letting the programmer be the designer, we in turn push responsibility and initiative to the user that gets to instruct the programmer directly.