What does security say to you?

Imagine for a moment that you randomly select someone in the street and ask him or her “What does the term security say to you?”, the likelihood is that he or she will immediately think of their personal and loved ones’ safety, or the excellent TV series Mr Robot, or media reports about the hacked accounts of socialites.
If that proverbial person in the street happens to be a software professional, perspectives like login screens, captchas and firewalls are likely to pop into his or her mind.
All are coherent viewpoints. But since everything starts with design, what about security in design? Digitalisation customers are more aware of security and privacy these days. Market forces are driving the need to better protect digital products, services, utilities and other critical infrastructure. The ubiquity of the internet and cloud demands ever more proactive and robust protection for business and personal assets to thwart security- and privacy-related harm. There are security- and privacy-related standards, directives and regulations. And of course, product and service security is a contributor to overall quality, which in turn contributes to customer satisfaction and the monetary bottom line.
So, the business justification for secure design is clear. But what does secure design mean?

Security defined

The term security is derived from the Latin root secura, meaning free of concern. According to SAFECode.org, “Secure design encompasses methods and processes that ensure design, software and user experience function as intended, while mitigating the risks of vulnerabilities and malicious code that could bring harm to your business and to your end users”.
Now, since being free of concern is a human emotion, I must admit that I slightly amended the original SAFECode definition to also incorporate the terms design and user experience, since it is secure design that facilitates secure development which, in turn, enables secure user interaction. In essence, a secure design is a design that is self-protective and, in the context of usability and user interaction, is trustworthy.

What does secure design mean in practice?

So, getting back to the proverbial person in the street, he or she could now reasonably enquire “Well, those are fancy definitions, but then what does secure design mean in practice?”
I would reply that secure design is a mindset and way of working throughout the lifecycle of any product or service digitalisation project. That is to say, security is take into consideration during requirements gathering, architecture design, user interface design, coding, testing, and deployment to customers. In other words, security is built into the product or service from the start, not bolted-on as an afterthought.
Then the proverbial person in the street will logically ask “OK, so how can I do that, and with what?”
I would reply that we conveniently don’t have to go to the bother of inventing secure design frameworks since they already exist.
Firstly, there is the open-source Open Web Application Security Project (OWASP) flagship project called the Open Software Assurance Maturity Model (OpenSAMM) Version 1.1 which is a security assurance framework to help organisations formulate and implement a strategy for software security that is tailored to the specific risks facing the organisation.
Secondly, there is the Security Development Lifecycle (SDL) Version 5.2 developed by Microsoft which incorporates secure development recommendations for Agile development. The Microsoft SDL is vitally focused on the identification of security threats and their mitigation via secure design, secure coding and security verification.
Thirdly, the OWASP project provides a security verification standard that provides a basis for testing web application technical security controls and also provides developers with a list of requirements for secure development.
Companies large and small that are security-aware are utilising these industry-scrutinised frameworks and are benefiting from them.

Secure design enhances inter-disciplinary collaboration

A common thread across these holistic resources is that they encourage us to incorporate industry-scrutinised secure development lifecycle best practices into our daily work. They also facilitate better communication and comprehension amongst digitalisation designers, architects and developers.
For example, threat modeling is the activity of scrutinising a design to identify user and business assets that require protection, and the security controls to protect them. Threat modeling starts in the design phase and requires facilitated collaboration between designers, architects and developers. In this way, a usable and sufficiently secure design starts to be built from the outset, reducing the vulnerability surface of the product or service even before any code is written. Secure coding and security testing further reduces the threat landscape and vulnerability surface to the point where a sufficiently secure service or product is accomplished.
Another impetus for this secure design ethos is that secure design is also a privacy-supporting pillar, and privacy is a media magnet these days. All the more reason then to also invite the privacy manager to threat modelling workshops.

You can start secure design already today

There is no barrier to adopting the secure design mindset and way of working already today. Although ideally begun at project initiation, you can already consider how to introduce the security practices that are relevant for the stage of the project you’re in right now. Your secure design mindset will start to germinate and competence will evolve as you adopt and incorporate secure design and development best practices into your work.

Niall O'Donoghue

Niall is a secure design best practices advocate, coach and promoter. His experience includes seeding the secure design mindset and best practices for private sector Internet of Things web applications and facilitating threat analysis workshops for public sector web application projects. Niall is also passionate about helping organisations to evolve their overall security maturity.

Linkedin profile

Do you know a perfect match? Sharing is caring

My previous blog post focused on making the meaning of metrics, why should you avoid having too many metrics, and which metrics are used in software development. I concluded that ‘time to feedback’ is the best metric to manage a software development process. This blog post gets deeper into the time to feedback metric’s anatomy.

