patkua@work

The intersection of technology and leadership

Just Published: Building Evolutionary Architectures

I’m very proud to announce the release of a new book that I co-authored with Neal Ford and Rebecca Parsons whilst I was at ThoughtWorks. Martin Fowler writes the Foreword (snippet below):

While I’m sure we have much to learn about doing software architecture in an evolutionary style, this book marks an essential road map on the current state of understanding

Building Evolutionary Architectures

It marks the end of a very long project that I hope will have a positive impact on the way that developers and architects consider building and designing software. We will also post related news to our accompanying website evolutionaryarchitecture.com

You can find the book available on:

Enjoy!

Starting as CTO at N26

I’m excited to announce that I’ll be taking on the Chief Technology Officer (CTO) role for N26 (formerly Number26), Europe’s first mobile bank with a full European banking license, and who is setting new standards in banking.

I’m joining an exciting and talented team based in Berlin, Germany – one of the favourite start-up cities in Europe. In my new role, I’ll draw upon more than a decade of my consulting experiences with the well-respected and industry-changing technology firm, ThoughtWorks – best known for leading the adoption of agile ways of working (particularly its technical practices), publishing open-source software like CruiseControl (the first widely used Continuous Integration servers) and Selenium (well-known automated web-testing tools), and sharing ideas through books like Continuous Delivery and the Lean Enterprise. I’m really looking forward to applying my experiences guiding organisational design, building evolutionary architectures, developing technical leaders all while sustainably delivering value for our customers.

What will be different?

After many years as a consultant, I realise that working with a product organisation is a different beast. I look forward to having some responsibility to instigate and guide changes throughout the organisation and living out the long-term consequences (both good and bad!) of my actions. I know that this is often a missing feedback loop for consulting. In my role, I’ll be able to invest more in challenging and growing people and building out new technical and organisational capabilities.

I also look forward to spending a bit more time “at home”. I still expect to travel for my new role, still speak at some conferences but I hope I will have a bit more say as to when and where I’ll travel to, based on our business needs rather than where clients happen to be based. Did I mention that I’ll also be based in Berlin, and it’s a great city with a very good balanced lifestyle? I might even get a chance to further develop my German again.

Why FinTech and N26?

As a consultant, I was always skeptical about having significant long-term impact on established financial companies. With teams, or parts or the organisations, yes. With a 10,000+ person company, less so. The exciting part about working with N26 is that I will work with a strong management team to prevent unnecessary bureaucracy and to let people focus on adding value to the product and organisation. We benefit from not supporting certain types of legacy, and building software with Continuous Delivery and modern technologies first. I’ll be helping guide us away from the traps and pitfalls I have seen many customers suffer from in the last decade.

The N26 Black Card

I also like the fact that N26 is growing fast, and has already proven to meet customer needs, where all growth has been organic so far with very little advertising. Did you know that we recently hit 500,000 customers (PDF)? It’s also one of the first mobile-first startup banks with a European banking licence, which opens up a world of opportunity that a lot of other FinTech banking products do not yet have.

Here’s what TechCrunch wrote two years ago:

N26 (Number26) could be the best banking experience in europe – Tech Crunch

Bank of the future

In case you can’t tell, I’m really delighted to be leading the technology organisation behind the bank of the future. The team has already accomplished a lot so far, and I look forward to working with the team to do even more. We’re going to build an exciting place to work in the FinTech sector and have a huge impact on our ever-growing customer base across Europe. If you’d like to be a part of the N26 team and join me on this journey, did I mention that we are hiring?

Drop me a line on twitter @patkua (DM’s open), or on my email address if you’re even curious. Berlin’s a great city to live and N26 is a great place to work while you’re there.

Leaving ThoughtWorks

I started with ThoughtWorks back in Brisbane, Australia in 2004. Though not a graduate developer (we didn’t hire graduates back then), I was one of the younger members of the company. I still remember being sat down by the then-Managing Director before starting with my first client, where he said, “We’re not really sure how you’re going to work out, but we’ll go on that journey together.” More than 13 years later, I guess everything did work out, and I’ve shared the same path with ThoughtWorks a long time.

Farewell ThoughtWorks

Now, my path is heading in a different direction. I take with me many fond memories, many wonderful new friends and acquaintances, and a wealth of experiences. I have grown through working on projects across multiple countries (Australia, Brazil, Canada, Denmark, India, Germany, Singapore, South Africa, Thailand, the USA), multiple verticals (including banking, charity, energy, gambling, government, housing, publishing, recruitment, retail, telecommunications, travel and valuable goods) and playing multiple roles (architect, cat-herder, developer, facilitator, leader, trainer and many more). I’ve been able to work with companies in their early days, when they hit growth and experienced scaling problems, all the way to large established companies looking to change and transform the way they build software.

