The Professional Buzzkill

I’ve joked occasionally that every software project needs a dedicated “Buzzkill”—someone who balances out the pie-in-the-sky thinking that often hurts these projects.

I do believe that optimism is one of the greatest dangers to most software projects—people being unrealistic about the complexity of things and how long things take to do well. But no project ever gets off the ground without optimism, right? Would any non-technical person ever sponsor a software project if they really took in the full complexity and likelihood of failure that their project (or any project) faces?

Broken toy

So let’s accept the necessity of the optimist. Instead of damning optimism, let’s promote context. Maybe every team needs the “Contextualizer”—the person who places new ideas in context and then encourages discussion in that light.

One of the great triumphs of Scrum is that the product backlog acts as a context for features to land in. Force the product owner to think about all the other stuff they’ve asked the team to do, every single time they have a new request.

I pledge not to shoot your idea down, but I will give it some context!


One of my favorite Twitter accounts in the software industry is Esther Derby’s. I’m constantly nodding along. This one got me thinking about the concept of “ownership” on software teams.

Esther tweet

It’s a common refrain from software project managers that they want developers to take ownership of the features they build, as in, accept accountability for what they’ve built and its quality—to care about it.

As someone whose career responsibilities have occasionally involved diving into another team’s codebase to figure out what went wrong, I’m guilty of thinking to myself, “How could these devs have shipped this crap? Don’t they care about the quality of their work?

Later on, I get a glimpse into the management of the team, and witness how the developers are pressured constantly to deliver more features, forget the bugs, and “commit” to delivering requirements they had no hand in writing and no say in the timetable for delivery.

It is damn near impossible to get developers to really take ownership of their code when all the circumstances of the project are implying: “Shit it and ship it!

Development teams must have veto power over scope and estimates, which I’m sure scares a large contingent of managers out there, but without that there is no hope for “ownership.”

Software Development Methodologies as Collective Fictions

The failure of methodologies to accurately model reality is a common source of cynicism amongst boots-on-the-ground developers. I can recall many conversations with teammates where we’d end a meeting and then chuckle in hushed tones with each other about how “wrong” we were doing Scrum and how clueless our managers were.

In his article My 20-Year Experience of Software Development Methodologies, Ian Miell makes the point that methodologies are necessary as “collective fictions”—a thought I personally find comforting.

As an industry, we tend to look back on Waterfall as hilariously naive and antiquated, but to Ian…

…the waterfall process was a ‘collective fiction’ that gave us enough stability and coherence to collaborate, get something out of the door, and get paid.

He goes on to discuss his experience with Rapid Application Development at a startup:

We were small enough not to need a collective fiction we had to name. Relationships and facts could be kept in our heads, and if you needed help, you literally called out to the room.

We got slightly bigger, and customers started asking us what our software methodology was. We guessed it wasn’t acceptable to say ‘we just write the code’.

Turns out there was this thing called ‘Rapid Application Development’ that emphasized prototyping. We told customers we did RAD, and they seemed happy, as it was A Thing. It sounded to me like ‘hacking’, but to be honest I’m not sure anyone among us really properly understood it or read up on it.
As a collective fiction it worked, because it kept customers off our backs while we wrote the software.

Ian then experienced Agile, with all its foibles:

The few that really had read up on it seemed incapable of actually dealing with the very real pressures we faced when delivering software to non-sprint-friendly customers, timescales, and blockers. So we carried on delivering software with our specs, and some sprinkling of agile terminology. Meetings were called ‘scrums’ now, but otherwise it felt very similar to what went on before.
As a collective fiction it worked, because it kept customers and project managers off our backs while we wrote the software.

As someone who’s been making software professionally for over a decade now (not as long as Ian!), I have arrived at much the same conclusion, that software development methodologies have value regardless of their literal reality. Organizing principles and shared terminology alone are worth adopting something...anything.


Accepting the inevitability of these collective fictions is like taking a weight off of one’s shoulders. It just saves so much angst.

Bosses like to give politically-correct names to things that their people are already doing, and that’s fine. The software industry’s current fixation on Agile concepts is a reflection of the way that a distributed workforce would inevitably do things. Ian explains:

If software methodologies didn’t exist we’d have to invent them, because how else would we work together effectively? You need these fictions in order to function at scale. It’s no coincidence that the Agile paradigm has such a quasi-religious hold over a workforce that is immensely fluid and mobile.

We’ll always be working under some “methodology” and that’s okay. Just keep making good software, and don’t worry about what people are calling it.

Inclusive Culture, Minimum Culture

Our startup has a very progressive culture…as long as you’re white, childless, in your twenties, politically liberal, and love craft beer, hackathons, and indie rock.

Dress codes are so lame.

My own personal experience working for a big, boring, multi-national company matches what Rich Armstrong recounts in his great article on Hacker Noon about inclusive company cultures:

