The Tao of Suck-Driven Development (SDD)

TL;DR

Suck-Driven Development is one of the innovator's solutions.
(or at least I think Clayton Christensen would agree)

it doesn't start with next most functional thing
it starts with the next thing that sucks the most
it solves the smallest possible problem that hasn't been solved by others
- even if it's a little disconnected or doesn't accomplish the overarching goal
it doesn't get encumbered by planning
- is executive, but more intuitive than operational
it focuses on working features, not more features
- i.e. features that don't suck

Backstory

Over the years I've off-handedly used the term Suck-Driven Development to basically explain what I'd otherwise call "the real agile"^[1][2] to other developers and it seems to have always made sense in context - among those familiar with other X-Driven Development styles.

Funnily enough, I recently mentioned it to a friend / new developer who in turn asked ChatGPT for it's meaning.
(also funnily enough, the conversation was in regards to the dilemma of innovation)

Since I've only mentioned it off-handedly here and there, mostly in speech, I was surprised that it came up with a pretty decent answer:

What does "suck driven development" mean?

Suck-driven development (SDD) is a software development methodology that focuses on meeting customer requirements and expectations quickly and efficiently. It is an agile approach that emphasizes customer feedback and rapid iteration. The goal is to provide the customer with the best possible product in the smallest amount of time.

And that's the prompt for this post - to give a more formal definition (if you can call it that) to the term. Or at least to articulate it more clearly in the context of the problem it solves which is, remarkably, that of innovation.

What is Suck-Driven Development?

SDD - Suck-Driven Development for short - is an ad-hoc style of development that focuses on driving unique value into product design.

You ask yourself "What about this is the most broken? The most difficult (or impossible) to use or do? What's the thing that grates on my nerves? What really sucks about it?" and then write code that does or fixes that thing.

It's in the vein of scratching the itch and dogfooding. It's where you either are the user, or are very close to the user and empowered to unobstruct the critical path (another term that's been somewhat co-opted, but basically means "the things that must be done to accomplish a goal or user story - such as "respond to an email").

You don't start with the thing that's the most functional. No, you start with the thing that sucks the most.

Why? Because if you don't start with that thing, then you'll be halfway through your project - the part where you want to just give up - and you won't have actually solved any problem that hasn't already been solved better by existing solutions.

The Obligatory Blog Example

We've all been there.
(or at least if you haven't it's a sign of personal weakness in your communication and documentation skills, and you need to overcome it)

I'm just sitting here at my desk, wishing I had a better blog. Where do I start? Well, it needs to be the thing that sucks most about current blog systems.

There are dozens, nay, hundreds - or even thousands - of blog systems out there. If I were to think "what's a blog?", then I'd immediately put myself in a box and start planning out something that feels "blog-like" - something that "checks the boxes" for "what a blog is".

So instead, I hone in only on the thing that sucks the most - which turns out to be the friction - the things that stand in between an idea in my head and a page on the web.

In my scenario, I decided the thing that sucked the most was simply having a place on the internet where I could just start typing, have it save as I type, thereby removing all the friction of starting anywhere and resuming anywhere.

And thus was born bliss.js.org - what I'm typing in right now.

And, of course, life gets in the way. I didn't have time to implement all of the features of a blog. But now, instead of a half-baked, mostly broken project, I have a fully-functional, cross-platform, note-taking web app that easily exports into other tools that do the checkbox-y blog-like stuff.

I was able to accomplish its purpose not by writing the whole blog system, but rather by putting just enough work in to seamlessly duct-tape it together to hook into systems like (and including) GitHub Actions and build with hugo.

Tada! https://github.com/BeyondCodeBootcamp/bliss-template

SDD on the Edge

Suck-Driven Development turns out to also be a great way to inspire edge-of-the-box thinking.

We're not racing out "into the unknown" like some crazy Nordic ice witch. No. Instead, we're just finding solutions that are adjacent to the existing problem and solution sets. Totally connected - bridged - yet just out of the bounds of the competing products. A nice space anyone in the area could have seen, but no one had quite ventured out to before.

SDD Dogfood

As stated earlier, the big principle of SDD is that you (primarily speaking to developers) are close to the customer. Ideally you are also a customer.

I'll give a counter-example:

Speechify (text-to-ai-enhanced-speech) should have a knock-it-out-of-the-park product.

They don't.

They are the market leader simply because there isn't a better alternative, not because their product is particularly great (it isn't, yet).

See, as developers, we sit in front of a screen all day, so to give our minds the necessary extra stimulation they need we caffinate, and we take in through our ears what we can - while our eyes and hands are busy on the keyboard and the screen.

Yet, Speechify has a dozen easy-to-fix bugs that I can only imagine would drive any software developers using it nuts - things like not having correct audible pauses between HTML header elements and "smart" punctuation. Thus I must conclude that either they don't have their own developers using it (i.e. they're outsourcing to effective mercenaries), or they don't allow them the freedom to fix the low-hanging fruit.

Meanwhile they're advertising new features and working on new features and building out more fluff.

Management either needs to bring some talent in-house, or to get out of their way.

Suck-Driven Development would get them from good to great.

You don't need to do more, you need to do better. You need to suck less.

This is the way.

Update: Even today Speechify has actually improved signficantly. Maybe they've picked up some Suck-Driven Development after all.

SDD around the Web

YouTube Transcript

I was trying really hard to find one of my earliest references to this topic. I know there were even earlier ones, because I mention mentioning them here, but this is all I got for now:

https://youtube.com/watch?v=xgEtAhd7blw&t=503

8:29 the advice on how i can create a full application versus something small and my answer is you don't create a full
8:34 application you just create multiple small applications and then you don't put them in separate binaries so
8:41 for example you create a small application that does message signing and then you create an
8:49 application that does message sending over say https
8:55 and then you create an application that combines message signing with message sending and so on and so forth so
9:02 you take little steps and you combine them together you don't think of the big idea
9:07 it's all this is this is the thing that you need to do what is the smallest complete unit i can
9:14 do today that i could deliver at the end of the day or tomorrow that would make what i'm
9:20 working on better than it is right now that is the path to follow i also have
9:27 oh i had some sort of um
9:33 i had some sort of it was like tdd
9:38 but it was a nitpick driven development i think
9:45 that's or annoyance driven development i had a term for this if somebody remembers what i've said about this before i can't believe i'm blanking on
9:51 it but so i'm just going to call it
9:58 nitpick driven development you want to take the thing that bugs you the most the thing that you say
10:03 this would be useful if you know this actually i think i called it suck driven development what sucks most about your
10:11 application right now so if i create this message signing tool the thing that sucks most about it is i have no way to
10:18 get those messages to people actually the thing that sucks most about it is i have nowhere to no way to verify the
10:24 signatures you could look at it either way you could actually make an argument for either of those being the things that suck the most
10:29 because once it gets to somebody they need to be able to verify but if you can't get it to them it doesn't matter whether or not they can verify it so
10:35 pick either one but it's it's suck driven development sdd that's what you do you pick the thing
10:41 you you smart start small and you say what's the one thing that if i accomplish it today would make my app
10:47 more usable for me and maybe one other person tomorrow so that's my
10:53 that's my advice on that matter \

By AJ ONeal

Did I make your day?

Buy me a coffee

(you can learn about the bigger picture I'm working towards on my patreon page )