Categories
development programming

Modular doesn’t mean interchangeable

Microservices are great. Containers are great. Packages are great. Objects are great. Functions are great. At each level they encapsulate functionality into re-usable modules. One place to make changes. One place to optimise. One abstraction to help you move to the best layer.

For the sake of argument though, I’m going to focus on microservices, specifically those accessed via an API, as that’s what I know best.

Interfaces and APIs are good for test harnesses, but isolating systems for your own benefit (to make modules open for extension but closed for change) bears no relation to making that module useful to other systems.

Sure, I could rip out the modules that contain business logic, and package it as a framework, but that doesn’t mean it’s useful for anyone else. It could well be an inner system . It may still be coupled to domain/architectural knowledge that make it too valuable to swap out. There could be an implicit dependency for just that one version of that one tool.

It is of course possible to make modules re-usable, but they have to be designed that way, whether up front, or evolved. And anything interchangeable has to be tested, in at least 2 conditions, to make sure it’s suitably robust.

Design an interface. Evolve the design. But don’t mistake solving one problem in one place for a general solution. And don’t think that adding an interface is all it takes to turn a local SQLite data store into a cloud file system repository.

Categories
code development programming

Software Development as a Christmas Story

Gingerbread Christmas Tree
Oh Tanenbaum

We decorated the house for Christmas. A smaller project than most of the software I’ve worked on, but a useful reflection.

The Cost of context switching

Sometimes, in the middle of one task, you need to do another. Either because you were interrupted, or because you weren’t prepared. Consider the tree, a tall tree, one you need a ladder to decorate. But you left the 🌟 in the attic.

You don’t just have the cost of picking up the star, you need to get down the ladder, fold it up, carry it upstairs, open the attic, unfold the ladder, climb to the attic, find the star, then pick it up and unwind all the other steps just to get back where you stated before you can continue the task of putting the Star on the tree.

It’s just a minute to get the star…

Yak shaving

Sometimes it’s more than just one thing. Sometimes to get to where you need to go, there’s a cascade of other tasks.

You want to put the tree up, but it’s the first time you’ve had a real tree, so you need a new base. It’s bigger than last year’s tree, so your lights don’t fit. So you need to go to the shops. But you need to fill up your car. And the tyre pressure warning light comes on so you need to top them up. And you need to check the tread depth whilst you’re there, and so on.

Programming in a nutshell

Performance at scale

Our tree stood up fine when it was delivered. But as it scaled out and the branches widened, it pushed against the wall, making it unstable in the condensed space. It fell over.

Luckily no lights or baubles were using it at the time, but it’s an interesting challenge holding up a heavy tree in one hand, trying to adjust it’s position with the other hand, as I avoided the puddles of water in the floor as my wife mopped them up. If you’ve ever worked support, this may sound familiar.

Turns out that it was harder to stabilise than I anticipated.

The branches were unevenly partitioned, providing more load on one side, so I had to stabilise it against the wall. And the tree was almost a foot taller than expected, which turned it out to be 2 foot taller than the base was rated for.

We upgraded the base to handle the load. It’s bigger than we need.

Technical debt

I have some old pre-LED tree lights and they slowly fail so each year I replace the unlit ones from the packet of spares but I haven’t been replacing the spares. Eventually, they will run out, and the spares will no longer be available. I’ll have to throw them all out and start again.

The new led ones don’t let me replace them individually. But they last longer and are cheaper to run.

Which debt is easier to live with?

With a big tree, those old lights aren’t long enough. So, do I buy another set for the rest of the tree that doesn’t match them, or throw out the existing ones and buy a longer set? The latter looks better, but throws out the sunk cost along with the lights.

You know computers, can you look at this for me?

No, I can’t fix your tree. I can navigate a garden centre. I know enough physics to keep a tree upright, eventually, and safely put the angel on, but I’ve no Idea how to grow one, or what that weird stand with 17 gears you bought does, or how to assemble your plastic one. And I’ve no idea what that bug in the tree is.

Merry Christmas. Catch you all in the New Year.

Categories
development programming

Somebody else’s problem

Sometimes dividing tasks creates inefficiency. When one person both cooks and cleans, they tend to create less washing up than if the tasks are divided, because washing becomes “somebody else’s problem”. However, when one person washes and the other dries, the load is equivalent. This setup can be prone to stoppages when the drainer is empty and the washer is trying to get that stubborn burnt bit off the pan, at which point any good ToC practitioner will ask the drier-upper to help with the washing to maintain throughput.

When teams are divided by layer instead of features, the interface between them becomes a fracture because each team has context missing from the other. Data has the wrong shape, validation requires fields that can’t be captured. If you build both sides, the transition is smooth.

When developers test, they can focus on smaller, independent chunks, which means fewer tests with greater coverage. Writing integration tests for complex calculations is painful and slow. Testing those same calculations as an xUnit Theory is cleaner and faster.

