You’ve probably heard the saying “Perfect is the enemy of good” and maybe you’ve even said it yourself a time or two. You may have also been in a situation where you’re working on something and a boss keeps asking you about fringe cases, those events that will only happen to an extremely small number of users or records. I’ve been in that latter situation more times than I would like to admit, but early on I came up with a method for dealing with such situations.
I call it it he 80/20 rule. This is different than the other 80/20 rule known as the Pareto principle. In my version of the 80/20 rule, I look at anything that’s outside the normal use case, as a fringe case. Something that isn’t likely to usually happen. So when trying to get to a releasable state, I will often ignore anything that isn’t going to happen more than 20% of the time. I don’t mean that I ignore it forever, just for that initial release, and maybe a few subsequent releases (bug fixes).
Over the years, I’ve come to understand one fact. You’ll never make whatever you’re working on perfect. So we have to stop shooting for perfect, and get it released. Launch it. Ship it. Get it out there for people to use. You can spend a lot of time working on every fringe case, but really the more you do that the longer it’ll take you to get release whatever it is you’re working on.
Our goal is to ship. So when a boss, customer, whomever keeps trying to find the fringe paths, try to counter by asking “how often do you expect that to happen?” or “That’s not important enough to be in version one.” You want to get what you’re working on out to the users. Then you can see what areas need addressing.
This isn’t an excuse to ignore errors, and not have your application error gracefully. It just means that you don’t have to work on ever edge case. Get the 80 percent solution finished (the parts that cover 80% of what you’re customers are going to need), then release it. Fix bugs, release a new version, rinse, repeat. Once you have the 80% parts done, and you know that’s working as flawlessly as you can make it, then worry about the edge cases. Those users who are the fringe of your customer base. But not before you have the eighty percent covered.
Like this:
Like Loading...
Related
Michael Koby 
The 80/20 Rule
You’ve probably heard the saying “Perfect is the enemy of good” and maybe you’ve even said it yourself a time or two. You may have also been in a situation where you’re working on something and a boss keeps asking you about fringe cases, those events that will only happen to an extremely small number of users or records. I’ve been in that latter situation more times than I would like to admit, but early on I came up with a method for dealing with such situations.
I call it it he 80/20 rule. This is different than the other 80/20 rule known as the Pareto principle. In my version of the 80/20 rule, I look at anything that’s outside the normal use case, as a fringe case. Something that isn’t likely to usually happen. So when trying to get to a releasable state, I will often ignore anything that isn’t going to happen more than 20% of the time. I don’t mean that I ignore it forever, just for that initial release, and maybe a few subsequent releases (bug fixes).
Over the years, I’ve come to understand one fact. You’ll never make whatever you’re working on perfect. So we have to stop shooting for perfect, and get it released. Launch it. Ship it. Get it out there for people to use. You can spend a lot of time working on every fringe case, but really the more you do that the longer it’ll take you to get release whatever it is you’re working on.
Our goal is to ship. So when a boss, customer, whomever keeps trying to find the fringe paths, try to counter by asking “how often do you expect that to happen?” or “That’s not important enough to be in version one.” You want to get what you’re working on out to the users. Then you can see what areas need addressing.
This isn’t an excuse to ignore errors, and not have your application error gracefully. It just means that you don’t have to work on ever edge case. Get the 80 percent solution finished (the parts that cover 80% of what you’re customers are going to need), then release it. Fix bugs, release a new version, rinse, repeat. Once you have the 80% parts done, and you know that’s working as flawlessly as you can make it, then worry about the edge cases. Those users who are the fringe of your customer base. But not before you have the eighty percent covered.
Share this:
Like this:
Related