I have been on - and worked with software development teams for more than thirty years (consider that software wasn’t my first career choice, and you’ll realize how old I actually am). A lot of times, and more than I can count as I think of it, I’ve seen teams encounter some sort of problem, and then immediately dive deeply into solving that problem - as if coming up with new solutions to old problems is the right approach - always.
Half of the time these teams are solving the wrong problem, and half of the time they’re solving a problem that’s already been solved. The statistically insignificant remainder that fits between those both halves are where the snowflakes live - and you’re not one of them.
The Problem with Problems
Let’s start with the easy problem - solving the problem before you understand it. A lot of software developers I know make the mistake of falling in love with their initial solutions. They assume that the problem is so simple, and so straightforward, that there can be only one solution, and it’s the one they just thought of.
A few decades ago, I learned The Rule of Three (from Are Your Lights On, by the amazing Weinberg and Gause). The Rule of Three states:
Until you can define the problem in three different ways, you don’t really understand the problem.
In practice, this simple rule just kicks ass. I can think of literally dozens of times when I’ve asked/forced teams to come up with another pair of alternate solutions to go with their “for sure the right solution, Alan, leave us tf alone” implementation. I remember exactly one time when the initial solution stood as is. Sometimes they changed direction completely and found a simple and safer solution. Most often, the exercise results in a compromise based on the discussion and debate that came from pitching the three solutions. I like to tell teams to wallow in the problem for a while before jumping to implementation, and this is the easiest way I know of to do that.
The Real Problem with Problems
And then it gets a little more difficult. Where more than a few software teams really blow it is when they confidently assume that their situation is so freaking unique that they must be the only software team in the world to ever encounter the problem. A search of stack overflow, GitHub or chat gpt isn’t even worth it because nobody could ever have wanted websockets in Go, or an easy way to scrape news articles, the ability to have cat run cat, or to write a program that just exits (in 10 languages).
Sometimes when you see a bunch of nails, a hammer is probably the right solution. But DON’T BUILD A HAMMER. Maybe you already have a hammer in your toolbox. If not, you can borrow it from your neighbor. Chances are that the hammer already exists - maybe Fred from the front end team has one in his filing cabinet. I have watched an embarrassing number of people see nails, and blindly assume that they are the first person to ever come across this particular type of fastening device, so building a hammer is in order.
Stupid, right?
The book that everyone started and a few of us finished (Thinking Fast and Slow, but Daniel Kahneman) goes fairly deeply into the decision-making, cognitive biases, and insights on why people might not recognize or seek out existing solutions. The Mythical Man Month (Brooks) touches a bit on this as well - in both the “No Silver Bullets” essay, as well as in the essay on the “Second System Effect”.
As with the first problem, I have a simple antidote. I have almost a Pavlovian response now when I hear someone say, “Our problem is unique…”. To that statement (after making them come up with at least three solutions), I ask:
Why is it Unique to you alone?
Who else could also have this problem?
What other problems may have the same solution that you are considering?
Inevitably, it turns out that they’re not as unique as they thought they were. In fact, I’ve never actually encountered a programming snowflake.
The Root of the Real Problem with Problems
Sadly, it gets worse. The first problem is just making sure you understand your problem. The second problem is assuming that your problem is unique. The far more severe problem is when you the learning and discovery needed to brainstorm solutions and to discover cohorts doesn’t exist. The internet provides some great ways to discover new solutions - and chat gpt is a great collaborator that can help find alternate solutions for your problems. But often the failure lives in a much smaller bubble - in the organization.
I worked at Microsoft for quite a few years. While I was there, I led a small number of cross-company groups. I did this, because I felt pretty strongly that Microsoft’s size (huge) was slowing them down, but that in a learning organization, that size should be a competitive advantage. By enabling connections between people solving problems and giving them a venue to discover each other’s problems and solutions, I wanted to find a way for learning to thrive. Peter Senge, of course, talks extensively about this concept in The Fifth Discipline. This book (which I think is overdue for a re-read), goes deep into applying system thinking to create an organization where learning from each other accelerates the capabilities of the team.
For some of you reading this article, it’s probably not too hard to imagine this scenario:
You have a large hierarchical organization that naturally (and strictly) follows Conway’s Law - the organization structure dictates the product structure. The people in Team A do their thing, the people in Team B do their thing and so on. Nothing works well together, but worse, ten teams develop software in ten different ways using several dozen different tool chains. Nobody talks, nobody shares, and nobody listens. It’s the opposite of a learning organization, it’s an unlearning organization. It’s a mess.
Break Down Silos
Bob Herbold talks about this exact experience at Microsoft in The Fiefdom Syndrome, and the book highlights the challenges really well. Once at Microsoft I was working on procuring some software that would have done absolutely amazing things for learning and community - but it was vetoed in the 11th hour by a VP in Sharepoint who said, “No, this functionality is something we may provide in SharePoint someday”. Twenty years later, and that functionality still isn’t there, and SharePoint is still…SharePoint.
Microsoft got (or at least is getting) better, but a lot of companies still have silos. They feel safe and comfortable. By avoiding other teams, you avoid pesky conflict. Then again, silos are also stifling the growth of the company, affecting developer velocity, and slowing down learning and innovation.
This too, is a problem with an easy fix. Regardless of your role and level, just talk to people in other groups. Tell them what you’re doing and what challenges you’re facing. Find out what’s easy for them, and what’s hard. Set up brown bags or show and tells. Collaborate with them a lot to help understand how your code works together. Pretend that the silos don’t exist.
Somewhere, someone is thinking that their org has silos and fiefdoms for a good reason, and that it helps them in some way that’s super unique to them, and that nothing I’ve said here is relevant.
Remember - this is one for the snowflakes.
-A 1:1
I like this posts’s blend of hard-earned curmudgeonly wisdom (“‘yer all a bunch a ‘idjuts”) combined with concrete questions for teams to address (“I’ve found it productive to have teams address the issue this way that you might want to consider adopting yourself…”). Nicely done!
This is great – simple questions that cut to the core of common mistakes and dysfunction. I’m ashamed to say I’ve been guilty of similar behavior in the past, but I guess at least I recognize now that there is a better way.