Monday, 16 July 2018

Another Technical Debt Quandrant and Debt Days

Martin Fowler's Technical Debt Quandrant

Ages ago I blogged about The Technical Debt Quadrant as explained by Martin Fowler in his blog from some years earlier. When I re-read that article (Martin's, not mine) it looks a lot like a discussion that was of its time. The reason why I raise this again is because recently I came across a completely different kind of debt quadrant, not for helping us understand how it came to be but for helping us to understand when to pay it back. In the course of some discussions with my current client I combined it with a thing that I learned from my previous client to come up with a plan to address technical debt.

Bug Squash

At my last client I was tech lead of a team that was mainly responsible for fixing production defects in the platform that we were implementing. Leaving aside whether this is an anti-pattern (it is) we were managing a large backlog of defects whilst simultaneously adding "BAU" enhancements to the platform itself. One of the side effects of this dual focus was that annoying little defects rarely got fixed. A knock on effect of that was that our backlog was growing, we were spending money managing it but we didn't really know if the backlog was real or not.

A Bug Bash is an exercise to be done occasionally, the object of which is to find previously undiscovered, or unrecorded, issues and get them on somebody's backlog. This could be semi regular, just before a major release or upgrade or just a fun afternoon. In my experience of these occasions, anybody can take part, there is probably some kind of refreshments offered and there may be some kind of gamification and prizes on offer.

Somebody in the team proposed something that came to be known as "Bug Squash". It wasn't me, for sure, but I remember thinking it was a great idea and that we should try it. The idea is kind of the opposite of a Bug Bash. We decided that every Wednesday afternoon we would all drop everything that we were working on and we'd look at the backlog from the least important stuff upwards (instead of the usual top down way of picking stuff to fix) and we would either fix the issue straight into the code base or we would record in the ticket why it was no longer an issue and close the ticket. We left it up to everybody to decide exactly how they wanted to work. If they wanted to pair fine, if they didn't that was also fine. This had some great benefits. First, it was fun. Second, our backlog got smaller so we could all share in the success of that, third it spread context of the whole codebase amongst more people.

Another Tech Debt Quandrant

My current client thinks it has a lot of tech debt and this is one of the reasons why myself and a colleague are here for about 3 months to try and advise on some thing they can do to help themselves. As you might expect, tech debt is a symptom of some wider problems with the organisation. Unlike many symptoms though, it is always worth treating tech debt because it has a nasty habit of multiplying and making your future life more difficult.

One of the big problems is that the tech debt makes it hard to do stuff. So they know they need to be paying this debt down but they find it hard to find the time to pay it down. And one thing that makes it hard to find time to pay down tech debt is tech debt. I think everybody can see where that one ends. We've tried a few different things to help with the situation. Currently each team is asked to assign 20% (it might be 10%) of their capacity in their sprint plan to debt items. The trouble is that these are the very items that feel the axe if the teams realise that they won't make their sprint commitment. Moreover, somebody spent some time analysing the debt, creating a card, putting on the board, bringing it into the sprint cycle etc etc. So the management of the problem becomes part of the problem itself (see my earlier post on inventory management).

So in advising on a way to get to the outcome (reduced technical debt) what we needed was a method that was easy to manage and track that encouraged people to pay down the debt. The first stage was a debt quadrant (an idea that was introduced to me by a ThoughtWorks colleague last year). Instead of just having a debt wall onto which everybody pins things they'd like to fix, you split your debt wall into 4 quadrants, as per the picture below.

For those that can't read my handwriting (probably everybody) the vertical axis is labelled "Ease of Solution" and the horizontal axis is labelled "Impact". So I hope it is therefore obvious that stuff in the top right (high impact, easy to fix) should be fixed as soon as possible. The stuff in the top left should be looked at and maybe fixed, the stuff in the bottom right should be looked at, analysed and prioritised into the normal process (whatever that is). Hopefully then, this simple visualisation gives each team a good way to record, manage and pay down their tech debt.

Debt Days

But what if people still don't feel like they have the time to do any of this? Our simple suggestion was that one afternoon a week (that would be about 10% so one whole day or two half days would be 20%) the team should drop everything they are doing on the sprint. Instead, they should pick up one of the cards in the top right of the debt quadrant and do something about it. No time used on planning or estimation or arguing what is the most important thing. Just pay back some tech debt.

It is early days yet but by combining the ideas of a simple quadrant and setting aside REAL time to do something (not time in a sprint plan that might not happen) we will hopefully get some significant payback of our debt pile whilst having some fun along the way.

Saturday, 2 June 2018

Architectology Update

Some time ago I wrote a post on this site about architectology. I have had a lot of time to think further about the subject since my original post, which I have just read again. I didn't really have a conclusion or a solution in that original post. It seems that I was saying that the notion of a person who spends their time navigating legacy code feels wrong but I had no better way of dealing with the silos and extracting value from them.

From talking to a lot of software professionals over the past year I have discovered that many large businesses (and public sector bodies) have their own word for architectologists, it seems that many of them widely refer to such people as "enterprise architects".

I've recently completed a 10 month engagement with a public sector client and although they didn't call them enterprise architects they had plenty of architectologists. I now believe I have seen enough to propose that architectology is an anti pattern. According to Wikipedia, an anti patter is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. To distinguish a genuine anti-pattern from a simple bad habit, the following 2 conditions must be met:

1. A commonly used process, structure, or pattern of action that despite initially appearing to be an appropriate and effective response to a problem, has more bad consequences than good ones.

2. Another solution exists that is documented, repeatable, and proven to be effective.

Firstly, is architectology a common response to a recurring problem? I would argue that it is. The problem is how to extract value from silos of legacy systems. The response is to task some people (architectologists) with drawing pictures of the legacy with lots of arrows on it to show a software team how they might get stuff done.

Secondly, does it have more bad consequences than good ones? I think so. Among other things it prolongs the lifetime of the legacy, couples it more strongly to more processes and makes it successively harder to add new value to the enterprise.

Finally, what is the better solution? Last summer we had a good deal of success in the client we were working at in persuading them to create cross functional teams that own the entirety of a customer facing outcome. Having made that step, the logical next step was to repurpose their architectologists (IIRC they were called enterprise architects) as architects working more closely with software teams delivering those outcomes. As the teams that previously owned the legacy pieces were broken up, nobody was left illogically defending the existence of various pieces and the client was able to start sensibly decoupling the systems and strangling parts out of existence.

So it is therefore my conclusion that architecology (or enterprise architects if you prefer) fulfils the criteria to be regarded as an anti-pattern.

I recently gave a short talk postulating that architectology is an anti pattern at Devoxx UK in London.

Thursday, 3 May 2018

* Driven Development

With thanks to my colleagues - Andrew Jones Weiss, Velizar Genov, Gergo Takacs, EnterTheDragos, Robert Chow, Stuart Paton.

I had a conversation with a friend a couple of days ago about what work his team was doing. They were supposed to have done some work "in time for UAT" but they missed getting a couple of stories into the locked down UAT environment before the deadline. Thus, UAT wasn't going to cover those use cases. The next UAT wasn't due to happen for a couple of months so they changed their focus on to some different stuff.

I laughed at this and commented that this sounded like Politics Driven Development. I had never heard the term before but given the nature of the organisation my friend works in, I thought it was an apposite term for what they sometimes end up doing. That got us into discussions of what other *DDs exist.

We then set ourselves the challenge of coming up with a whole alphabet of *DDs. Some of them are serious, some of them are not, some of them we made up to get through the alphabet. Our criteria was that for something to stand it either has to be a real thing or the person suggesting it had to have experienced it at some point in their career.

Any more suggestions welcome!


AWS Driven Development - This is when your company migrates from the old server farm to AWS and all future development is constrained by the tools and services that AWS offers.


Behaviour Driven Development - this is a thing.

Bullshit Driven Development - when an influential developer blags that they understand a technology and the team goes too far down the road of relying on that technology before they realise that (a) that developer was lying and (b) the tool is not appropriate for the job. Extra points if the developer that influenced the decision leaves the company shortly after the decision was taken. Kafka is a repeat offender in this space.

Bleeding Edge Driven Development - this is when you must on NO ACCOUNT use any technology found closer to the middle of the ThoughtWorks Tech Radar than the Assess ring. If there has been a conference with this as its main subject you may still use it but only if that conference was an UnConference.


Career Driven Development - when a decision to use a language or technology is not driven by what is best for the problem at hand but by what the developer or developers want to learn to enhance their career within an organisation.

CV Driven Development - like Career Driven Development except the motivation is to enhance your CV with the intention of moving to a different job.


Domain Driven Development - this is a thing.

Developer Driven Development - This is when developers as a group decide that they want to do something interesting. So they decide that instead of using boring old Java for their Microservices that they are going to use shiny new and interesting Clojure. This could also morph into one or other of the types of CDD.


Ego Driven Development - It’s what Rockstar developers do.


Failure Driven Development - Your system has so many defects with new defects being constantly reported that you never have the bandwidth within your team to play any stories that add new value. You are sentenced to be forever jumping to the tune of the person in the business who is screaming the loudest to have their defect fixed.

Fowler Driven Development - When Martin Fowler posts a new blog post that could impact your work in progress you then make it your business to ensure that it WILL affect your work in progress. Extra points are awarded if you contact a friend you have within ThoughtWorks to ask for a clarification on the nuance of what Martin was referring to before you modify your stories.


Google Driven Development - Like AWS Driven Development except you use Kubernetes and the Google Cloud tools.


Hypothesis Driven Development - This is a thing.

HiPPO Driven Development - This is based on the HiPPO decision making process that many organisations rigidly stick to. To implement HiPPO decision making you gather a large group of people in a room to discuss the decision. The larger the better. You then discuss the thing for a long time listening to everybody's opinions, including those that will live the consequences of the decision. Then, the Highest Paid Person's Opinion (HiPPO) is aired and that is the decision taken. HDD is when the priority of features is decided purely on the seniority of the person that requested it. Actual business value is irrelevant and pointless to argue about. If the CEO requested it, it's the first thing you do.

Hype Driven Development - This is strategic decisions based on what the current "big thing" is (see also ThoughtWorks Driven Development). So if the buzz in the industry is Microservices, then the CTO will be demanding that we "should be doing Microservices" irrespective of cost of value.


IntelliJ Driven Development - when you join a new codebase the IDE tells you all the bad things about the code. AKA Alt + Enter Driven Development.


JetBrains Driven Development (see IntelliJ Driven Development)


KISS Driven Development - Let’s keep this one simple.

Kangaroo Driven Development - I’m struggling here, you may have noticed. This is when you have a weak or no product owner who has a bad time articulating upwards what is important and what isn’t. You therefore end up jumping from one priority to another never quite knowing from one week to the next what your purpose as a team really is.


Lifestyle Driven Development - As a tech lead I always think there are two kinds of decisions. Those that I care about and those that I really don’t. Some people get really exercised about the second type of decision. I’ve seen conversations over whether we should use a 2 or 3 space indent in our C# code rumble on for 3 months. Seriously. And it involved edit wars in FXCop lint rules. Any such decision, that really doesn’t matter in my view, is a lifestyle choice. Lifestyle Driven Development is when this type of Bikeshedding dominates team stand ups, team planning meetings and all team conversations. Even in the pub.


Marketing Driven Development - when a marketing campaign proves that a market exists for a new product that you haven't built yet, forcing you to build it.

MoSCoW Driven Development - this is a thing.


Negativity Driven Development - This is when your developers are so negative about the prospects of the code not falling apart that you write dozens of tests that test the edges of the edge cases that can only ever be hit when all 8 planets (and Pluto) align in such a way that frogs fall from the sky and turn into baby poodles before they hit the ground. This causes such immense scope creep that your project funding expires playing the first story and nothing ever goes live.


Optimism Driven Development - This is when you design for the happy paths only because obviously those are the only bits of your system that will ever get exercised. This is very true, until your project goes live at which point you have to run for the hills.


Politics Driven Development - Many large organisations are riven by internal politics. When you work in such an organisation you know about it. Politics can lead to some pretty illogical decision making around prioritisation of your backlog. Conversations could be something like "We think this is the most important thing but we need to keep this group happy because we need them onside to help with next year's budget approvals".

Patterns Driven Development - When one developer has recently read Design Patterns by the Gang of Four and goes through the codebase insisting that everything be refactored to closely follow some of the patterns in the book. It doesn't matter if it is an appropriate pattern for solving the problem at hand and it doesn't matter if the code being refactored is covered by solid tests that can verify the refactoring. In fact it is better if there are no tests at all so that you really have no idea if the code still behaves as expected. Patterns Driven Development is an Anti-Pattern.


QA Driven Development - This is a thing but every reference I found to it calls it Tester Driven Development but we already had stuff in T.


Resharper Driven Development (the Visual Studio version of IntelliJ Driven Development).

Retro Driven Development - This is actually a good thing. This is when you do something for two weeks, discuss how it can be improved then realise that you were doing it wrong so now you do it right. Wash and repeat.


Sales Driven Development - This is when your sales team makes a bespoke deal with a new partner assuring them that we have systems in place to support these weird business rules that they just invented on the fly. They then come and talk to the tech team and say things like "we can do this, right?" It obviously doesn't matter if we can or not because we're now committed to hastily implementing the features that we have already sold. This happens a lot in start up companies.

Stack Overflow Driven Development - It’s a thing, no really! It is! This is often characterised by code comments saying “I don’t really know what this does but here’s a link to the Stack Overflow page”.


Test Driven Development is a thing that I hope we are all familiar with.


Underwear Driven Development - This is when a team works as a distributed team and most people’s default setting is working at home. During stand up everybody is on a video link and you can tell which developers aren’t dressed yet because their video feed will be a black screen with “John’s iPhone” written on it.


Value Driven Development is a thing.


Waterfall Driven Development - We’ve all been there. Hopefully not recently. Oh dear, does last year count?

Wagile Driven Development - When you are actually doing Waterfall but the project management like to claim you are doing Agile.


XD Driven Development - I thought this was a real thing but when I Googled it I couldn’t find it. At a place I worked recently the client had a really strong UX department and their product design was heavily influenced by what the UX people did with user research and workshopping. It seemed to work pretty well, the product was really cool that we built and had good take up from the target market.




Zealot Driven Development - When somebody in your team is so vehement in their beliefs that they drive the team forward to complete the work according to their standards. This was, in fact, the method used to construct this blog post. My colleagues are now desperate to order some food having been forced to finalise our definitions before I allowed us to sit down for dinner.

Tuesday, 5 December 2017

Inventory Management

On my first real engagement as a ThoughtWorker, before we started doing any delivery work, my colleague Chris and I were in a meeting with some architects and business stakeholders looking at their backlog. It was large. Very large. Chris started pointing at some items near the top and asking when they might get done. "Soon", "In the next few weeks", "in this or the next sprint" were typical answers.

Next Chris pointed at some stuff just under the fold and asked the same question. "Maybe in the new year" (this was late October), "Depends if anything else comes up", "Probably in the plan for Q1" were typical of the slightly more vague answers we got at this stage.

Then Chris started asking about some stuff that was a few pages of scrolling further on, nearer the bottom of the overall backlog. Now the answers were more like "That may never get done", "Can't see that ever being a priority", "I have no idea what that even means" were the type of answers we got at this stage.

At this point Chris made what I thought at the time was a rather controversial suggestion. He asked if they had considered deleting everything. The whole backlog (he may have suggested reprieving the stuff in progress and a little bit more, I can't remember, but it sounds more dramatic if he proposed torching the whole lot). This was met with howls of protest from our clients. "We need this stuff!", "Everything on this list is business critical!", "We've promised this stuff to the business!". One of us asked how long something had been on the backlog. The tool was able to tell us it was in the order of 2 years. "How has the business managed without this business critical functionality for 2 years?" was a rather ironically posed question at this stage.

I do remember asking Chris afterwards why he was advising them to do this. The answer I got was "it's inventory". Unfortunately, I either didn't have the time or I didn't press to get a fuller explanation of why inventory was a bad thing. I hadn't read much, if anything, about lean manufacturing or the TPS at the time, and I certainly hadn't read the Goal, so I was probably associating inventory in my mind as something that was an asset (stock in hand), not a liability.

I'm not sure how that one ended up. I wasn't close to the further discussions when we started delivering and I left that client a few months later. As I was working on completely new functionality I never had to go near their backlog so I guess I just stopped immediately caring about why we should care so much.

Two years later I saw exactly what I didn't seen then. I was moved to a new project and told that there was a problem. This team that I was being asked to work with was having a problem moving stuff across their board. We are responsible for live system defects and in the months prior to me landing here the number of outstanding defects had risen slightly despite the number of new defects raised to the team being in successive months, 45 then 30 then 20 then 10. Clearly something was wrong with the flow of items across the team's board.

When I arrived I thought it might take me a few weeks to discover what problems existed. In the first week I noticed that several people in the team were spending an extraordinary amount of time looking at the card management system, updating cards with various numbers, extracting data from it and preparing reports for consumption by various people. I don't know when it started but clearly at some point somebody in the business asked this team for information about when stuff might be fixed without considering the consequences of how those answers might get produced.

I went to a meeting with 8 people in it that lasted an hour. In this meeting we reported to these people various things that they could have found out by looking on the card management system (they all had access, I checked). After that meeting I asked a few people in the team how much time they spent on what I was now recognising as inventory management. I was shocked by the answer. Some of the team were spending half their time on this type of inventory management activity!

So what did we do? In the next meeting I suggested to the business stakeholders that they were asking for all of these updates because at some point in the past they lost confidence in our ability to deal with defects in a timely fashion. This was agreed. I then postulated that they wouldn't care about these reports if we were dealing with defects in days or hours instead of weeks or months. Again, they agreed. Then I pointed out, which they probably weren't previously aware of, that we were spending so much time on servicing their reporting "requirements" that it was seriously compromising our ability to do the work that they were asking us to report on. So I asked if they minded trusting us for a little while. Could we drop all the reporting stuff as of now and then talk again in a few weeks when hopefully we'll be able to demonstrate an improvement. All of this was agreed by all of the teams we deal with.

Three weeks later and the signs are good. We've decreased the count of outstanding defects from about 70 to about 45. We have no live category 1 or 2 defects. Morale in the team is considerably improved. Nobody in the business has asked where their reports are. I am hugely simplifying of course. We also put in place a number of other things to help our team. This felt like the biggest thing though.

So for the first time I could see through direct experience why Chris was so keen to remove (or at least reduce) the backlog. The backlog is inventory. Inventory needs inventory management. Inventory management does not return value to the business. So a big backlog is bad.

I guess in conclusion I'd say if you are part of a delivery team and you find that you are spending lots of time managing inventory then ask yourself why. My advice would be not to bother jumping to these reporting "requirements". The data is probably there in your card management system or your wall. Explain to the business how inventory management stops you doing work that returns value to the business and respectfully ask if you can concentrate on valuable work. It certainly helped for us!

Wednesday, 20 September 2017

Risk Management Theatre

Process Theatre?

Some time ago I put some placeholder headings on my blog for some thoughts I was having. One of them was "process theatre" which I was never happy with. Before I dive into it, some historical context...

Security Theatre

I think a lot of people are familiar with the concept of Security Theatre. This is the practice of investing in measures that give the impression of providing security when in fact they do little to improve actual security. We see this in the UK with armed police patrolling London's transport hubs. These people do a wonderful job I'm sure but they will not prevent attacks. The real work is done behind the scenes by intelligence people. I guess the problem is (for some people, not me) that this work is not visible.

"Security Theatre" has worked its way into the IT lexicon to describe things that happen that give somebody somewhere some comfort that things are all OK but may not actually add value in an Agile environment. Consider the insistence of many "infrastructure" teams on installing virus checking software on every production instance. This may have had some merit back in the day of real metal servers but it has no merit now. I've been involved in teams who have to install virus checking software every time we spin up a new instance in AWS. This adds minutes to the start up time and hence the deploy time. I have never known this virus checking software find a virus or highlight any issue. We still have to do it though because it is on somebody's checklist somewhere.

So Security Theatre is stuff that looks like security but isn't. In fact it is probably worthless. This is why I was always unhappy with "process theatre" because, whilst in my mind it was describing a worthless process, it is definitely a process.

Reactive Processes

On my last 3 major engagements I worked for mature organisations, including one bank, who were in various states of confusion, inability to innovate and general lack of corporate agility. This type of work is often dubbed as "Agile Transformation" or "Digital Transformation", certainly "transformation" needs to be in there somewhere.

The big thing that I kept seeing over and over again were processes that had to be followed no matter what. Such processes were (probably) created in reaction to some bad event that had real consequences at some point in the distant past. The business responds by installing all sorts of governance around that thing which is evermore regarded as risky. Teams then evolve to own parts of this process. Over time the original intent of the regulation is lost. The teams that manage it now exist for the purpose of that process. There is no knowledge, or desire, to understand what outcome was originally being supported. The end state is that entire teams of people exist whose day to day job involves servicing a check list to ensure that if (when) things go wrong, they don't get blamed.

So I am grateful to my colleague, Robin Weston, who introduced me to the phrase, Risk Management Theatre, apparently coined by our esteemed ex colleague, Jez Humble, to describe such processes. This is much better than what I was thinking. What we have is a process that is seen by some to manage a particular risk but which in fact does nothing to manage that risk. In fact in some cases it actually makes it worse.

So I was reassured that what I had observed and thought about was a thing. So I've been thinking about it a lot in the course of my consulting work.

Example - Code Freezes and Release Cycles

If you have worked in software delivery for any length of time you will have come across (unless you are very lucky) the "death spiral" of code freeze - testing period - release to production - pray - work late and work on weekends to fix stuff - throw out fixes - rinse and repeat etc etc.

Long before Agile was a thing somebody released some code that broke something in production. This was probably before TDD was a thing, maybe there weren't even any kind of unit tests. Old bugs were reintroduced, nobody really knew what had changed, nobody could understand why it didn't work in production because "it worked on my machine" etc etc...

In response to this undeniably bad happening the business decided that it needed to test its releases more thoroughly. This seems like a reasonable response, indeed in 2004 it may well have been a reasonable response. So they create a test team somewhere. In order to do a release now you have to build your application, put it in some environment for testing and have this test team run through their tests scripts for a prescribed period before each release. Note that after you've built into this test environment you cannot make any further changes to the code that will be released (unless they are critical bug fixes), the code freeze. This is so that everybody can be sure that the test team is testing the stuff that will end up in production.

Ten years later this governance process still exists even though software development practices have moved on. We now have TDD, pair programming, cross functional teams, continuous integration and continuous delivery. We now understand what we have changed much better and moreover we have tested it at the unit level, the integration level and the user journey level. One of the big factors in our confidence is that we changed very little. This means we know what changed, we know what we needed to test and we know how to undo it very quickly if something somehow slipped through the net.

If we still have to go through code freeze and a testing cycle what happens? We try to cram as many changes as we can into the codebase before the code freeze. We cut corners on our Agile process to beat the deadline. We start to game the process by forcing new features past the code freeze by pretending they are bug fixes. We end up doing a big bang, waterfall style release. This is precisely the thing that caused the original problem. We have good solid practices in place that mean we don't need this whole process but the insistence of somebody, somewhere that that process is necessary perpetuates the exact behaviour that made it necessary in the first place. This is why I call this a "death spiral" - once it starts it is very hard to stop.

Corporate Immune System

So why do these teams and processes not get swept away? I think there are many answers, and I don't have all of them by any stretch. A good summary of some of the reasons can be found in the Corporate Immune System.

The organisation has evolved many processes, they have to be followed. There may be a blame culture within the organisation which prevents bold, innovative, employees from challenging the status quo. They first think of avoiding blame and second think of adding value. Innovation means change, which is something to fear for many people. There are managers, or even CXOs, who are heavily invested in the people supporting some of the risk management theatre. These often powerful voices argue strongly for the continued existence of the process that they curate citing examples from ancient history to show their worth. Other people have written far more eloquently and far more knowledgeably than I about the Corporate Immune System. I'm not saying the corporate immune system, or its side effects, are the only cause of the continuance of risk management theatre, but it certainly doesn't help!

How do we break the cycle of Risk Management Theatre?

I haven't fully formulated my thoughts on solutions yet. I have had varying degrees of success in the teams I worked with on my previous engagements. I'm now working in the public sector which introduces a whole new dimension of dysfunction that I hadn't previously seen. This is what prompted me to get my thoughts down about Risk Management Theatre as they stand. I want to take that as a baseline to hopefully move forward with this new client and hopefully come up with some solutions that may help even in the public sector. That is very much a work in progress!

My best answer at the moment is to reason with people involved in Risk Management Theatre about the outcomes they are supporting. If you can find a receptive audience, with an appetite for positive change, they should be willing to reason out the answer to "what outcome are you supporting" and extrapolate that thinking on to the question of whether the process they are using is the best way to achieve that outcome.

Customer focus is a great reasoning tool here as well. If you can ask the question above in terms of customer focus, i.e. "what customer facing outcome are you supporting with this process?" this can not only help an individual to reason about a single process but it can also help resolve a conflict between opposing processes and goals. For example, we have had success using the customer as a reasoning tool to resolve the tension between the development team who wants rapid change and the infrastructure team who oppose all change.

I will return to this subject when I understand better how to challenge (and hopefully reduce) risk management theatre in a public sector environment that cares little for any customer and may not even have a clear understanding or consensus about who their customers are.

Sunday, 11 June 2017


Recently I've had a few conversations along the lines of "what is architecture?" The natural follow on to that question is "what is an architect?" (I'll come back to that later).

Firstly, what is architecture? This is an interesting one. Depending on who I speak to I may get very different answers. It may well come down to the type of organisation people work in or perhaps the role they play within the organisation.

The best, or at least the most succinct, answer I've come across is that architecture is any decision that is hard to change later. This sounds very good to me because it plays to my feelings about drawing out diagrams and discussing a big picture and then talking over the consequences of arrows going from one place to another and what may happen if that bit is different and how that could affect the other bits it touches. But this definition also plays to my prejudice about what an architect should be. If we accept that architecture is a decision that is hard to change later then we must also believe that an architect makes such decisions or is responsible for such decisions. This idea would also closely align with how we think of as a bricks and mortar, as opposed to technology, architect.

But how often are people who either style themselves as architects or whose job title contains the word "architect" doing this kind of work, making these kind of decisions, and little else?

In my personal experience I have come across 2 other, more common, types of architects.

Firstly, it is a job title bestowed on software developers after they have been designated as senior developers. This often involves no real change in duties except more management. Sometimes there may be an "architecture group" which the architects contribute to. The architecture group is responsible for architecture decisions which in practice means "anything we do that affects more than one team".

Secondly, there are "architects" who spend their time trawling through legacy code and reading legacy (probably out of date) documentation in order to understand the existing technology landscape of their organisation. These people probably don't write code and possibly rarely even talk to people who write code. They explain, or attempt to explain, to development teams (or BAs) how things are and therefore what constraints exist on teams that attempt to create value for the organisation. These people are architectologists.

I'm interested at the moment in architectology. Why is it necessary and what does it say about the organisation that has them? The first question can be easily answered. You need them if you have a lot of legacy and a lot of knowledge silos. Somebody has to be there to help developers or BAs traverse the organisational silos in order to deliver value to the business.

What does it say about the organisation that has architectologists? Are they valuable or is there function waste? I haven't got a good answer to this question yet but instinctively it feels to me like they are waste. Instead of helping teams to traverse the silos and integrate to the legacy using the antiquated interfaces that exist it feels like the investment should be in decoupling the systems and creating a series of self service APIs that can be consumed by value adding applications. I'm currently investigating this idea more at my current client so hopefully we'll get to a better state and a better understanding of how we can get real value from the architects.

Thursday, 4 May 2017

Things I do in real life that show I'm a programmer

Sometimes the way I talk, the way I interact with people or just the way I do stuff betrays (at least in my mind) my background as a software developer.

Endless Refactoring

I am constantly annoyed by how inefficiently my wife loads the dishwasher. There are some spaces that are clearly suited to the pasta bowls and the dinner plates, some that are better suited to the cereal bowls. More than that, if you load the pasta bowls from the right and the dinner plates from the left, you can use each space on that row. If you load the pasta bowls from the left you cannot load dinner plates to the right of those spaces because of the way the bowls are shaped. This is really obvious. It is also simple. And yet, no matter how many times I point it out, she always does it wrong. The result of this is that the dishwasher appears full when it isn't. A simple re-organisation of the contents makes the space available that was otherwise wasted. I therefore constantly refactor the dishwasher after my wife has put stuff in it. I find I cannot just put more stuff in. If she puts a pasta bowl in the wrong position and it is the only thing in there, I HAVE to move it. I guess this is because I know from experience that if you leave smells lying around they morph into a horrible mess before you know it.

See also refactoring the fridge and the (very few) shelves allocated to me in the bedroom wardrobe.

Optimising Journeys

When you work in London there are many ways to get from one place to another. Many years ago a friend of mine (who is from the midlands and back then was not at all familiar with London) told me that he came to London for an interview and the instructions simply said "nearest Tube station, Euston Square". This was long before smart phones or Google Maps. So he got to Euston Station and looked on an Underground map. He saw that to get to Euston Square he needed to go to King's Cross (one stop on the Victoria Line) then change to the Circle Line and go one stop to Euston Square. The famous tube map gives no indication of how long it may take to switch lines at any station. It also gives no real indication of surface distance. So he made his journey and emerged from Euston Square about 20 minutes later. The first thing he saw was the street sign that says "Euston Station - 300 yards".

Not all journeys are so obviously sub optimal. But I have always tried to know where the exits are from the platform that I'm going to arrive at so that I can get in the most appropriate carriage. I love the latest version of London Midland's application because it tells me which platform the trains are leaving Euston by and thus which entrance to the station is optimal. Should I really be concerned with optimising my journeys to this extent?


I guess this is more of an Agile thing than strictly speaking a developer thing. After a few years of indulging in blamestorming and defensiveness I started to be involved in the culture of continuous improvement as my previous employer evolved. When I moved to ThoughtWorks I finally shed the last vestiges of defensiveness and started to view regular retrospectives and feedback as opportunities to learn and improve. The trouble is when I try to engage people who aren't from this background in conversations about what went wrong or what could be improved or how we can avoid excessive risk, then I get a wall of defensiveness and accusations that I'm attacking people. Oh how I wish people could detach from the obviously over emotional reactions that have to advice or criticism and start to engage with opportunities to improve.

Am I expecting too much of people who haven't gone through an Agile transformation?