I appreciated working with so many well-respected and well-known people such as Barry O’Reilly (Lean Enterprise), Dan North (BDD), Dave Farley (CD), Gregor Hohpe (EAI), Ian Robinson (SOA guru), James Lewis (Mr Microservices), Jez Humble (CD/Lean Enterprise), Jim Webber (SOA guru), Kief Morris (Infra-as-code), Liz Keogh (BDD), Martin Fowler (Martin Fowler!), Neal Ford (Speaker Extraordinaire), Pramod Sadalage (Refactoring Databases), Sam Newman (Microservices), Rachel Laycock (Head of Tech for N. America), Rebecca Parsons (CTO) – and I need to stop now as there are so many other people I will forget off the list!

I’m grateful to have seen the company grow across countries (15 countries & 42 offices), adapting to local cultures yet keeping the “core” culture of engineering excellence, passion and a love of learning. It’s this combination plus the magic of trust that let teams live up to ThoughtWorks’ reputation. I am also proud to see our values (The Three Pillars) discussed and seen first hand, how they influence management decisions. I realised early on, that there is a delicate tension in balancing these three pillars within local and industry constraints and that there is rarely a “perfect solution.” However I truly do believe the balance is signficantly better in comparison to other companies.

I’m particularly grateful to have benefited from learning from others, watching others grow, and helping others grow. I also learned that these are not mutually exclusive options!

Where to now?

An opportunity landed on my doorstep, taking me along a different path, and means I’m off to try something different. I feel excited about my new opportunity (more on that to come!) but also excited to watch ThoughtWorks continue to grow, evolve, and continue to have a positive impact on the industry.

Book Review: 37 Things One Architect Knows

The author of 37 Things One Architect Knows, Gregor Hohpe, has a lot of experience to share, already having published the hugely successful and still highly relevant book, Enterprise Integration Patterns book in 2003. More than a decade later, Hohpe published his experiences playing the Architect role across many different organisations and shares useful tips and tricks for the modern day Architect.

Grab a physical copy of 37 Things One Architect Knows here or get the ebook as a published bundle Tools for Tech Leads and Architects

The term Architect is certainly overloaded, and although his book is aimed at describing the role of a Transformational Architect (one who can help shift traditional organisations into thinking, planning and acting more digitally), there are many different gems that Architects in all types of situations can benefit from.

Hohpe describes the Architect role using the analogy of a large building and the interplay between the Architect, the elevator and traversing the building up and down; “Be sure to stop in the “engine room” and various floors from time to time,” is a useful reminder for Architects to avoid staying in the Penthouse (aka Ivory Tower) and understand the value that a well-informed Architect can add when they truly understand the issues in the “engine room.” He has kindly also published an expanded version using this metaphor on Martin Fowler’s Bliki.

The book is divided into five different sections:

  • Architects – Exploring the various interpretations of the term Architect, and his perception of its responsibilities.
  • Architecture – Useful tips and approaches to understanding, defining and shaping decisions.
  • Communication – A really key area that Architects need to develop and draw skills on to be succesful.
  • Organisations – An explanation about the relationship between the Architect and the interactions and world they find themselves in.
  • Transformation – A call to action for Architects.

Hohpe has a great story-telling skill, and with cute and memorable chapter titles like “Control is an Illusion”, “If You Never Kill Anything, You Will Live Among Zombies” and “You can’t fake IT” there are useful cross-references contextualising the pragmatic advice gathered over his long career in technology.

Buy this book if you want to be a more effective software architect. You will learn some of the false assumptions or traps unexperienced architects fall into when they take on the role. You can order a physical copy of 37 Things One Architect Knows here or get the ebook as part of a bundle, “Tools for Tech Leads and Architects”.

The Technology Landscape in Singapore

Earlier this year, I held my Tech Lead Skills for Developers workshop in Singapore and Thailand. It was a short and busy week including some customer visits and a talk on Building Evolutionary Architectures for the local community.

As a consultant, I’m lucky to travel to different parts of the world where I have been able to compare technology industries and cultures around the world. Please note that the following observations are simply my observations and not necessarily backed by research.

Extreme Shortage of Developers

