Your Problem Is Not Unique

As I approach my 10th year as a software professional, one of the things that frustrates me the most about our industry is the way in which people chronically overestimate the uniqueness of the problems they’re facing, and the frequency with which wheels are reinvented.

Designers, developers, and managers all have a habit of approaching common problems as if they’re the first one to do so. There’s an expression about “standing on the shoulders of giants.” We’re not all giants, and not all of our problems require herculean efforts.

Begin rant…

Your UI problem is not unique

I think the most common and ultimately harmful way this manifests is in user interface design.

Reinvention at the UI level is particularly insidious, as it doesn’t just waste the time and money of the team developing the software, but it confuses users (and we’re ultimately doing this for them, right? Right?)

I’ve witnessed bored designers coming up with the most elaborate one-off UI components to show a list of items or tabular data as if that’s a unique thing to do. Your typical line-of-business web app is not going to succeed or fail based upon the clever, innovative concept you’ve invented for showing a list of items to a user.

The thing is for the 99%, familiarity trumps cleverness. Every UI element that has to be explained-- especially when you could have swapped in one that people already know and accomplishes the same purpose—is one check against you and your product.

For example, I can’t tell you how many hours I’ve spent on teams debating the look and feel of the primary navigation for a web app. Grab a copy of Don’t Make Me Think, read the chapter on navigation, do what it says, and then move onto more pressing issues. You’re doing a big disservice to your users if you don’t copy the familiar style of navigation that your users have gotten used to on popular websites for the last decade.

One more example: your web app is not the first one to need to notify users of events that have happened in the system. Roughly 1.4 billion people--including the people who use your web app--use Facebook and are desperately familiar with the way that Facebook handles notifications. Rip their design off as closely as you can, and move on to something that can differentiate you from your competitors.


There are good catalogs of established UI patterns out there, such as the book Designing Interfaces. Before you have a long, long, like cruelly long series of meetings and email chains, whiteboard sessions, and the like, identify the pattern that relates to your requirement, find some well-known examples of the pattern, and copy them as closely as you can. If by some fluke your unique problem has not already been solved in a nice, familiar, recognizable, warm-fuzzy to your grandma kind of way, then by all means proceed to your brainstorming session(s).

Your development problem is not unique

For developers (and this includes me), I know that working day in and day out on that accounting app is not always particularly exciting, but avoid the temptation to write your own object-relational mapper from scratch to shove ledgers in and out of your SQL database. If you want to break out of the mold and roll your own thing from scratch, choose an area where you can really make a difference.

If you really want to differentiate yourself, be the person that knows the lessons of 40 years ago rather than a person who’s obsessively implementing TodoMVC over and over in this afternoon’s hottest JavaScript framework. The former is much rarer than the latter.

Tweet from Giles Bowkett

I know a lot of devs are entranced by the technology for its own sake. And there’s nothing wrong with nerding out over programming languages (my personal favorite), or JavaScript frameworks, or NoSQL databases or whatever floats your boat, but it’s easy to lose sight of the bigger picture.

“Barb, I know this thing is a pain in the ass to use, because the navigation makes no sense, no thought was put into the information architecture, and we didn’t consult with one actual user before developing it, but you’ll be happy to know that we’re using Riak on the back end. You’re welcome.”

There’s an episode of The Changelog podcast that came out recently in which they interviewed DHH about the decade long history of Ruby on Rails. With his trademark bluntness, he lets loose on “unique snowflakes” in a quote that I would guess was inspired by Tyler Durden’s speech from Fight Club:

They want to believe that every single application is a unique snowflake. That they're so brilliantly unique, too. That their value comes from their careful selection of which template language, which data mapper, which whatever the hell it is...

There are lots of applications out there trying to be needlessly novel to satisfy the egos of programmers who do not want to feel like they're working in cookie-cutter domains. That they somehow attach their self-worth to how novel their application is.

That’s a little harsh—what would you expect from DHH?—but I think the point is valid. It’s all too easy to focus on the minutiae of technology when in reality, we’re in a people business. And now I quote from Peopleware, as I often do:

