Coding with Honour

The personal blog of Sam Stokes.

Move fast with confidence

| Comments

If you work on a software product team, you’ve probably heard, or said, things like this:

  • “The deadline is unreasonable, I can’t do a quality job in that time.”
  • “Just ship it already, it doesn’t need to be perfect.”
  • “Shipping quickly is the priority, so we don’t have time for testing and code review.”
  • “We’ve been moving too fast recently and breaking too many things. We need to slow down and be more careful.”

These sorts of statements often come up when discussing schedule or scope. They frame the decision being made as a choice between two approaches: you can do it fast or do it well, but not both.

I believe that “speed vs quality” is a false choice. Each time we naïvely frame a decision this way, we do a disservice to ourselves and to our users. Sometimes the best way to run fast is to be confident in your footing.

Let's talk about confidence

| Comments

Ever been in a conversation like this?

Engineer: “We’re going to have to cut feature X if we want to launch on time. It’ll take two months to build, but the deadline’s in a month.”

Product manager: “That’s a shame - our competitors have that feature. I thought you demoed it last week?”

Engineer: “That was just a prototype. We can’t ship it to users.”

Product manager: “Why not? It looks awesome, and it worked fine in the demo.”

Engineer: “Sure, it basically works, but the code is a mess, and we haven’t done any testing. It’s not ready to ship.”

Product manager: “It doesn’t have to be perfect. We need to move fast now - we can always fix it later.”

Engineer: “That’s what you said last time. Fine, we’ll ship the prototype… again. Don’t blame me when it breaks.”

Each person is trying to manage the risks they know about, and do what’s best for the business. Despite the best of intentions, these conversations can feel frustrating for both parties. It’s easy to feel like the other person doesn’t understand your concerns, or is stubbornly clinging to their own principles. The optimal decision is probably somewhere in the middle, but this kind of discussion rarely gets there.

I previously argued that we should stop using the word “quality” because it tends to polarise conversations. Now I want to offer an alternative. I propose that most conversations about schedule or scope would go better if they were framed instead around confidence.

Let's stop talking about quality

| Comments

I don’t like discussions about quality in software.

Don’t get me wrong. I want to build software I can be proud of. I want to be part of teams that build great products. I aspire to craftsmanship. What I dislike is the word “quality”, and how it tends to polarise conversations.

Quality

Quality is subjective

A lot of factors go into software quality. Good software is fast. Good software is maintainable, readable, scalable, and well tested. Good software has attractive UI and intuitive interactions. Good software has no bugs, or at least no serious bugs, or at least no bugs that our customer support team can’t work around.

In practice, quality means whatever you want it to mean. To a fan of unit testing, quality means investing in unit testing. To a designer, quality means beautiful screens and careful interaction design. To a customer support manager, quality means all bugs are documented and the serious ones have an ETA.

If you tell people that your estimates are higher than expected because you want to do a quality job, some of them will think you’re spending time refactoring and writing tests, and some will think you’re going pixel-by-pixel in Photoshop. Some of them will end up disappointed.

Programming is not magic

| Comments

When people who program want to convey to others the joy and satisfaction we find in our craft, we often liken it to doing magic. The analogy evokes a sense of empowerment, possibility and freedom. But I think comparing programming to magic actually does unintended harm, because it has another connotation: that programming is a mystical ability, something you are born with, not something you can learn.

Magician

I want to get a lot more people programming, and I think we need a better analogy to get there.

What programming is like

| Comments

What is programming like?

We in the software profession have done a terrible job of explaining to the public what it is that we do. Everyone has interacted with a teacher or a doctor. There are TV shows about lawyers, cops, even government officials. However warped our impression of their day-to-day, we can relate to these professions. TV depicts programmers as modern-day wizards, socially aloof, hacking into systems or bringing the new algorithm online just in time to stop the cyberterrorists — totally disconnected from people’s experience of the software they use every day. Software remains mysterious.

This isn’t just a problem for awkward “so, what do you do?” conversations at parties. I believe one reason why so many demographics are underrepresented in software is that unless you grew up with it, you’re unlikely to have the faintest idea what making software is actually like. Why would you strive — particularly against economic obstacles and systemic biases — to enter a profession you know nothing about?

Programming sucks

Inspired by a friend who couldn’t see what was so hard about programming, Peter Welch wrote a hilarious, heartfelt and all-too-true rant about what writing software is like. His title, and answer: “Programming Sucks”. The whole, long post is enjoyable reading, but here’s a representative excerpt:

Imagine joining an engineering team […] for a bridge in a major metropolitan area. […] The bridge was designed as a suspension bridge, but nobody actually knew how to build a suspension bridge, so they got halfway through it and then just added extra support columns to keep the thing standing, but they left the suspension cables because they’re still sort of holding up parts of the bridge. Nobody knows which parts, but everybody’s pretty sure they’re important parts. […]

Would you drive across this bridge? No. If it somehow got built, everybody involved would be executed. Yet some version of this dynamic wrote every single program you have ever used, banking software, websites, and a ubiquitously used program that was supposed to protect information on the internet but didn’t.

Vim wizardry #1

| Comments

(I wrote this as a response to an Ask Hacker News post about learning Vim, but I thought it deserved a life of its own.)

This is one of my favourite Vim features. Say you have the following code:

do_something_with(some + long * complicated * expression)
                           ^

Say your cursor is where the caret indicates. Typing ci) (“change inside parens”) in normal mode will:

  • delete all the text between the two matching parens
  • place you in insert mode with the cursor between the two (now adjacent) parens
  • put the deleted text in the yank buffer so that p will paste it.

The use case here is obviously so you can assign a name to that long complicated expression. ci) is much easier than selecting it with the mouse, and keeps your hands on the keyboard where they belong ;)

The genesis of a building

| Comments

Witnessing this is pretty cool from a “making things” point of view. Shame it’s happening right outside our flat.