Talking to a number of managers, it’s apparently very difficult to find experienced and very good developers. There seem to be a number of reasons for this including how Singapore Universities aren’t producing enough software developers, a country limit that ensures a consistent ratio of foreign and local talent and a culture that values higher status over getting things done.

Dense and active community

Singapore reminds me a lot like London. The financial sector has a big impact on the technology market. London is much more diverse from that perspective. Singapore, like London, is a small dense population with a very good public transportation network. The public infrastructure enables many community meetups as people don’t have to worry about driving, traffic or how long the commute might take and thus enables a lot of learning to be done.

One of people I met during my time at Singapore, Michael Cheng (or @coderkungfu), organises the Engineers.SG website, where they go around to meet ups, film the talks and put them online.

Above is a picture of Michael and I during the course I was running. What he organises is no small time-commitment, and is a huge service to the community and makes the content available to a much wider group.

High Power Distance Index (PDI) matters

Accroding to Hofsted, a researcher on the cultural dimensions of countries, Singapore has one of the highest PDI ratings. This means that ranking, titles and the relationship between titles matter more to people in Singapore than in countries with a lower PDI (such as the US or the UK).

Translated into the local market – almost everyone wants to be a manager.

One person was telling me about one team where they had two developers building software and eight managers managing! It wasn’t of any surprise to me that this team worked in a finance industry. It also didn’t surprise me that not a lot of work got done!

Singapore is following, not yet leading in technology

Singapore is known for its passion and drive to make a big difference for its size. I see many great things changing on the island state, however I see many other challenges in their market that simply investing in programmes as a nation won’t necessarily change.

If you want any other perspectives on this market, I’d recommend reading a couple of this articles:

Book Review: Scaling Teams

This weekend I finished reading Scaling Teams by Alexander Grosse & David Loftesness.

I know Grosse personally and was looking forward to reading the book, knowing his own personal take on dealing with organisations and the structure.

tl;dr Summary

A concise book offering plenty of practical tips and ideas of what to watch out for and do when an organisation grows.

Detailed summary

The authors of the book have done a lot of extensive reading, research and talking to lots of other people in different organisations understanding their take on how they have grown their organisations. They have taken their findings and opinions and grouped them into five different areas:

  • Hiring
  • People Management
  • Organisational Structure
  • Culture
  • Communication

In each of these different areas, they describe the different challenges that organisations experience when growing, sharing a number of war stories, warning signs to look out for and different approaches of dealing with them.

I like the pragmatic approach to their “there’s no single answer” to a lot of their advice, as they acknoweldge in each section the different factors about why you might favour one option over another and there are always trade-offs you want to think about. In doing so, they make some of these trade-offs a lot more explict, and equip new managers with different examples of how companies have handled some of these situations.

There are a lot of links to reading materials (which, in my opinion, were heavily web-centric content). The articles were definitely relevant and up to date in the context of the topics being discussed but I would have expected that for a freshly published book. A small improvement would have been a way to have them all grouped together at the end in a referenced section, or perhaps, (hint hint), they might publish all the links on their website.

What I really liked about this book its wide reaching, practical advice. Although the book is aimed at rapidly growing start-ups, I find the advice useful for many of the companies we consult for, who are often already considered very succesful business.

I’ll be adding it to my list of recommended reading for leaders looking to improve their technology organisations. I suggest you get a copy too.

Three ways to handle CFRs

Cross-Functional Requirements (CFRs) are some of the key system characteristics that are important to design and account for. Internally we refer to these as CFRs, although classically they might be called Non-Functional Requirements (NFRs) or System Quality Attributes, however their cross-cutting nature means you always need to consider the impact of CFRs on new or existing functionality.

In the Tech Lead courses that I run, we discuss how it’s important that the Tech Lead ensures that the relevant CFRs are identified and accounted for either in design or development. Here are three ways I have seen some CFRs accounted handled.

1. CFRs satisfied via user stories and acceptance criteria

Security, authentication and authorisation stories are CFRs that naturally lend themselves to actually building out testable functionality. It’s important to consider the effort the risk and, in my experience, is important to start implementing these early to make sure they meet the needs and can evolve.

For these sorts of CFRs, it’s useful to identify these as natural user stories, and once implemented become acceptance criteria on future user stories that touch that area of the system.

As as example, authorisation can be dealt with by introducing a new persona role and what they might do (or not do) that others can have:

As an administrator, I would like to change the email server settings via a user interface, so that I do not need to raise an IT change request for it.