…the High-Tech Illusion: the widely held conviction among people who deal with any aspect of new technology (as who of us does not?) that they are in an intrinsically high-tech business. They are indulging in the illusion whenever they find themselves explaining at a cocktail party, say, that they are “in computers,” or “in telecommunications,” or “in electronic funds transfer.” The implication is that they are part of the high-tech world. Just between us, they usually aren’t. The researchers who made fundamental breakthroughs in those areas are in a high-tech business. The rest of us are appliers of their work. We use computers and other new technology components to develop our products or to organize our affairs. Because we go about this work in teams and projects and other tightly knit working groups, we are mostly in the human communication business.

Managers, you’re not helping

Project managers, stakeholders, and other people who manage software efforts are not off the hook here. You also need to be honest about the product you’re making and accept that sometimes your unique take on logo placement is not what’s going to sell your software. You folks hold the keys to the backlog and how work gets prioritized. Spend those precious developer-hours on things that matter, not reinventing the same basic features and conventions that nearly every application has in common.

What’s worth spending time on?

The way that your bread is truly buttered in 99% of applications is through insights into the business domain that come from years of domain expertise accumulating slowly.

If you want to futz with some new technology and try something new, that’s great. But be honest about what you’re doing. Most of the time you’re doing it for you, not for your users.

I wish a standard role on every software team was the “That Thing’s Already Been Invented” Czar. Or “Code Historian” or “User Experience Historian”. Now that person would be worth their weight in gold.

Instead of Not Invented Here (NIH), how about Proudly Found Elsewhere (PFE)?

But what about innovation?

Innovation is a necessary thing and I would never suggest that people should never try anything new. If you never try anything new, the industry can never move forward.

The question of when to innovate is so context-specific. If you’re writing an early iPhone app during the wild west of that platform, by all means, try some new form of navigation. If you’re Facebook and having the (good) problem of 1 billion users hammering your database every day, by all means, invent your own database.

I think “20% time” or something similar may be a good solution. Spike some crazy idea you had or some bleeding edge tech on a pet project one day a week. If it happens to have practical implications for a product, then awesome. But it’s ok to just have some fun and learn something new. Scratch your itch--we know that’s important for its own sake.

Postscript: Why make Ruby on Rails?

It’s funny—when I started writing an outline for this post, I couldn’t stop thinking about DHH and Ruby on Rails, which I think is one of the few true game-changing innovations in the field of web development since I joined the industry. I kept thinking back to the early days of Rails’ creation and how difficult it would have been to justify such a project. It seems like such a strange case of yak shaving. Really? You need to take this weird Japanese programming language no one has heard of and write the umpteenth web framework in order to write yet another project management tool? How can you possibly justify that? What did your business partner, Jason Fried, think? You guys are the “do less” guys. What the hell?

In an interview from 2005, Fried says:

I had some natural hesitation about using Ruby at first ("What the #@!* is Ruby?" "Why don't we just use PHP--it served us well before?"), but David Heinemeier Hansson, the first engineer on the Basecamp project, cogently made the case and I bought it.

In the podcast episode I mentioned earlier, DHH also discusses his motivation while writing the code that would become Rails. It turns out that a major motivation for DHH was to remove all the wheel-reinvention that happens with each new web project. He wanted to make a “batteries included” full-stack framework that gave you sensible defaults and convention over configuration. Because it’s not necessary, for example, to invent your own naming conventions for every class and every property and how they map to the naming conventions of your database tables and columns. Because what the hell does it matter? He’ll think carefully about the problem, pick one, make it the default, and then you can move on, because you have more important things to worry about.

Should Managers Share an Update in the Standup?

I've been a part of several agile teams in my career that did a daily standup as part of their process. I've come to view standups as a must-have for software development teams. The payoff is large for the minimal time commitment.

The idea is that the team gathers together every day for a brief meeting (typically 15 minutes or less) just to update each other quickly on what they worked on the prior day, what they plan to work on today, and if they’re hitting any roadblocks that the team may be able to help out with.

A standup in progress

In some teams, I've noticed what seems like a strange phenomenon to me, which is where managers that attend the standup don't share an update with the team, but merely attend to hear the updates of everyone else. This has always bothered me a bit, as I view the Agile philosophy as an egalitarian approach to making software, where everyone on the team is an equal.

I can distinctly remember on one team, where one of the developers had recently been promoted to management, and almost immediately stopped sharing an update like every other member of the team in the daily standup. As we had worked together for some time, I good-naturedly asked him to share an update, which was greeted by nervous laughter from the rest of the team, as if this was an odd request. He obliged and shared an update, which turned out to be packed with helpful information for the team. But after doing this a few times, and each time feeling like I was violating a cultural taboo somehow, I relented to the idea that he was now in a different class from the rest of the team that did not need to share an update.