The Noble Metric

The time to feedback defines the time elapsed between the identification of a requirement and customer feedback. The final goal is to gather the customer feedback at the earliest chance. The benefit of the time to feedback metric is that it measures the whole process, not only one part. This avoids sub-optimizations and leads software developers, system specialists, UX designers, product owners, and other development people to co-operate.
Here are few practical actions that help to reduce the time to feedback:

  • Work continuously with your customer
  • Do as few things as possible at the same time
  • Focus on prototypes and ‘Proof of Concepts’
  • Minimise your task size
  • Keep your backlog as short as possible
  • Release as quickly as possible

Above actions are also considered the best practices in software development. This shows the metric is selected wisely. Now it is time to implement the metric.

In God We Trust, Others Bring a War Room

During the second world war, English prime minister Winston Churchill needed a place where he could ‘direct the war’. Churchill and his team built war rooms under London where the core team met daily and the crucial information was available. The war room’s walls were covered with important statistics, maps, and reports, and they were updated daily.
A project room should be set up using the same principles. The room is simultaneously a workplace, meeting point, and knowledge centre. Whiteboards or printed excel sheets are an easy way to hang the metric data. Be sure that your data is visible, clear, updated, and explained to everybody—also to the executive team.

A Simple Graph is Enough

Collecting the time to feedback data is fairly simple. Write down the creation date of the task and when the feedback is gathered. Create a graph and update the average time to feedback monthly. If the data is not collected in every task, make sure the sample data is large enough.
There are numerous ways to gather customer feedback. Surveys, comments, tests, interviews, and on-site activities are just a few examples. The collaboration with your customers must be on daily basis, and not a complicated process.
Unless you are working with remote or distributed teams, there is no need for fancy issue-tracking systems, such as Atlassian Jira. These systems are expensive, highly complicated, and need a dedicated person for maintenance. Issue-tracking systems come with a wide range of reports, however, the proper ones are usually missing. If you work in conditions of remote or distributed teams, using the simplest track-system such as Trello and sharing your data via a wiki or collaboration tool is the ideal recommendation.

The Next Challenge

Adding a couple of more metrics to your software development process is possible, but keep in mind that too many metrics give mixed signals and are time-consuming to maintain. When the software development metrics are up and running, it’s time to concentrate on the more important question: how will the customer feedback change your product?

Graphic design

Ville Takala



Juhana Huotarinen

Juhana Huotarinen is a lead consultant of software development at Gofore. Juhana’s background is in software engineering and lately, he has taken part in some of the biggest digitalisation endeavours in Finland. His blogs focus on current topics, involving agile transformation, software megatrends, and work culture. Juhana follows the ‘every business is a software business’ motto.

Do you know a perfect match? Sharing is caring

Ode to Kotlin

I hate working with Java. I really do. It makes me always feel powerless and bored. Yet I need to face it in pretty much every project I work on – one way or other. I do get the reasons of many companies to use Java, but those are based on completely different perpective than the one that I have as a programmer. In this blog post I’ll tell you why I feel so and introduce a great alternative, Kotlin, based on my experiences on Kotlin in projects varying from plain Kotlin to Spring 5 WebFlux and Android. I do hope that the things described in this post will encourage you to at least consider Kotlin as an alternative for your beloved Java.

My problem with Java

Describing everything I hate about Java would take a blog post series of its own. In this post I concentrate to the parts that I come across most often while doing web development with it.
The biggest problem of Java is the unergonomic nature of working with it and especially the ecosystem around it. Let’s take a few examples of code that needs to be written all the time while doing web development. First there are the POJOs (Plain Old Java Object) needed to model the data structure of applications. Here’s an example of idiomatic Java code:

class Person {
  private String name;
  private Integer age;
  public Person(String name, Integer age) {
    this.name = name;
    this.age = age;
  public String getName() {
    return name;
  public setName(String name) {
    this.name = name;
  public Integer getAge() {
    return age;
  public setAge(Integer age) {
    this.age = age;

There is 20 lines in this model, out of which not even half declare anything useful. Let’s compare this to same model as idiomatic Kotlin:

data class Person(var name: String, var age: Int)

Okay, looks quite a lot simpler. How about the usage then? Let’s declare an array of objects of these types. First Java:

final List<Person> persons = new ArrayList<>(Arrays.asList(new Person("John", 36), new Person("Mary", 29)));

And Kotlin:

val persons: MutableList<Person> = mutableListOf(Person("John", 36), Person("Mary", 29))

Ok, so at least to me even the creation of objects seems also a lot more compact in Kotlin.
Kotlin is an excellent example of a programming language I categorize as modern, developer-friendly programming language. Kotlin is constantly releasing new versions with the most wanted features by the community. It does this constantly with small batches instead of Java’s huge updates coming every X years. In practice, Java’s latest release (Java 8) is from 2014 while Kotlin has released already once (1.1) along with multiple patch, preview and release candidate versions this year with at least Kotlin 1.2 still coming before the end of the year.
Generally speaking I do believe the less code you have the less there is to maintain. One could argue that since you have to write less code to achieve the same you must be skipping some important things or there have to be some implicit stuff (often referred as magic) that would need to be explicitly written for it to be clear. But that is not the case actually. Just take a look at the examples above, they aren’t lacking anything that is in the corresponding Java code, but they are much nicer to write and read since there is less noise around the actual thing.
Java development is also overly complex. I never was able to wrap my head around of all the Java EE stuff. Nor did I even try because I always knew it won’t be the way to go. With solutions such as Spring Boot that have lately become the standard way to do web services there has already been a huge improvement on this. Still, the solutions made by Java programmers tend to follow the same overengineering practise from the past. This isn’t something that can easily be changed. No wonder also Spring 5’s WebFlux has built-in support for Kotlin.
For me the caricature of a Java developer is a developer who is totally locked in to the way things are done in Java which is obviously the only acceptable way for him/her. They rely on XML which has in my opinion partially the same problems as Java. Essentially it is not ergonomic to use. Java developers, in my experience, tend to believe that other languages are just some kind of toy languages for pet projects and not capable of building the complex enterprise applications (whatever that even means) that they need to build. These developers always think that their application is so large and complex that it can only be solved with the one and only enterprise-capable programming language in the world – Java. Usually the services built are actually quite simple and could be implement a lot easier with some more appropriate tool like Node.js. Yet the only capable language is believed to be Java.
Okay, that is quite harsh and most propably not an accurate description of many Java developers but you get the idea, right? Still, they say every cloud has a silver lining. That is the case also for Java for which the great part is the JVM as discussed in the next section. Also the ecosystem is quite good around Java.

So how about Kotlin?

First, let me tell you what Kotlin is. Kotlin is a modern programming language by JetBrains (the company behind the IntelliJ IDEA and other IDEs among other stuff related to software projects). It continues the list of JVM-based languages such as GroovyScala and Clojure. Kotlin, released in 2011, is not only running on top of JVM but completely interoperable with Java. This means that companies can migrate existing codebases to Kotlin gradually piece by piece without extra hassle and still leverage the large ecosystem around Java. Kotlin can be used also to do Android development without performance hit. It also supports compilation to JavaScript for Node.js or browser apps.
But what makes Kotlin more ergonomic to use than Java? Kotlin aims to be as concise as possible and to eliminate a lot of boilerplate code found in applications written on Java. Kotlin’s home page gives great examples of all the most important benefits of using Kotlin. Since we already mentioned the POJOs, let us start with the example used already earlier:

data class Person(var name: String, var age: Int)

Wow, that is concise. So how about the setters and getters I (as Java developer) want for every damn field no matter they’ll never even contain any logic? Well, Kotlin already generated the getters and setters for us. I don’t personally find the value of getters and setters to be that great and I am happy to use public fields instead. And yes, I am familiar with the idea behind using private fields and getters/setters but I never do anything special in the getters and setters so I am happy to refactor the direct usages of public field to getter/setter when actually needed. But I’m not going to dive into that discussion now since it is out of scope for this post.
Another extremely important feature that many languages (such as Swift) have implement because of null-safety problems with languages like Java is the concept of Optionals. Yes, the Optional<T> is there finally in Java 8 but it is simply too little too late. Kotlin makes the null-safety main feature of language instead. Here is an example of how the optional code looks like:
This produces a compilation error:

var myString: String = "foo"
myString = null

while if we explicitly allow null values, this would compile:

var myString: String? = "foo" // Non-null value
myString = null

Also if we have possible null value, we can’t just call some method on it:

var l = myString.length // // error: variable 'myString' can be null

and instead we need to explicitly do a safe call with ?. instead of .. This way the result is null if the left-side of operator is null.
You can still get an NullPointerException in case you explicitly want it or some external Java code throws one but those are special cases and won’t happen by accident on Kotlin side.
One extremely annoying feature of Java has always been that it only supports Object-oriented programming. Even the very basic lambda functions weren’t possible before Java 8. Kotlin provides the basic OOP capabilities while offering great support for functional programming with features like functions as first-class citizen and encouraging usage of immutability.
Besides the features highlighted here, there are lots and lots of features in Kotlin that make it superior compared to Java. These things include better syntax, fresh take on asynchronous coding with coroutines and great tooling support by IntelliJ IDEA. One great example of the last one is the option to convert Java code to Kotlin automatically. Having used quite a lot of this it has proven to work extremely well.


Technology choices are always made with at least some kind of assessment of costs and risks associated with certain technology. Often heard concern is how fast the team will adapt the new technology. As Kotlin builds up on the same premises as Java it is extremely easy to adapt by Java programmers. The basic types are the same and code looks a lot same. Also the whole ecosystem built around Java is easily used within a Kotlin project. These facts combined with automatical conversion from Java to Kotlin to see how things would look in Kotlin makes the learning of Kotlin easy for Java developers.
Second concern relates to the expected future support for the technology. Kotlin is supported and used by JetBrains itself which is one of the key players in software-related tooling. There’s currently no reason to expect they would stop the development for a long time. It is also used by many well-known companies as listed on Kotlin’s home page. Kotlin is also recommended by Google to be used on Android development.
The Java-interoperability of Kotlin is also an extremely important aspect as it lets you use all of the Java libraries and frameworks. Besides that it is also possible to not only convert Java code to Kotlin but also vice versa (though not explicitly supported by the tooling) in case you want to get rid of Kotlin for good.
As a conclusion Kotlin takes the best parts of Java and combines those with a modern language with great tooling. Its advanced features allow you to write concise and clean code without unnecessary boilerplate around it. Let me know of your experiences in the comments below. Also keep your head up for upcoming posts about soon-to-be released Spring 5 and especially its new WebFlux module.

Roope Hakulinen

As a lead software developer Roope works as team lead & software architect in projects where failure is not an option. Currently Roope is leading a project for one of the world's largest furniture retailers.

Do you know a perfect match? Sharing is caring

Some months ago, I organised a workshop with the theme of efficiency in software development. During the workshop, I asked participants to identify how they would like to measure bugs. In just a few minutes the participants invented more than twenty different bug metrics. If a bug tracking is only a minor part of the software development process, how can you handle hundreds of metrics and statistics?

Metrics Beat Arguments

Metrics are a vital part of learning. Without a foundation, it is impossible to know if you are improving or regressing. Metrics give guidance to your decision making and make the important information visible.
Breaking down your metrics into vanity and actionable metrics help you to focus on the essential. Vanity metrics are typically nice and easy to collect, but don’t change how you act. In the worst-case scenario (such as what happened in the  Space Shuttle Challenger disaster, huge amounts of vanity metrics hide the critical data with fatal consequences.
By contrast, actionable metrics change the way you behave. Software and consulting firm Gofore’s actionable metrics are, for instance: the utilisation rate, employees’ engagement level, and clients’ satisfaction rate. To test your metric, just double or divide the value. If you need to reschedule your calendar after modification, you have found an actionable metric.

Less is More

“Can’t do what ten people tell me to do, so I guess I’ll remain the same” sings Otis Redding. This  Otis Redding problem explains that too many metrics give mixed signals and require unnecessary work, and as my workshop example shows it is extremely easy to invent numerous metrics in a limited time.
Have you ever wondered why management books introduce so many four-element theories? The root cause is humans’  limited working memory capacity. An average human can remember 3 to 5 items at once. Your metrics should follow the same pattern—less is more. The Lean Startup movement goes even further. It introduces the  ‘one metric that matters’ concept, where there’s one metric you should care about above all else. If the product goals changed, then the metric needs to change as well.

And the Oscar Goes to…

It is impossible to choose one metric that works on every product. The metric depends on the business model, product maturity level, and other boundary conditions. The whole Lean Analytics  book focuses on how to choose the right metric for your product.
Whereas software development rules are universal, speed with superior quality is always the key to success. Typical software development metrics are velocity, throughput, burndown metrics, cycle time, lead time, work in progress (WIP), and different bug metrics. What if you need to survive with only one metric?
The essence of agile is to reduce feedback loops, hence my natural choice is the ‘time to feedback’ metric. It defines the time elapsed between the identification of a requirement and customer feedback. The time to feedback metric provides a whole software development organisation one single goal: how can we get the customer as close as possible?
My latter blog post goes deeper into the time to feedback metric and explains how you should use the metric in your software development.

Graphic design

Ville Takala



Juhana Huotarinen

Juhana Huotarinen is a lead consultant of software development at Gofore. Juhana’s background is in software engineering and lately, he has taken part in some of the biggest digitalisation endeavours in Finland. His blogs focus on current topics, involving agile transformation, software megatrends, and work culture. Juhana follows the ‘every business is a software business’ motto.

Do you know a perfect match? Sharing is caring