Specialists are great, but where is specialisation causing fractures and more work?

Categories
development leadership

CodeCraftConf follow-up : notes on growing a team

Whilst I have a few thoughts I’m still processing after the whirlwind of fantastic insights I got from CodeCraftConf, I wanted to capture some of the highlights from some of the answers to my questions on Growing a Team.

Many thanks to everyone who came to the session. Lots of thoughts coming out of the conference.

When is it time to grow your team?

  • You never grow a team, you create a new one.
  • There’s always too much work, you should grow when you have capacity, so you don’t put new starts off

How do you deal with resistance from existing team members?

  • Communicate clearly and address concerns (e.g, time to mentor)
  • Involve team early
  • Do you have a choice who joins?

Is it more important to find a culture fit or build a diverse team?

  • Do candidates know what they’re signing up for?
  • Introvert vs extrovert (see also hiring practice)
  • Interviews should be structured to filter out arseholes – do they have empathy (or have they been taught to suppress it)
  • Every new hire should bring the level up
  • Don’t just hire for technical skill
  • Diversify your interview pool

What is your biggest worry with your current team size, or with growing your current team?

  • Are you doing Health Checks? Survey staff regularly
  • Make sure the bigger team, outside your daily work, understand the culture – it only feeds from top down
  • Fear of churn
  • Loss of culture
  • Try to understand
  • Make the culture explicit

What practices do you use to ensure sustainable growth?

  • Pair a lot, reflect (e.g. retro)
  • face-to-face regularly, even if it’s video
  • Values workshop – does everyone share them?
  • Social convenor to ensure cohesion
  • Slack channel dedicated to positive feedback on living the values
  • Office/company changes should have their own backlog with an open grooming process so priorities are explicit

How long does it take to integrate someone new?

  • Be careful about language
  • Train everyone in personal skills
  • Listen even when you disagree
  • lack of ego
  • Culture changes people
  • What personalities do you want?
Power corrupts
Categories
development leadership

CodeCraftConf 2018 : Successfully Growing A Team

Thanks to everyone who came to my CodeCraftConf session today, and to the organisers for all their hard work. Here’s the questions I asked, and I’ll follow up with my thoughts from the discussion.