I saw this pattern repeat a few times, where managers who attended the standup would listen to everyone else, but rarely speak about their own work. I may find this strange, but what do the experts have to say?

Scrum—the most popular agile methodology—has its version of the standup called the “daily scrum.” According to the official Scrum guide:

…only Development Team members participate in the Daily Scrum.

According to the Scrum Alliance:

Though interested parties are welcome to come and listen to the Daily Scrum, only the Scrum team members, including the Scrum Master and product owner, speak during this meeting.

In my experience with Scrum, the Product Owner has always been someone in management. The quote above indicates that the Product Owner speaks during the meeting, but it’s not clear if this means answering the three questions development team members answer:

  1. What did I do yesterday that helped the Development Team meet the Sprint Goal?
  2. What will I do today to help the Development Team meet the Sprint Goal?
  3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

In James Shore’s highly-rated book, The Art of Agile Development, he has a fictional transcript of a well-run standup:

A programmer:

Yesterday, Bob and I refactored the database pooling logic. Check it out—we made some nice simplifications to the way you connect to the database. I'm open today and I'd enjoy doing something GUI-related.

The product manager:

As you know, I've been away at the trade show for the last week, getting some great feedback on the user interface and where we're going with the product. We need to make a few changes to the release plan; I'll be working with the other customers today to work out the details. I can give a lunch-and-learn in a day or two if you want to know more. [Several team members express enthusiasm.]

A domain expert:

After you guys [nodding to the programmers] asked us about that financial rule yesterday, I talked it over with Chris and there was more to it than we originally thought. I have some updates to our customer tests that I'd like to go over with somebody.

A programmer responds:

I've been working in that area; I can pair with you any time today.

In this hypothetical standup, not just programmers but the “product manager” and a “domain expert” are both chiming in with relevant updates for the team.

Scrum expert and author, Mike Cohn, has this to say in the comments of a blog post on daily scrums:

I have no idea why the Scrum Master and Product Owner would not give updates. That sets up a complete us-and-them division between the team: "You have to share what you did, but I don't." A Scrum Master and Product Owner could easily within a minute (total) update the team in a way that kept things brief but didn't create that division.

In another comment on the same post, Mike continues:

I view the Scrum Master as a committed participant. I coach Scrum Masters to give (brief) updates on what they did. For example, if a Scrum Master never reports on removing impediments he's told about, other team members may never mention them. They'll think, "Why mention my impediment? I've never heard our Scrum Master say he's resolved anyone else's?"

Finally, here’s a comment from Gunther Verheyen, author of Scrum - A Pocket Guide:

I tell that Scrum Master and Product Owner are allowed to join the meeting. This seems to have a positive effect on the team; it shows they are connected and committed as Scrum Team members. But if they join, behave as every other Scrum Team member. So, don't start leading the meeting. I ask them to answer the 3 questions from their perspective. It keeps the others informed, and it helps to keep the Product Owner to be accurately informed which is quite helpful for his/her stakeholder management.

Let’s consider the chickens and pigs analogy that Scrum practitioners are fond of. If a person is so invested in the success of a project that they are attending the standup every day, then in my mind, that makes them a “pig” and their input is needed just like every other member of the team.

Chickens & pigs

If you're a committed member of the team, then you have important work to do to make the project successful. Tell the team what you're doing! In my mind, the standup is partially about keeping the team members accountable to one another, so that everyone is clear about the team's goals and that each person is contributing on a daily basis to make those goals a reality. If you're the Scrum Master, for example, tell the team what impediments you removed the day before and which ones you're removing today. If you're the Product Owner, tell the team about requirements that you're gathering or priorities that you've shifted. Tell the team about demos that you've given or discussions you've had with stakeholders that are relevant to the team. How are you helping the team meet its goals? What impediments are you facing?

When a manager attends the standup every day but doesn't feel the need to communicate what they've been working on that's relevant to the team, it indicates to me that the person thinks the standup is an old-fashioned "status meeting" where underlings account for what they've been doing while management listens and judges. I would argue that the best place to see the status of work the team is doing would be to look at the backlog in whatever tool the team is using to organize work (Pivotal Tracker, for example). There’s no need to be in a certain place at a certain time each day to find out the status of work. Pull that status any time you like.

What do you think?