If it hurts, stop doing it: the wrong process

If something is painful, should you do more of it? Not if it’s painful because you have the wrong tool.

Sometimes though, it doesn’t matter what the tool is, there’s something more fundamental at play. A process that exists only because one thing went slightly wrong years ago. And rather than implementing a process to correct mistakes, somebody tried to prevent them.

Just like technical debt, this process debt adds pain to every feature, every bug fix, or every release. That pain can be removed by removing the process.

It’s painful because you shouldn’t be doing it

Does your test plan or your requirements sheet still specify IE as a supported browser? If Microsoft doesn’t support it why should you?

Are you spending all your time monitoring your staff, making sure they’re working when they’re not in the office? Do you struggle getting the right reports? Do you feel resentment from your staff even though it’s in their best interest? Or have you tried trusting them?

Is every release delayed because the database team and the security team have to review all code, and they’re already overstretched? Have you asked them how to provide confidence with less manual intervention? How to minimise the impact any change could make? How to add automation for common areas? How to train the developers to fix common issues upstream before it gets to the frontline teams?

Have you ever thought about deleting a process that isn’t adding anything? About making things simpler?

`The Untapped science of less : Inquiring Minds podcast’

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?

Sometimes the greatest challenge of leadership is making your boss understand what you do all day

Everyone loves a maverick. The one who bends the rules, who gets the job done. Who leaves fireworks in his wake (it’s always a man) and doesn’t mind breaking a few chickens to make an omelette. The people who rescue the projects in a tailspin, who shout loud and carry a big stick.

What happens to the projects without fireworks? The sysadmins that don’t have to explain why they got breached? The project managers who don’t have to explain why they went over budget? The developers who aren’t in the office past midnight fixing bugs? The people who aren’t visible because they fix the problems before they become visible?

I grew up watching Formula 1 with my dad, in the era of Senna and Mansell. Senna was fiery, pushed the car to the limits, exciting to watch. Mansell was controlled, steady, hitting the right line, and easing the car in as if it was on rails. Senna looked like the hardest worker, but Mansell broke his run of world championships.

If you’re competent, if you get the job done, then people believe that your job must be easy. It’s not easy to beat a triple world champion. Sometimes you need to anchor your achievements in advance, so people understand the challenge in hindsight, especially if you are marginalized in the workforce such that your achievements are minimised.

The Difficulty Anchor

Hey underrepresented folks in technical roles! Performance review season is upon us. I want to take a few moments to remind you about some practical tips that can help you be evaluated more fairly in this and future seasons.

— Mekka 💉x7 @mekkaokereke (@mekkaokerekebye) August 9, 2018

It’s even harder once you move into any management role, success is due to your team (and be damn proud of that success), but failure falls squarely on your shoulders. If you don’t have a strong sense of your own self worth, it can hollow you out, and leave you with nothing but a thick skin.

Take on extra responsibilities, be the consistency for the team when the powers above you are a maelstrom of confusion and musical chairs. And nothing happens.

Remove obstacles and no-one sees them.

Anchor your team’s success. Quiet, dependable successes make everyone on the team happy : no drama, no overtime. But it can be hard to show the work behind the scenes that makes it look so smooth.

It’s not just a dev problem, a good sys admin is invisible, designers struggle to prove their worth (How to Prove Your Design’s Value – Hack Design
https://hackdesign.org/lessons/57-how-to-prove-your-design-s-value?utm_source=newsletter&utm_medium=email&utm_campaign=howtoproveyourdesignsvalue ).

Market yourself. I know you hate sales and marketing, you’re happy to leave it to others, but you need to give yourself the confidence to be proud of your achievements and make sure people understand what you did. Share it with your boss and your peers (you’ll need some recognition when it comes to your appraisal). Promoting yourself is not someone else’s job. Practice it. Embrace it. Be proud.

De-pluralisation: strategic blinkers

The process of de-pluralisation takes all your existing problems and combines them into one simple manageable problem: “it’s JavaScript”, “it’s Windows”, “it’s the CDO” with a simple manageable solution “kill it”. Like all simple solutions it’s almost always wrong.

“People aren’t complying with our data quality. Users keep putting in wrong email addresses.”

“The new computer system will fix that”

“Users complain that there’s too many steps to sign off expenses”

“Each step will be faster in the new computer system”

“Staff have low job satisfaction”

“New computer system!”

“Our users aren’t interested in that new feature”

“New computer system!”

“We’ve been hacked with a social engineering attack”

“NEW COMPUTER SYSTEM!”

Changing one thing is rarely the answer. There are many pain points and problems we all face day to day. It’s tempting to try and fix them all together, but unless you understand why the problem exists and what the parameters are to fix that problem, you can’t fix it.

Sometimes New Computer System (TM) will fix multiple problems, if they’ve been defined and the system has been designed to do so. But don’t expect it to fix everything because it’s new. That’s how to make people disenchanted.

If you think one system will rule them all, you may as well throw your team in the fire now before you waste time and money on a misguided transformation.

Sense and Respond by Jeff Gothelf and Josh Seiden

Sense and Respond: How Successful Organizations Listen to Customers and Create New Products Continuously by Jeff Gothelf

My rating: 5 of 5 stars

Having read Lean UX, I was expecting a good book on how organisations could deliver projects. This book is about much more than that. The authors are coming from a point of frustration where agile delivery and Lean UX projects have failed to reach their potential because the organisations surrounding them were not supportive, so this book is about how to reshape an entire organisation to meet the challenged of the modern world, with lots of positive and negative examples, which is refreshing to see in this type of book. If you’ve ever had a strategy meeting, or ever found your project success limited by your organisation, go read this book.

Easily the best book about dysfunctional organisations and organisational change I’ve read since Peopleware.

View all my reviews

Buy on Amazon UK :

Reducing waste by automation

Reducing waste is one of the key concerns of agile development, and is a defining character for Kanban, where blockages are ruthlessly identified and resolved. Timeboxing provides a low-cost means of identifying waste and a framework for tackling it, but doesn’t provide many solutions on its own.

For tasks that continually cause blockages, such as the release process, or testing, automation is a good way to eliminate the repetition, and the chance of human error. Indeed, the engineers in the audience will immediately recognise the key drivers for Continuous Deployment and Continuous Integration in the examples I’ve given.

And yet, whilst we appreciate the gains it can make, how many teams set aside specific time in their schedules for “automation” as an activity alongside “refactoring”, “upgrading dependencies” and “deleting dead code (including tests)”.

Check your backlog, and if automation, in some form, isn’t there, ask yourself why those repetitive manual steps still exist in your workflow and why they have priority over the other work you have to do.

Privacy is not your only currency

If you’re not paying, you’re the product.

But you’re not. In security, we talk about 2-factor authentication, where 2 factor is 2 out of 3 : who you are, what do you know, and what do you have. Who you are is the product, a subset of a target market for advertising, or a data point in a data collection scoop. The former requires giving up privacy, the latter less so.

Advertising is about segmenting audiences and focusing campaigns, so views and clicks both matter, to feed into demographics and success measures. Ad blocking is a double whammy – no ads displayed, and no data on you. Websites tend to argue that the former deprives them of revenue, many users argue that the latter deprives them of privacy.

What you have is money, and who you are is part of a demographic than can be monetised in order to advertise to you to get your money.

But what else do you have? If you’re on the web you have a CPU that can be used to compute something, whether it’s looking for aliens or looking for cancerous cells. If you’re happy to give up your CPU time.

Who else are you? You might be an influencer. You might be a data point in a freemium model that makes the premium model more valuable (hello, LinkedIn).

What do you know? If you’re a human you know how to read a CAPTCHA (maybe), you could know multiple languages. Maybe you know everything about porpoises and you can tell Wikipedia.

Your worth to a website isn’t always about the money you give them, or the money they can make from selling your data. It’s the way we’ve been trained to think, but there’s so much else we can do for value.

Bad change : The rock star developer and dealing with unexpected change

Have you ever worked with a developer who knows everything? The one who does a bit of tinkering in the evenings and weekends, and when the rest of the team come in, they can’t find anything in the code?

Yes, it’s a bit neater, but it’s a lot more broken, because it’s less readable, because it’s using a beta version of a library rather than the previous stable version. And one project in the solution uses different conventions to the rest.

I also tend to find the tinkered code is proof of concept with minimal testing, and little documentation. So the software diva who developed to the limit of their ability can’t tell you how it works 1 week later. They got bored and moved on. After all, there’s another Javascript framework to learn.

It’s great if you write throwaway code. If no project lasts more than a month. But that’s not the software I’ve been building. I enjoy the challenge of nurturing code that’s got a lifespan of 5, 10, 25 years or more. Not necessarily the same code, modules get rewritten, tests get added, dead code is removed, but it has to remain readable and maintainable all the time.

If you are a lead with a diva on your team, use them for research, because they will chase The Precious whenever something shiny comes into view. But when they need to get code into production, enforce your coding standards strictly. They will moan. They will sometimes throw a tantrum. If they do, you know they’re wrong, otherwise they’d have a convincing argument for doing it their way.

Standards are universal. Divas are occasionally useful idiots. Learn to spot them, and use them to your advantage without disrupting the rest of the team.

Did you have a useful week?

Did you learn something? Did you stretch yourself? Did you challenge your assumptions, or your practices? 

Do you feel like you achieved something last week? Did the frustrations inspire you to make it easier next week? Did you share them with others, in the pub, or on your blog, so others can learn from your frustration? 

Did you set new goals? Are you going to be a faster typist? Are you going to learn functional programming? This time, are you going to lose weight? 

Did you make new connections? Did you make an effort to understand the people you work with? Did you do something to strengthen your work and personal relationships? 

You don’t have to do all of that. But did you think of it? Did you write it down? Did you, in some small and agile way, improve yourself? 

Can you say to yourself, today, that you had a useful week? 

Developers are Users Too : Why the User Experience of Your API sucks #yourapisucks

Many thanks to those of you who came along to my talk on why your API sucks. There were some great discussions during and after, and I hope I’ll be seeing slightly fewer reasons to tear my hair out in the near future.

A few things that people mentioned that I want to discuss again, as they’re not on the slides.

APIs still need a view model

There was a question about the API view of your data vs the database view. A good API still follows MVC principles. Just because a View is written in JSON instead of HTML doesn’t make it a model. Isolate it, because otherwise a database change is an API change. You can use automappers to save you having to write convertors, but always create a view for your API so you can handle versions and create consistency.

There was also a big discussion on how deep the hierarchy should be, particularly relating to data obesity. And it’s a different tradeoff if you’re optimising for poor latency, where larger packets with redundant informatio make more sense, or timeliness where small packets that can be built and parsed quickly are preferred. It all depends on your users. It may be the case, as the Trello API does, that returning the deep hierarchy is a request option so that the user can decide.

User Experience doesn’t always mean asking the user

Developers will ask for lots of things that aren’t useful. Sometimes you need to discover what the user needs are. Maybe it’s a test-first design. Maybe it’s a loosely typed API to help you discover what users want to do (think Google search vs Yahoo’s hierarchy – Google is more loosely types so was more likely to return odd results, but Google had lots of data on what people were searching for that it could learn from).

Link suggestions from the audience

Thanks for these suggestions. I’ll have to try them out myself, so I’m putting them here without warranty.

Kong – to consolidate your APIs, and create the polished surface that doesn’t expose the dirty, inconsistent history behind it.

RAML – to design a typed RESTful API up front so you know what it will look like.

Heroku’s HTTP API design guide

Slides from Google Docs

Slides from Slideshare