As I said, to this day, my team at J.D. Edwards was the most diverse I’ve ever worked on. My first boss was an African immigrant, second boss was a forty-something mom. Our team measured high on nearly every dimension of diversity — gender, race, religion, age, parental status, national origin, sexual orientation, disability status, veteran status.

Rich goes on to talk about how that experience contrasted with his subsequent experience with the monoculture of a hip startup:

When our office culture is focused on business rather than socializing, we reduce the number of ways in which we all have to be the same. When we do that, we allow diversity to flourish. If your culture expects people to work long hours or hang out off-hours, the strain on the people who are different, in whatever way, is increased, and your ability to retain a diverse work force is reduced.

He then discusses his experience at a startup, Fog Creek Software, that managed to retain the inclusive culture of his big company experience:

...the culture was mostly about the business of software, how you build it, how you sell it, how you support it. If you were excited about that, you automatically belonged. You didn’t need to stay late, or drink alcohol, or play Rock Band, or play board games, or not have kids to pick up, or go to church, or not go to church, or do anything except show up 9-to-5 and care a lot about good software.

…the lesson I’m taking for myself going forward is this: if you want to build an inclusive culture, build a minimum culture. Build it around professionalism, boundaries, and work-life balance. Make sure your senior staff walks the walk, and spreads the word.

I found this last bit so poignant, as it’s really sort of counterintuitive—perhaps the reason why so many tech companies fail at trying to bolt on “inclusiveness” to a monoculture after the fact.

For a company that really wants to have a diverse pool of employees, you have to back off the idea that they’re all going to be best buddies, and don’t insist that their personal identities are enmeshed with a corporate culture.

Job Ad Red Flags: Calling All Ninjas!

I’m not sure this really needs to be said, but these words in a job posting are an instant buzzkill:

  • Ninja
  • Rockstar
  • Jam sessions
  • etc.

Basically, if the ad sounds like it was composed out of words that immature young men would think are cool, you lost me.

These may be controversial, but I’m also wary of mentioning things like “hackathons” and “kegerators”. Hey, I love working as a software developer, and I love beer, but it seems kind of weird to think I want to hang around the office after hours. (In fact, let’s kill the office altogether—I’ll take the savings in my paycheck, please.)


Don’t Trap Your Clients in the Bikeshed

As software developers, one of the best things we can do for our clients (internal or external) is to restrain from bombarding them with questions about trivial and easy-to-change aspects of their requirements.

When I find myself in doubt about how some aspect of the software I’m developing should work, I try to identify if the requirement is “bikesheddable” before stopping my progress to reach out to the client.


For example, the client has a requirement for a feature like “when an administrator grants access to a new user, the user should be notified by email.” I’ve seen developers (typically more junior) block their progress on a feature like this until the client gets back to them with a definitive answer on what title to use for the email.

I define a question about the requirements of software to be bikesheddable if it is…

  1. Trivial
  2. Likely to generate back-and-forth and delays
  3. Easy to change later

If it’s bikesheddable, pick a sane default and continue on with the feature. When the client sees the feature deployed, they are of course most likely not even going to notice the choice you made for the aforementioned bikesheddable thing, but if it happens to matter, by way of #3 above, you can easily change it later.

Get the broad strokes right in v1, and the fine details in v2 and beyond.

Job Ad Red Flags: Fad Obsession

This red flag may be considered a subcategory of the previous red flag I wrote about in my post highlighting technical minutiae.

Remember when everyone was talking about how jQuery was unmanageable without a framework like Backbone.js? And then three seconds later it was embarrassing to be using Backbone.js, and startups would talk sheepishly about using it and how they should really rewrite using Angular? And then three seconds after that, they were embarrassed to be using antiquated technology like Angular, and how they couldn’t wait to start their rewrite using React?


As Dan McKinley put it in his classic post, Choose Boring Technology (2015):

Let's say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while.

If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. If you choose to use service discovery tech that's existed for a year or less, you just spent one of your innovation tokens.

Adding technology to your company comes with a cost. …if we’re already using Ruby, adding Python to the mix doesn't feel sensible because the resulting complexity would outweigh Python's marginal utility. But somehow when we're talking about Python and Scala or MySQL and Redis people lose their minds, discard all constraints, and start raving about using the best tool for the job.

The problem with "best tool for the job" thinking is that it takes a myopic view of the words "best" and "job." Your job is keeping the company in business, god damn it. And the "best" tool is the one that occupies the "least worst" position for as many of your problems as possible.

When I read a job ad where the focus is on an intricately presented list of the most bleeding edge languages, frameworks, databases, text editors, chat tools, and the like, I have to wonder what other trivial things they’re spending an inordinate amount of cycles on instead of delivering software to their customers.