patkua@work

The intersection of technology and leadership

Author: Patrick (page 1 of 50)

Why we wrote Building Evolutionary Architectures

When I first started working as a developer, agile was a taboo-word, seen as a fad driven by developers. Scrum was, at least in Australia, unheard of and I luckily fell into a team experimenting with XP (Extreme Programming) combining CruiseControl with CVS and the first version of JUnit.

In those days, most projects ran using some sort of waterfall process with a lengthy requirements-gathering phase, a long architectural design phase followed by problematic development and often a stressful testing phase. You were lucky to get access to a new development because there were long delays in obtaining new infrastructure, waiting for some operations person to set up the machine, configure the services and grant you access.

Fast forward to today where we have a completely different world of technology. We have rich, open source libraries that give us fundamental building blocks to focus on solving our problems. We have powerful computers with vast disk space, processing capacity and memory that enable us to build complex features without waiting for a lengthy compile or build phase. We have access to cloud services that give us even more compute power, disk space and broadband that allow us to rapidly interact with remote services, almost as if they were on a local network.

Today’s world of building software looks very different from what it looked ten or fifteen years ago. The way that we need to design and architect our systems also needs to change. This is one of the reasons why my co-authors and I decided to write the book, “Building Evolutionary Architectures

Long phases of designing an architecture will likely result in an architecture that will be cumbersome to build. Zero architectural design will fail to meet what we deem as a software’s “fitness function.” Instead, developers need to consider how their systems will adapt to change and we’ve looked at modern software development practices, methodologies and processes to understand what supports change and, more importantly, what typically hinders change.

If you’re interested more in this topic, then check out this page on how you can learn more about building evolutionary architectures.

Quotes on metrics and numbers

I published an article a few years ago, called “An Appropriate Use of Metrics.Martin Fowler, who hosts the article, tells me that it receives good regular readership. As someone who has been working as a consultant, I’m aware of how an inappropriate use of metrics can really incentivise the wrong behaviour, destroy company and team cultures and drive incongruent behaviours between teams and people.


Source: From Flickr under the Creative Commons licence.

In this post, I thought it’d be worth sharing a few quotes around numbers and metrics. I’ll leave you to decide where they may or may not be useful for you.

Tell me how you measure me, and I will tell you how I will behave.

Source: Eliyahu M. Goldratt (Father of the Theory of Constraints) from “The Haystack Syndrome” (1980).

What can be counted doesn’t always count, and not everything that counts can be counted.

Source: Often attributed to Einstein but the Quote Investigator suggests crediting William Bruce Cameron (1963).

Not all that matters can be measured.

Commentary: An alternative form to that above often attributed to Einstein.

What gets measured gets done, or What gets measured gets managed.

Source: According to this blog, there doesn’t seem to be a definitive source.

It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth.

Source: W. Edwards Deming from “The New Economics.”

(One of the Seven Deadly Diseases of Western Management) Management by use only of visible figures, with little or no consideration of figures that are unknown or unknowable.

Source: From W. Edwards Deming’s Seven Deadly Diseases of Western Management.

Data (measuring a system) can be improved by 1) distorting the system 2) distorting the data or 3) improving the system (which tends to be more difficult though likely what is desired).

Source: Brian Joiner via the article, “Dangers of Forgetting the Proxy Nature of Data.

The most important figures that one needs for management are unknown or unknowable.

Source: Lloyd Nelson (Director of statistical methods for the Nashua corporation) via Deming’s book, “Out of the Crisis.”

When a measure becomes a target, it ceases to be a good measure.

Source: Also known as Goodhart’s Law phrased by Marilyn Strathern.

If you can’t measure it, you’d better manage it.

Source: Management consultant, Henry Mintzberg

People with targets and jobs dependent upon meeting them will probably meet the targets – even if they have to destroy the enterprise to do it.

Source: W. Edwards Deming. No concrete source found except for Brainyquote.

Conference Tips: Submitting a Talk Proposal

I have been keynoting and speaking at conferences for more than ten years. I also contribute to a number of conferences as a reviewer, giving my thoughts to conference committees on evaluating potential talks/workshops. In this post, I want to share a number of attributes I look for, when reviewing a conference submission. It may help you as a person who wants to submit an idea to a conference. I won’t promise that your talk will be accepted if you follow these tips, but I do hope you end up with a better chance.

Conference talk preparation

Make it relevant to the conference

Some people use a scattershot approach – preparing a single talk that they send to all types of conferences. As a reviewer, it’s relatively east to spot these ones. At an agile-themed conference, there’s a loose tie to a talk titled, “Introduction to Kubernetes.” At a developer-focused conference, there’s a loose tie to talk on “Optimising flow with Kanban” unless there’s an agile twist to the conference. Talks with loose-ties will perform poorly against well-targeted talks that are very relevant to the conference theme and audience.

Consider who the conference attendees are and what themes/tracks the conference has to see if you can make the content more relevant.

Use the Goldilocks rule for talk descriptions

A talk can be too abstract when it tries to put in too many buzzwords without adding any practical information. Want to talk about microservices, docker, or continuous delivery? Great, but let us know how your talk is different and useful. A talk can also be too specific with a very narrow lesson or target audience. Great that you want to talk about how you managed to optimise the smallest possible CSS, using X tool! Is it relevant to a conference focused on software architecture?

Follow Goldilocks and make sure that your talk abstract is just right by considering how your description gives some weight and more meat to your talk. Conceptual talks with examples are a good start. A super narrow topic can be fine as long as it really unique or interesting for potential attendees.

Bonus tip: One sentence talk abstracts are normally too short.

Make your talk title and description match

I don’t claim to have the best talk titles, but I really make sure that the talk descriptions builds on what is eluded to in the talk title. I have see too many submissions where people have a catchy title, and then the description doesn’t match the topic at all. It sometimes seems like two completely unrelated topics and I give the submission a low rating because it’s hard to predict what it will actually deliver.

Define concrete learning points

Although some talks are intended to be inspirational, many talks are there to help others learn about a particular circumstance. You will attract the right participants, and help committees select your topic if you can explain what you hope audience members will learn. I look for three to five key points in a 50-60 minute talk that make your talk stand out from others. The more concrete (and relevant) these learning points are to the audience/conference, the better.

Avoid the sales pitch

Unless you are at a vendor conference, I favour talks that are not overly product focused. This becomes more difficult when the field is highly aligned to a specific topic or technology. Amazingly I have seen many talk submissions made, as if the marketing department of some mega-corporate technology vendor (wonder who that could be, cough cough) made it on behalf of someone else. Please provide something useful, rather than words that don’t add substance.

Draw on real world experiences

People love hearing stories about problems and solutions for technology conferences, and real world experiences or case studies can be really strong vehicles for demonstrating lessons learned. Distilling case studies into higher level conceptual, design or architectural learnings rate highly (assuming it is relevant to the audience).

Use your editing tools

Although I don’t expect all submissions to come from people where English is the first language, please make sure you run your submissions through some sort of spellcheck or grammar check. It’s very painful as reviewers if every third word has a typo and we can’t understand every sentence. If we can’t understand them, chances the conference attendees will not be able to understand them too!

These basic tools are built into almost all text editing program, so please use them.

Conclusion

Having a conference talk accepted isn’t really a mysterious process. There are certainly things that make the life of a selection committee or reviewer much easier if you follow the tips I provide above. Although these tips don’t guarantee your proposal will be accepted, following these will make sure that they don’t automatically get rejected.

Good luck!

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?

Older posts

© 2017 patkua@work

Theme by Anders NorenUp ↑