If this is the first time that this user story is implemented, then some acceptance criteria might look like:

  • Only a user with an administrator role can access this page
  • Only a user with an administrator role can successfully update the email setting (check the API)
  • Users with no administrator access receive a 403 or equivalent

This new role addition often means considering new acceptance criteria for every story going forward (if it should be accessible only by administrators or by all.

2. CFRs satisfied through architectural design

Scalability and durability are often CFRs that require upfront thinking about the architectural design, and perhaps planning for redundancy in the form of additional hardware, network, or bandwidth capacity. A web-based solution that needs to be scalable might draw upon the 12-factor application principles, as well as considering the underlying hardware. Failing to think about the architectural patterns that enable scalability and start coding will lead to additional rework later, or make it even impossible to scale.

3. CFRs satisfied via the development process

User experience is a CFR which often requires people, making automated testing much more difficult. An application where a high level of user experience is best dealt with by ensuring that a person with a background in UX is involved and that certain activities and feedback cycles are planned into the software development process to continually fine-tune the user experience as an application evolves.

Changes to the development process might include explicit user research activities, continuous user testing activities, the addition of an A/B capability and some training for product people and the development team to ensure that the developed software meets the desired level of user experience.

Conclusion

Every system has their own set of Cross-Functional Requirements (CFRs) and it is essential that teams focus on identifying the relevant and important CFRs and find ways to ensure they are met. In this article, I shared three typical ways that CFRs might be met.

How else have you seen these handled?

Automated Tests for Asynchronous Processes

It’s been a while since I’ve worked on a server-side application that had asynchronous behaviour that wasn’t already an event-driven system. Asynchronous behaviour is always an interesting challenge to design and test. In general, asynchronous behaviour should not be hard to unit test – after all, the behaviour of an action shouldn’t necessarily be coupled temporally (see forms of coupling).

TIP: If you are finding the need for async testing in your unit tests, you’re probably doing something wrong and need to redesign your code to decouple these concerns.

If your testing strategy only includes unit testing, you will miss a whole bunch of behaviour which are often caught at high level of testing like integration, functional or system tests – which is where I need asynchronous testing.

Asychronous testing, conceptually, is actually pretty easy. Like synchronous testing, you take an action and then look for a desired result. However unlike synchronous testing, your test cannot guarantee that the action has completed before you check for the side-effect or result.

There are generally two approaches to testing asynchronous behaviour:

  1. Remove the asynchronous behaviour
  2. Poll until you have the desired state

Remove the asynchronous behaviour

I used this approach when TDD-ing a thick client application many years ago, when writing applications in swing applications was still a common approach. Doing this required isolating the action invoking behaviour into a single place, that, instead of it occurring in a different thread would, during the testing process, occur in the same thread as the test. I even gave a presentation on it in 2006, and wrote this cheatsheet talking about the process.

This approach required a disciplined approach to design where toggling this behaviour was isolated in a single place.

Poll until you have the desired state

Polling is a much more common approach to this problem however this involves the common problem of waiting and timeouts. Waiting too long increases your overall test time and extends the feedback loop. Waiting too short might also be quite costly depending on the operation you have (e.g. hammering some integration point unnecessarily).

Timeouts are another curse of asynchronous behaviour because you don’t really know when an action is going to take place, but you don’t really want a test going forever.

The last time I had to do something, we would often end up writing our own polling and timeout hook, while relatively simple is now available as a very simple library. Fortunately other people have also encountered this problem in java-land and contributed a library to help make testing this easier in the form of Awaitility.

Here is a simple test that demonstrates how easy the library can make testing asynchronous behaviour:

package com.thekua.spikes.aysnc.testing;

import com.thekua.spikes.aysnc.testing.FileGenerator;
import org.junit.Before;
import org.junit.Test;

import java.io.File;
import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.util.Arrays;
import java.util.List;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

import static java.util.concurrent.TimeUnit.SECONDS;
import static org.awaitility.Awaitility.await;
import static org.hamcrest.Matchers.startsWith;
import static org.junit.Assert.assertThat;

public class FileGeneratorTest {

    private static final String RESULT_FILE = "target/test/resultFile.txt";
    private static final String STEP_1_LOG = "target/test/step1.log";
    private static final String STEP_2_LOG = "target/test/step2.log";
    private static final String STEP_3_LOG = "target/test/step3.log";

    private static final List<String> FILES_TO_CLEAN_UP = Arrays.asList(STEP_1_LOG, STEP_2_LOG, STEP_3_LOG, RESULT_FILE);


    @Before
    public void setUp() {
        for (String fileToCleanUp : FILES_TO_CLEAN_UP) {
            File file = new File(fileToCleanUp);
            if (file.exists()) {
                file.delete();
            }
        }
    }


    @Test
    public void shouldWaitForAFileToBeCreated() throws Exception {
        // Given I have an aysnc process to run
        String expectedFile = RESULT_FILE;

        List<FileGenerator> fileGenerators = Arrays.asList(
                new FileGenerator(STEP_1_LOG, 1, "Step 1 is complete"),
                new FileGenerator(STEP_2_LOG, 3, "Step 2 is complete"),
                new FileGenerator(STEP_3_LOG, 4, "Step 3 is complete"),
                new FileGenerator(expectedFile, 7, "Process is now complete")
        );

        // when it is busy doing its work
        ExecutorService executorService = Executors.newFixedThreadPool(10);
        for (final FileGenerator fileGenerator : fileGenerators) {
            executorService.execute(new Runnable() {
                public void run() {
                    fileGenerator.generate();
                }
            });
        }

        // then I get some log outputs
        await().atMost(2, SECONDS).until(testFileFound(STEP_1_LOG));
        await().until(testFileFound(STEP_2_LOG));
        await().until(testFileFound(STEP_3_LOG));

        // and I should have my final result with the output I expect
        await().atMost(10, SECONDS).until(testFileFound(expectedFile));
        String fileContents = readFile(expectedFile);
        assertThat(fileContents, startsWith("Process"));

        // Cleanup
        executorService.shutdown();
    }

    private String readFile(String expectedFile) throws IOException {
        return new String(Files.readAllBytes(Paths.get(expectedFile)));

    }


    private Callable<Boolean> testFileFound(final String file) {
        return new Callable<Boolean>() {
            public Boolean call() throws Exception {
                return new File(file).exists();
            }
        };
    }
}

You can explore the full demo code on this public git repository.

The Gift of Feedback (in a Booklet)

Receiving timely relevant feedback is an important element of how people grow. Sports coaches do not wait until the new year starts to start giving feedback to sportspeople, so why should people working in organisations wait until their annual review to receive feedback? Leaders are responsible for creating the right atmosphere for feedback, and to ensure that individuals receive useful feedback that helps them amplify their effectiveness.

I have given many talks on the topic and written a number of articles on this topic to help you.

However today, I want to share some brilliant work from some colleagues of mine, Karen Willis and Sara Michelazzo (@saramichelazzo) who have put together a printable guide to help people collect feedback and to help structure witting effective feedback for others.

Feedback Booklet

The booklet is intended to be printed in an A4 format, and I personally love the hand-drawn style. You can download the current version of the booklet here. Use this booklet to collect effective feedback more often, and share this booklet to help others benefit too.

Reflecting on the Tech Lead Skills for Developers Course in Brazil

Earlier this month, I visited our Brazilian offices to run some internal training, called Tech Lead Skills for Developers. The trip felt a bit full circle as I had visited Brazil several years ago for the same reason and needed to develop the material. Instead of the handful of people I coached, I ran two full classes with a mix of people currently playing the Tech Lead role and those who might be stepping into the role.

The course I run uses a mix of training styles (short presentations, lots of time for story sharing, discussions, interactive exercises, brainstorm and lots of time for question time). In general I’m really happy with the overall result with a good balance of covering lots of material, making it personalised and relevant, and giving people an opportunity to practice, gather feedback and have a go at applying it. The feedback for the course was quite consistent with those in the past, telling me that the balance was just about right.

One of the great opportunities I have had, running this course in different places is seeing some of the cultural implications and differences between continents. I learned, for example, that Brazil (traditionally) has a higher Power Distance Index (PDI on the Hofstede Dimensions), which means that, at least compared to the United Kingdom or America, authority is viewed a bit more strictly. In practice, this meant that a lot of the developers, working in more collaborative environments seemed to almost take an extreme anti-leadership position, where any mark of authority was viewed poorly, or that there was a reluctance to be seen taking on a title.

I also discovered that the word delegate in Portuguese had a negative association. As we discussed how effective leaders scale themselves through effective delegation, it was almost interpreted as a manager telling people to take care of the bad tasks – which, of course, wasn’t the intent! In the end, I tried to express effective delegation as a way of ensuring that all important responsibilities were being taken care of.

I am running this course again later this year in both Thailand and Singapore and look forward to seeing some more of the cultural differences that emerge during the discussions.

« Older posts

© 2017 patkua@work

Theme by Anders NorenUp ↑