Episode 60: How Developers Fail In my experience, both personally and with others I've worked with, more junior programmers are most concerned with how to build the thing. But as you gain experience, you find that often the thing you or your team built isn't actually the thing the customer wanted. And this kind of failure is both more difficult to detect and often more expensive to address after the fact.
Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.
This is episode 60.
This week's tip is brought to you by devBetter.com.
What is devBetter? It's a private group coaching community geared toward accelerating developer careers. We meet weekly for live Q&A sessions and have an active Discord-based discussion the rest of the week. Topics range from coding skills to interviewing and personal branding. Check out devBetter.com and read the testimonials at the bottom of the page.
I'm fond of saying "Developers fail in two ways: either we build the thing wrong or we build the wrong thing." I like the word play, which helps make the quote more memorable. It's very similar to the adage that "if you don't like where you work, you can change your organization, or you can change organizations." But it also strikes me that that most developers focus more on one problem than the other. In my experience, both personally and with others I've worked with, more junior programmers are most concerned with how to build the thing. There's a technical challenge there, and figuring it out is something many of us enjoy, like solving a puzzle. But as you gain experience, you find that often the thing you or your team built isn't actually the thing the customer wanted. And this kind of failure is both more difficult to detect and often more expensive to address after the fact.
Let's focus for a moment on the first kind of failure, building the thing wrong. It's intentionally vague. The thing is whatever the software is you're building. And wrong in this case means any kind of technical defect that results in the system not meeting its users' needs. Maybe there's a critical bug that results in the system crashing. Maybe the architecture doesn't scale. Maybe there are massive performance or resource problems or memory leaks that make the system unusable. It could even be a security flaw that allows a malicious user to take down the system, or compromise its private data. These are all the kinds of things we tend to think of when we think about flaws or defects or bugs in software applications.
Sometimes, quite often in fact, these failures are quite minor. They may be caught by a build server or during manual testing before end users ever see them. Other times, the failures may be quite expensive, with no easy fix. Some bugs are inevitable, which is why we design software processes to expect, detect, and correct them. Our engineering practices are very often designed to find system defects as quickly as possible, since we know correcting a defect moments after its introduction is orders of magnitude less expensive than after it's been shipped to production. Make no mistake, preventing the shipping of defects is a very worthwhile activity for software teams.
Another more subtle way in which we might build things wrong is architecturally or from the standpoint of quality. Certain decisions made early on about the system architecture might turn out to be "wrong" later on when they prevent us from responding to customer demands. Technical debt in the form of shortcuts taken can have a similar impact later in the life of a system. Though more insidious than the release of user-observable defects, these too are examples of building things wrong.
So what about the second class of failure, building the wrong thing? Why would we do that? It turns out communication is hard. Customers and users don't always communicate what they want clearly. We don't always listen well. Or we forget. Or we build what we think they want - or what we would want - instead of what they say they want. Sometimes that even works, but most of the time it's an example of forgetting that you are not the user.
Oftentimes the user wants to solve a problem, but when they see part of what your software-based solution looks like, it triggers new ideas about how to better solve the problem. It's not that they didn't know what they wanted, but rather that the iterative process of designing a solution has revealed a better approach they was apparent at the outset. The worst thing we can do as software developers is to force the production of a mediocre solution because we are not open to a great one that our efforts made apparent later in the development process. To that end, it's important to communicate frequently, to validate our assumptions, and to allow the customers and stakeholders to respond to our work as it progresses. Be willing to change direction and be open to new ideas in order to maximize the value of the solution you deliver.
Being able to build a thing right is generally a question of technical competence. Once you reach a certain skill threshold, you have confidence in your ability to do it. Building the right thing requires additional skills and may depend on that technical competence. Beyond building software right, you must now be able to communicate quickly and effectively and pivot the direction of your solution as needed based on the latest information.
Only then can you be confident that you're building the right thing right.
That’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.