Converting to Kotlin

kotlin_250x250After dipping my toe in the water a number of times, I’ve finally taken the plunge. Over the last couple of weeks I’ve been migrating a private project from Java to Kotlin. This is a report of how it’s been going…

Firstly, my main interest in Kotlin was the cleaner language design, the clear Java migration path and good interoperability with the JVM ecosystem. What do I mean by “cleaner language”? The my favourite example are the Kotlin data classes. In my code base, I have a large number of classes deriving from “Event”. Each one of these event classes has a number of attributes, with corresponding getter functions, plus an equals, hashcode and toString function. Here’s one of my classes:

public class LearnerAddedToOrganisation implements Event {

    private final LearnerId learnerId;
    private final OrganisationId organisationId;
    private final UserId agentId;
    private final Instant eventTime;

    public LearnerAddedToOrganisation(LearnerId learnerId, OrganisationId organisationId, UserId agentId, Instant eventTime) {
        this.learnerId = requireNonNull(learnerId);
        this.organisationId = requireNonNull(organisationId);
        this.agentId = requireNonNull(agentId);
        this.eventTime = requireNonNull(eventTime);

    public LearnerId getId() {
        return learnerId;

    public LearnerId getLearnerId() {
        return learnerId;

    public UserId getAgentId() {
        return agentId;

    public Instant eventTime() {
        return eventTime;

    public boolean equals(Object o) {
        if (this == o) {
            return true;
        if (!(o instanceof LearnerAddedToOrganisation)) {
            return false;
        LearnerAddedToOrganisation that = (LearnerAddedToOrganisation) o;
        return Objects.equals(learnerId, that.learnerId) &&
                Objects.equals(organisationId, that.organisationId) &&
                Objects.equals(agentId, that.agentId) &&
                Objects.equals(eventTime, that.eventTime);

    public int hashCode() {
        return Objects.hash(learnerId, organisationId, agentId, eventTime);

    public String toString() {
        return String.format("LearnerAddedToOrganisation{learnerId=%s,organisationId=%s,agentId=%s,eventTime=%s}",
                learnerId, organisationId, agentId, eventId);

Here’s the code for the same class after I converted it to Kotlin:

data class LearnerAddedToOrganisation(
        override val id:                LearnerId,
                 val organisationId:    OrganisationId,
        override val agentId:           UserId,
        override val eventTime:         Instant) : Event {
    val learnerId: LearnerId
        get() = id

This Kotlin code has exactly the same functionality as the Java equivalent, plus it also has a copy function as well.

This conciseness can lead to some large reductions in code size. The module I converted to Kotlin originally had ~8,000 lines of Java code. After conversion, it contained ~4,800 lines of Kotlin, which corresponds to a 40% reduction in code size. This is a significant improvement! Consider that programmer output in terms of lines of code tends to be relatively stable, independent of language. Switching to a language where the same features can be implemented in fewer lines of code means more features can be built.

The more I use Kotlin, the more I find I enjoy using it. I’m definitely going to use it more in the future.

The Hosting of has Changed

This is just an administrative announcement: I have moved to be hosted by It was previously hosted on a EC2 server and database. At the time I moved to AWS, I felt it was an interesting project to learn the AWS tools and infrastructure. In that sense, it was a good way to learn. However, years later I’m running months behind on keeping everything updated with security patches and paying too much for AWS services. Given that 90% of my website was already running under WordPress, I decided to bite the bullet and let manage my site for me, allowing me to kill my EC2 server and save some money.

The transfer wasn’t quite painless: some of the URLs have changed. All the content is still available, but if you have any bookmarks, they may need to be updated, and the RSS feed location has changed too, so you may need to update your subscription.

Software Development is an Engineering Discipline

There is a view that software development is a craft; that “Software Craftsmanship” is a better metaphor for software development than is engineering or science. I’m going to argue against this view: software development is an engineering discipline, and relies strongly on scientific principles. Firstly, what is an engineering? Here’s one definition of the engineering method:

The Engineering Method is the use of heuristics to cause the best change in a poorly understood or uncertain situation within the available resources. – Billy Vaughn Koen

What heuristics? In general, they look something like this:

Engineering method

(from the article “Comparing the Engineering Design Process and the Scientific Method“)

The first thing to notice is the feedback loops here. The steps brainstorm ⇒ develop ⇒ test corresponds to the TDD cycle in software development:

TDD cycle(from “Growing Object-Oriented Software, Guided by Tests“)

The difference between the engineering design process with physical products and TDD in software is mainly the speed of the feedback loop. A skilled developer can often go through the red-green-refactor loop in less than 5 minutes, as there is no physical materials to manipulate. When you then add in the steps specify requirements ⇒ … ⇒ meets requirements around the TDD cycle, you get the ATDD cycle: ATDD Cycle

Depending upon the size of feature that the the acceptance test describes, this could take anywhere from an hour to a week, though high-performing teams learn that quicker feedback is critical to quality.

Zooming out, there is a larger feedback loop surrounding the ATDD loop: the lead time between new software capabilities being prioritised and the capability being used by an end user. The DevOps movement is built on the focus on the software and organisational structures required to get software into the hands of end users as quickly as possible.

The size of the feedback loop is probably the most critical part of successful engineering. Consider, for example, the first human powered flight across the English Channel. The Kremer Prize was established in 1959 to give some motivation to show that human powered flight was both possible, as able to go long distances.

The challenge was picked up by many peoples and teams, but there was very little progress until the problem was examined by Paul MacCready, who noted that the engineers were trying to solve the wrong problem.

MacCready’s insight was that everyone working on solving human-powered flight would spend upwards of a year building an airplane on conjecture and theory without the grounding of empirical tests. Triumphantly, they’d complete their plane and wheel it out for a test flight. Minutes later, a years worth of work would smash into the ground.

The problem was the process itself… He came up with a new problem that he set out to solve: how can you build a plane that could be rebuilt in hours not months. And he did. He built a plane with Mylar, aluminium tubing, and wire.

After two and a half years, MacCready team successfully flew the Gossamer Albatross II across the English Channel in just under 3 hours.

Gossamer Albatross

(Gossamer Albatross II in flight, from Wikimedia Commons, public domain)

Compare this feedback loop to a more traditional engineering discipline based upon something less malleable than software: traffic engineering. This is a branch of civil engineering that uses engineering techniques to achieve the safe and efficient movement of people and goods on roadways. In this case the engineering medium is road signs, lane markings, asphalt, road size and shape. In some cases, the traffic engineer will look to move roads through entire buildings. The behaviour of traffic can be very complex, with surprising effects from interventions (think of adding a lane to a busy road, causing induced demand, causing worse traffic delays). In all these examples, the feedback loop for understanding if the intervention was successful can range anywhere from days to years. In order to reduce the risk of untested changes, traffic engineers must use models of the road, and run the simulation in software.

In summary: software development that makes use of feedback loops to help understand and direct the problem solution is most definitely engineering.

One question is left to ask: where does Software Craftsmanship fit in the context of software engineering? My take is that Craftsmanship is the focus on the skills that are known to be effective, a body of knowledge on the techniques that are effective. Engineering without skills won’t get you very far. Skills without engineering means that you can build the wrong thing very well. Both are required.

(This post was prompted by a discussion between Dave Farley and myself when we were both at the book launch of Infrastructure as Code by Kief Morris. A subsequent discussion with Andy Parker helped refine the topic)

Devops 101

I recently saw a reference to Devops 101 on Twitter. It looked interesting, so I bookmarked it, and forgot about it for a few weeks.

Devops 101 - Part 4

Last night I finally got around to trying the exercises – it was a bit of an eye-opener. There’s a huge amount of functionality on AWS that I’m not really up-to-date with (and I say this as a person who has been running an AWS EC2 instance for many years now).

The “101” part of the name implies that it’s a starting place for graduate developers. I would clarify to say that it’s very useful for anyone who isn’t working on infrastructure-as-code day to day. If you’re developer who is not yet embedded in a team working devopsly, give it a go.

I had never had a chance to place with the AWS command line, and leveraging that with cloudformation and ansible was an real pleasure to use.

I previously worked at a company where we had built our own stack builder tool. I never got to grips with it at the time, but I now want to go over it again.


Well, I finally received an invitation to join My Keybase profile is:

I first heard about Keybase from a post by Tim Bray in March. I’ve been quite interested in crypto stuff since forever, but I’ve never been able to use it consistently in all my communications. Given the increasing surveillance issues on-line, it seems prudent to increase use of encryption, but it’s still very hard when pretty much everyone I would ever chat with can’t decrypt. Wider use of tools like GPG and usability wrappers like Keybase might improve the situation. As a first step, this is my announcement of my public key and availability to receive encrypted messages, should you so desire.

Keybase is currently still in a closed alpha. You can request to join, but it will probably take a while (it was 6 months for me). Even without Keybase, you can still use GPG directly, just retrieve my public key from

Management Training for the Twentieth Century

So, I recently took management training course. There was some useful stuff taught in the course (such as delegation, coaching, and performance management, among other things). I learnt a lot, most of it useful. I’m not here to talk about that, though. I’m here to rant…

First problem: the feedback method they were teaching was the “shit sandwich“. I thought it was known for years that the shit sandwich was shit. However, in this course this shit sandwich was still king of the dung-heap. They had videos of actors giving each other the praise-shit-praise rigmarole, and then turning around giving the thumbs up and a shit eating grin. I kid you not.

Second problem: Myers Briggs. At the time, I didn’t know better. It’s an interesting topic. I felt that I was learning a really useful tool that would help me to understand myself and others. (I’m an INTJ, thanks for asking!). However, as I recently found out, Myers Briggs is completely meaningless. That’s a really interesting article, and explains why Myers Briggs is so popular: the Forer effect.

Now, if you will excuse me, I have to send some feedback to the course administrators…