Successfully Growing A Team

  1. When is it time to grow your team?
  2. How do you deal with resistance from existing team members?
  3. Is it more important to find a culture fit or build a diverse team?
  4. What is your biggest worry with your current team size, or with growing your current team?
  5. How frequently can you add new people to your team?
  6. How long does it take to integrate someone new?
  7. What practices do you use to ensure sustainable growth?
  8. How do you know when a team is too big?
  9. How do you split a team that’s grown too big?
  10. How do you grow a team when the existing members are already overworked?
  11. How long is your recruitment pipeline in terms of short-term planning (getting people in the door) and long-term planning (having the right team in place for next year or 5 years?
  12. How do you recruit outside your specialty?
Categories
code leadership

CodeCraft – Architecting Teams Notes and follow-up

Thanks to everyone who came to the CodeCraft guided conversation last week. I’ve added some notes to the questions below to carry on the discussion, and there’s a few topics I want to revisit in this blog, and in DDD Scotland if my talk is accepted.

The code craft team did a great job of reviewing and improving the questions so thanks to them, but I think in the very busy session itself, some of the questions were too ambiguous. For example, when I was thinking about goals, I was thinking about project goals and strategy goals rather than just “Make more money”, but I suspect that’s as much to do with the ambiguity many people have about their company strategy and culture in general.

It was also interesting to me to hear how agile is interpreted. The agile manifesto is clear that people take priority over procedures, and software over documentation, but explicitly the authors “still value the things on the right”. So it’s not about no procedures, and no documentation (please tell me you have coding standards), it’s about the right ones to support the people, the delivery of working software, etc. rather than documentation in its own right. Indeed, there are a number of explicit rules that an agile team needs in order to function. Is there a framework? What is the lifecycle of a unit of work? What language are we using? Not all of it needs to be documented, but some of it absolutely does, especially if you want to understand and improve it, and remove the rules you no longer need.

Be wary of anything that interrupts transparency, whether it’s Chinese walls, secret tasks, hidden agendas or ninja developers who work in the shadows and surprise everyone when they’re least expecting it.

And it’s never just enough to say who you are and what you do. Promote, encourage, and challenge. Be proud to be a diverse employer, to be wheelchair accessible, to have staff with more than 2 years real world experience, and welcoming to fresh faces with new ideas.

Trust. Respect. Communicate.


As a general point, I’m thinking of a team as “the people you work regularly with, usually daily”.

  1. How do you keep track of your team and the company goals?
  2. How does your team manage risk to and changes to those goals?
    • Pre-mortem
    • Chaos monkey
    • Agile “threw away risk register and other important documents”
  3. What makes a great team?
    • People
    • Feel comfortable
    • Trust
    • Communication
    • Balance
    • Good Leader
    • Sustainable development
    • Transparency
    • Healthy Debate
    • Growth and change
    • Common Goals
    • Motivation tailored to each person
    • Rules
      • Raise concerns
      • Feedback should be timely and structured
      • Coding standards
      • Process rules (e.g. how do we report a story can’t be implemented, what’s the weekly schedule)
  4. What would you change about your current team?
    • Management
      • Decisions made outside the team, not taking input from the team
      • Coaching developers to talk to management
      • Wrong person promoted to lead
    • Too many rules
      • “Because we’ve always done that”
      • Needs the context of why that rule exists
    • Clear roles
    • Respect for decisions the team has made
    • No secret tasks
    • Co-located, or remote, not mixed.
    • No “them and us”
      • Manager vs developer
      • Techie vs non-techie
  5. What makes you feel unsafe in a team?
    • Lack of:
      • Support
      • Communication
      • Respect
      • Goals
    • Secret genius / hero developer who does their own thing
    • Decisions made without buy-in
    • Teams without source control
    • No tests
    • Secrets
    • Success at the expense of others
    • Developers are not “resources”
      • And managers are not “overhead”
    • Fear
    • Stagnation
  6. How well would your current team survive a conflict?
    • To survive, have Strong Opinions, Weakly Held
    • Have a “naughty step” project for someone who doesn’t follow the rules, or doesn’t respect the team
    • Avoid imbalance in workloads that lead to loading stress onto key individuals
  7. Should teams change when projects change?
    • Teams should be mixed to avoid stagnation, but not completely break them up
    • Good teams can inspire others
    • Every good team cares about the product they produce
  8. How does the culture of a team change as it grows?
    • Negatively. Easily leads to “Us vs Them” (e.g. backend vs frontend vs DBAs, developers vs testers)
    • Lines of communication fail, especially as distance increases.
    • Old vs new – “I prefered the company when it was smaller”
    • T-shaped individuals are better collaborators
    • Tribe structures can help by allowing multiple communication lines
  9. What kinds of diversity should we seek in the teams we work in?
    • Diverse teams build diverse products
  10. Should we recruit to enforce the current culture or diversify it?
    • Put accessibility positively on ad when true (wheelchair accessible, BSL-friendly)
    • Do you know the current culture?
    • What is “culture fit”?
    • Does anyone know your company values? (not just the 5 Apprentice team names on the posters around the office)
    • Get job adverts reviewed by as diverse a team as possible
    • Diversify where the jobs are advertised
    • Not every candidate has 20 hours for a coding exercise, or wants to give up 2 holidays to pair with you
    • Coding review should be blind
  11. What one thing can a leader do to make a team great?
    • Trust
    • Delegate authority and empower the team
    • Protect the team
    • “Reading the room” understand what’s not being said so you can investigate
    • Push everyone to improve (including yourself)
    • Empathy
    • Happy people
    • Communicate
  12. Are effective teams a democracy or a dictatorship?

codecraftuk-sessions/architecting-teams.md at master · craignicol/codecraftuk-sessions · GitHub

Categories
code leadership

CodeCraft – Architecting Teams

Thanks to everyone who came to the CodeCraft guided conversation yesterday. If you want to reconsider any of the questions yourself, you’ll find them below.


As a general point, I’m thinking of a team as “the people you work regularly with, usually daily”.

  1. How do you keep track of your team and the company goals?
  2. How does your team manage risk to and changes to those goals?
  3. What makes a great team?
  4. What would you change about your current team?
  5. What makes you feel unsafe in a team?
  6. How well would your current team survive a conflict?
  7. Should teams change when projects change?
  8. How does the culture of a team change as it grows?
  9. What kinds of diversity should we seek in the teams we work in?
  10. Should we recruit to enforce the current culture or diversify it?
  11. What one thing can a leader do to make a team great?
  12. Are effective teams a democracy or a dictatorship?

codecraftuk-sessions/architecting-teams.md at master · craignicol/codecraftuk-sessions · GitHub

Categories
leadership Uncategorized

As a team lead …

As a team lead you need to know your team. You need to understand people. You don’t need to second guess them, you don’t need to micromanage them, but know what motivates them. Know what they need to perform at their best.

What tools do they covet? What routines matter? Do they need precision? Do they value gym time? Do they aspire to learn?

Understand their 6 month and their 5 year plan and help them achieve it. Make sure they know the team 6 month and 5 year plan and where they fit into it, and where that fits in the company plan.

Value them, and ensure they feel valued. Listen. Give them the grace to accept that which they cannot change but be sure they know you’d change it if you could.

Change what you can. Make their lives easier. Help them aspire to your job, even if they may fear the conflicts you protect them from. Keep your head whilst those about you are losing theirs.

Be the best team you can be. Discover the greatness in everyone. Play to strengths to see them through weaknesses. Move people. Change their roles. Find your gardeners and your innovators and Train them to replace you, because for certain times they will need to. Do not become vain or bitter for always there will be greater or lesser persons than yourself.

Let go. Trust them. Trust yourself. Let them do their job so you can do yours.

But lead, don’t follow. Have strong opinions, weakly held when a better way presents itself.

Let data guide you but not be your master. Don’t trust your gut.

Don’t be a stranger and make a full commitment to your team.

And make sure everyone knows the standards.

Categories
development

Reducing waste by making your goals visible

Metrics are good, but they’re not enough. If you want metrics to drive change, they need to be visible. Not just to managers, but to the team. The right metrics, visible to the team, drive improvement. Visible only to management, drive control. Visible to no-one, drive nothing.

Good metrics need to be communicated clearly and persistently. There needs to be a continual focus on whatever the priorities are. If it’s out of sight, it will be out of mind. If it’s digital, rescue it from individual screens that are easily covered up.

It’s why kanban boards can be so effective when used well. It’s easy to see when the team is taking on too much work, or where there’s a queue waiting for tasks to be pulled. The board radiates information to the team, about how much work is in progress, and who is working on what. It becomes the centre of communication about tasks and removing waste. Make it physical, if you like, and the team is co-located. Use Post-its. Let dog ears and grubbiness indicate age. Do your backlog pruning via environmental effects – older & more used notes are more likely to fail behind the radiator and get lost.

Put (work-related) personal tasks on there too. Keep yourself honest. It’s good for the team to know you’re reviewing CVs, or preparing for that strategy meeting, or learning Haskell the hard way.

But keep it clear. Use a Kanban if WIP or queueing are your key metrics. Use Scrum if velocity and deadlines are key. Use a dashboard if that makes your priorities and progress clearer.

And make sure your key priorities (4 or less please) are visible at a glance for the team, and easy for anyone in the team to explain to a passerby. They don’t need detail, but pointing to a big pile of waiting tasks to justify recruiting a new tester is a clear message.

Categories
development leadership

Measuring the wrong thing

Process improvement requires measurements. How do you know what to improve if you can’t see where things aren’t working, and how do you know you’ve made the right change without seeing those numbers going in the right direction?

But measuring doesn’t mean you’re measuring the right thing, and measuring the wrong thing can lead to the wrong outcomes, and can be very harmful (see Liz Keogh’s talk on perverse incentives )

The key to the success of any metric is that it is owned by the team so they have complete control over the changes needed to affect it, so they feel ownership, and that improving the metric has a useful business outcome.

Metrics that I’ve found useful in the past include:

Number of bugs introduced by a release.

This is a tricky one to work with because it can easily be a perverse incentive, and the feedback cycle can be slow, especially with the usual 6-12 month release cadence. However, on one waterfall project I took over there was a strong negative perception of the quality of the code, and big count was a useful proxy as the customer had access to JIRA so the big list was already visible. Reducing this number was a combined effort where testers and developers had to approve requirements, developers and testers invested in automated testing at all levels, and testers joined the developer daily stand-up in order to catch bugs before they were released “have you checked that page in Welsh?“, “We found problems on that page last time because IE was too slow“.

Number of releases per month.

On an agile project we noticed that releases were getting held up because testing was slow and produced a lot of rework, which were then tested against more features that had been pulled from the backlog, increasing testing time. Each release also took half a day, so we had to schedule them carefully.

So we set a goal of focusing on releases for a month and measuring how many we did. There were other measures within that, such as monitoring work in progress on the testers, time taken to do a release, and cycle time from start of development to live release, but they all drove the big number, visible to the whole company, of more quality releases.

Questions answered per day.

This can be a very useful metric for research projects, especially when following a fail fast approach, when you want to prove something can’t be done before you invest in doing it. In order to do that, you need lots of questions with quick answers, to accelerate learning. Any answer, positive or negative, is progress. It means we have learned something.

“I cheerily assured him that we had learned something.
For we had learned for a certainty that the thing couldn’t be done
that way, and that we would have to try some other way.” – Thomas Edison

Age of Pull Requests

Successful agile projects rely on peer review, either via pairing, or a formal review process such as git PRs (and I won’t discuss that in this post). However, when we started working with these on one project, we discovered that we were building up a large debt of Work In Progress because the team wasn’t incentivised to review each other’s code, so one of the developers set up a nag bot for any PR older than 4 days. It lasted 2 weeks before it was no longer needed.

What about you?

What metrics have you used to incentivise the team? What problem were you trying to solve, and did the metric work?