Better than best (practices)

Practices work when they’re applied effectively and appropriately, adapting solutions to your own particular needs.

Better than best (practices)

Last time we talked about the kinds of best practices that tech orgs have tried over the past two decades, and how well they’ve worked out. It all seems so promising – so why do we still have problems?

The hard answer is that no practice can be thrown on top of the current situation without any context and automatically fix everything. This may seem a little obvious when I say it like that, but if we really believed it, things would look different.

Practices work when they’re applied effectively and appropriately, adapting solutions to your own particular needs. Slicing the code base into smaller pieces, changing the planning process, and automation are all things that happen in the context of your existing technology stack and organization. In addition, remember that your needs will change over time. So a practice that solves problems right now may become a pain point in the future.

We make a big mistake when we try to solve our people problems with technology, or fix the software by restructuring the organization. Both parts are linked. A new team structure or development process will change the kind of software you create. Trying to decompose your software stack into services will only succeed to the extent that your organization, planning, and communication keep up. Any solution needs to take both sides of the problem into account.

Now that we have more understanding of what we’re dealing with, what’s the path forward?

Ask why a practice is there. It might be a little embarrassing, like a rewrite that happened because you were following a design trend that was very hot at the conferences everyone went to a couple years ago. But more likely, something wasn’t working, and this is the tool you reached for to fix it.

Find the underlying problems that need to be solved. That might involve safety, reliability, scaling, or communication breakdowns. Try to pinpoint specific requirements and goals.

Examine the constraints: do you have the capacity to make changes? What else needs to happen? Grand plans go nowhere if everyone is overbooked and there’s no ability to get it done.

Look at everyone who will be affected, and get them talking about their needs. Who should be at the table? Well, it would help to have some way to discover who the owners and contributors are… (We can help with that!)

Let go of the idea of doing things the “best” way according to some outside label. By its nature, best is relative. If it doesn’t help you get where you’re going, is it even worth caring about? “Better” will go a long way, especially if you can also arrive at “done”.

Throw out the things that you can agree feel like bullshit. This ought to be satisfying and give everyone the sense of a fresh start.

Make incremental changes and use the results to steer you forward. Bite-size pieces, not reinventing the world.

If this seems like a lot, don’t worry. We’ll take it step by step. Next time I’ll be talking about how to start thinking about the shape of your own particular situation and what needs it indicates.

Photo credit: CC-BY #WOCinTech Chat

What could shared context mean for your SDLC?

Learn more strategies and benefits.

Thanks, please check your inbox
Oops! Something went wrong.