7 ms·

Perfection is a modern heresy

83 points by awinter-py 9y ago

AstralStorm 9y ago
Trite and worthless. I've never yet seen a project that got perfect (or attempted to do so and ever shipped or delivered) and it is almost never a goal. The tug of war is more often between putting unfinished things into production and some random deadline set by a person who knows nothing about the required amount of work to have a correct result. (Much less decent or maintainable.) Not negotiable or adjustable too. Even the sc(r)um approach of cutting features has limitations. At some point the customer will just be unhappy.
- Practicality 9y ago
  It's just a blog post about what he has observed as a common problem with teams falling behind. I think it's a little much to call it worthless. Excessive focus on unimportant details is a real problem. Everybody probably naturally focuses either too much on details or too little, and this person recently ran into some teams that focused on them too much, preferring to polish features the customer didn't care about rather than finishing the product.
amelius 9y ago
Write an imperfect foundational library, and watch everything built on top of it crumble down at some point. Perfection has its uses.
- khedoros1 9y ago
  Something can be imperfect but sufficient, or just plain insufficient. I don't think I've ever seen a perfect piece of software.
- onion2k 9y ago
  I don't think that's true. For example, it doesn't get much more foundational than glibc and that isn't perfect[1]. There's definitely a level of quality than needs to be reached, but that's some way short of perfection. Sometimes it's more useful to move forwards despite problems than to wait for them to be fixed. [1] https://sourceware.org/bugzilla/buglist.cgi?bug_status=__open__&no_redirect=1&order=Importance&product=glibc&query_format=specific https://sourceware.org/bugzilla/buglist.cgi?bug_status=__ope...
toanjc783tome 9y ago
I think most of what he says is correct, but it doesn't seem to address the actual problem I run into. The problem I see with my group's projects is not that we're trying to make it perfect. That almost never happens. Instead, management wants us to "just get it done," and "stop wasting time planning," and we end up with something that doesn't work well and is hard to maintain. Where a few days of pre-planning would have pointed out some areas where we were likely to get stuck and given us enough foresight to think up a better (but not perfect) architecture that we could implement in the time allotted. It still wouldn't be perfect, but it would be good instead of bad, which is what we end up shipping usually.
- darkerside 9y ago
  What I've found is that those days of pre-planning can be hit or miss. Yes, you might uncover a design flaw or missed requirement that would have set you off in the wrong direction. However, a prototype implementation is much more likely to uncover those same flaws, and probably also a few that you never would have found without building a prototype. I've found the prototype approach leads to a far higher likelihood of success. I think the real challenge with it is getting management to understand what is a prototype and what is a finished product, the danger being that you ship the prototype. Of course, this is all highly dependent of the nature of your work and length of development cycles. But if you're shipping in weeks, I'd wager you should be planning for hours at a time, not days.
agentgt 9y ago
I'm fairly certain the lunar landing required perhaps not perfection but pretty damn close planning. Modern heresy is applying anecdotal solutions to situations as learnings for all problems.
- awinter-py 9y ago
  well, yes and no. The apollo program operated on a tick-tock schedule where they did progressively harder missions. I interpret this as a series of proof-of-concept deliverables which allowed the team to develop expertise. Then later they could define & hit their tolerances for orbital mechanics, fuel budgets, system redundancy. Same deal with faraday / maxwell / einstein. The experimenter (faraday) measured & applied new phenomena, then maxwell came up with general laws, then einstein figured out their implications.
wellpast 9y ago
This is straight from the cowboy coder's mouth. This is Philistinism, plain and simple. > "...deliver something, anything...", no need to make it good, "teams make things better," anyway. No, no, and no. If you want to scale a team you have to deliver quality code. The cowboy coder spews out code, screams "see it works!", and then moves on to produce more diarrhea for "the team" behind him to clean up, "make better"... When one realizes they do not yet have a skill (such as producing quality code), it is tempting to scream "quality/perfection is a heresy" because this is much, much easier to say than the labor it takes to develop the skill. > It’s hard to see more than a week out because anything that takes more than a week to build involves R&D. Wrong, wrong, and wrong. MOST of what we do as practitioners (for those that have been doing it for at least some time) is NOT novel. Estimation is a skill. Estimates can be extremely accurate for those of us that have developed that skill. It is much easier to say "estimation is worthless" when it is a skill that you have not yet developed. Because it is only developed through (often frustrating) practice. Record the time it takes to do your work. Notice the patterns of problems that you face and how often they repeat themselves. --- Perfection per se has its hazards but in no way should that truth get us off the hook from developing ourselves and doing our work well. This post is nothing but dangerous to the nascent programmer-practitioner as it attempts to lull them away from what is possible and the work it takes to get there. Perfection is not attainable, but if we chase perfection we can catch excellence. -- Vince Lombardi
- mjw1007 9y ago
  Some new programmers need the advice to spend longer improving their code before sharing it; some need the opposite advice. Unfortunately, some people who dispense advice pick one of those "directions" and argue strongly for it, rather than trying to describe how to recognise when you've got the balance right.
  - hashmal 9y ago
    Sadly a lot of people have a hard time understanding nuance and middle-grounds. In programming or in anything else. If your code is to be thrown away in one week, why make it perfect? If you have to maintain it for years, why make it a pile of shit? Funnily enough you can't often predict the lifetime of code.
b1daly 9y ago
One thing to consider is that different types of projects have different "thresholds " of "good enough." This is also highly dependent on the available competition to your product. At this point, unless there is some fantastic new application, anything intended for use by "ordinary consumers" better be nearly perfect to even have a chance. I've observed with user interface design that there is often a stark threshold between "usable " and "unusable", and that it takes a perfectionist mindset to reach it.
mwfunk 9y ago
This is one of those conversations that has been going on for decades (if not centuries or millennia). If your life involves making something in private, then putting it out there for other people to see/buy/whatever, every such project requires you to decide when its done and ready for the world. Getting it out there sooner can be appealing if time is a factor. Spending extra time perfecting it is appealing if time is not a factor. It's just two poles between which you set a cutoff point, and in team efforts everyone will not only have different ideas about whether time or quality is more important, but they will have different perceptions about what it even means to be closer to one pole. You're always compromising something in engineering, no matter which pole exerts a stronger pull on you. Putting a flawed product out early might kill the product; you should've put the development time cutoff point closer to the 'perfection' pole. On the other hand, spending extra weeks or months or years polishing something that ends up not being not quite what anyone wanted is also bad, because if you had just gotten something out there sooner, you could've spent the same amount of time iterating on it in response to feedback. Lots of extra time spent on something often also translates into getting locked into technical choices that can be more difficult to back out of later if necessary. So there's definitely something to be said for putting a simpler and less-polished product out sooner to get feedback and test your initial assumptions vs. reality. I think these conversations never cease in part because so many people who argue about this stuff are treating it as a binary choice. They're not picking a cutoff point between two poles, they're picking a pole and going all in on it. In reality, they see different sets of pros and cons and weight them differently and see risk differently. The solution is better communication between people so that there is at least a shared set of known pros and cons. People might still not agree, but they can at least have the same conversation when weighing compromises. People who get into binary thinking patterns about situations which no one person fully grasps are being rational in their own way; they just don't understand that they are compromising something else. In my experience, people rarely see things in black and white once they understand how the opposing side views the situation. Both sides are rational, they just have disjoints areas of knowledge and thus priorities.
CM30 9y ago
Well, while I don't think perfectionism is always a bad thing and releasing 'any old thing' as quickly as possible it's always a good idea, I definitely see where he's coming from. There's a balance you have to strike here between 'done quickly' and 'done perfectly', and pushing towards either end can doom your project. I mean, look at Duke Nukem Forever. The game spent 15 years in development because the creators were never happy with it, constantly felt it needed to be better than the competition and always fretted about what engine might be the 'best possible choice' for the title. That wasted millions of dollars, years of people's lives and all manner of resources for a game that would have been better released after three or four years with a couple of sequels down the line. And lots of non game examples exist there too. I'm sure you can name amazing systems that took so in development due to 'doing everything properly no matter the cost' that their nimbler competitors ate them for lunch. At the same time, you can also likely remember many examples where products got released without enough care and attention put into the coding site (or quality control in general) and it just slaughtered their reputation and long term popularity. It's a fine line you have to wander, and one that can sink a product or service if you go too far off track.
jrochkind1 9y ago
> People talk about executive functioning like it’s a general thing, but I’m just as helpless as my nephew when digging into a new codebase or project. Spending all your energy on details means having no attention left over to plan. Each problem you solve becomes an all-consuming distraction. This.
mjevans 9y ago
There still needs to be a clear understanding of what 'done' is. By my reading the old definition of 'perfect' is "fulfills the important criteria of being done". For a boat that meant "didn't sink" (so done is like completed, while perfect is 'completed and useful').
daemonk 9y ago
"Good enough" is often very subjective.
panic 9y ago
Maybe this works in the short term, but if your policy is always to "deliver something, anything", you'll find it harder and harder to deliver anything, and more and more bugs appearing when you do. You need to understand the meaning of the code to successfully change it. Code written following this "deliver anything" policy will tend to have unclear, inconsistent, or flat-out nonexistent meaning. Further changes written like this will keep eroding the meaning until you're left with a program that can only be understood in terms of what happens when you run it. You can never be confident making changes to a program like this, because you don't have a coherent understanding of how each change will affect the system as a whole: all you know is how it will change the behavior when the system is run in a particular way. You don't have to be a perfectionist to understand this!
- btschaegg 9y ago
  > Code written following this "deliver anything" policy will tend to have unclear, inconsistent, or flat-out nonexistent meaning. Funnily enough, "quick & dirty" code also often seems to ignore obvious easy solutions to any given problem and instead pursuits more cryptic/unmaintainable ones. That's the thing that bothers me the most when I'm encountering that sort of thing: It isn't just "a bit ugly" - more often than not it's hacked together using methods that merely almost work when there's a perfectly viable option that has been there since the 70s. And - on top of that - it usually even locks you in on those horrible decisions. Example: You have to configure a piece of software. The configuration is highly critical and must be maintainable and synchronizable between systems. There are tools that put their entire configuration in a database and sell it as a feature. To sum up: - You can't properly version said database - You can't diff said database - You can't grep said database - Reading the config takes ages if you can't use a different shoddy tool - Writing it manually is nigh on impossible - Errors get very obscure since you have to provide tables and IDs as references ...then why the hell aren't we just using text files for that? You could even insert the text verbatim into a table record and be better off.
flohofwoe 9y ago
When I went through my toolmaker apprenticeship a long time ago, the first rule that our master hammered into our brains was "Not as accurate as possible, but as accurate as required". The tool didn't work any better if the accuracy was better than specified, so trying to make it better was considered a waste of time. It helped that the required accuracy was usually part of the specification, while software quality is mostly a subjective thing.
- deleted 9y ago
  [deleted]
acscott 9y ago
If everything is always changing, then the perfect happens only one moment in time and the next moment the perfect is gone. Secondly, you can only influence things to perfection and when they hit perfect, you got lucky. You cannot make it happen. With design, there must be some way to be objective to evaluate a design. If there is no objective, then how can you establish, know and recognize what is perfect? A witty saying proves nothing -- Voltaire.
combatentropy 9y ago
The merits of the advice aside, the foundation of his argument and the headline itself are wrong. What about Platonism? And the Sapir-Whorf hypothesis needs to die. I guess this isn't meant to be a serious work of scholarship anyway, with footnotes like, "For the life of me I can’t remember where I read this."

83 points by awinter-py 9y ago

Trite and worthless. I've never yet seen a project that got perfect (or attempted to do so and ever shipped or delivered) and it is almost never a goal. The tug of war is more often between putting unfinished things into production and some random deadline set by a person who knows nothing about the required amount of work to have a correct result. (Much less decent or maintainable.) Not negotiable or adjustable too. Even the sc(r)um approach of cutting features has limitations. At some point the customer will just be unhappy.

Practicality 9y ago
It's just a blog post about what he has observed as a common problem with teams falling behind. I think it's a little much to call it worthless. Excessive focus on unimportant details is a real problem. Everybody probably naturally focuses either too much on details or too little, and this person recently ran into some teams that focused on them too much, preferring to polish features the customer didn't care about rather than finishing the product.

amelius 9y ago

Write an imperfect foundational library, and watch everything built on top of it crumble down at some point. Perfection has its uses.

khedoros1 9y ago
Something can be imperfect but sufficient, or just plain insufficient. I don't think I've ever seen a perfect piece of software.
onion2k 9y ago
I don't think that's true. For example, it doesn't get much more foundational than glibc and that isn't perfect[1]. There's definitely a level of quality than needs to be reached, but that's some way short of perfection. Sometimes it's more useful to move forwards despite problems than to wait for them to be fixed. [1] https://sourceware.org/bugzilla/buglist.cgi?bug_status=__open__&no_redirect=1&order=Importance&product=glibc&query_format=specific https://sourceware.org/bugzilla/buglist.cgi?bug_status=__ope...

toanjc783tome 9y ago

I think most of what he says is correct, but it doesn't seem to address the actual problem I run into. The problem I see with my group's projects is not that we're trying to make it perfect. That almost never happens. Instead, management wants us to "just get it done," and "stop wasting time planning," and we end up with something that doesn't work well and is hard to maintain. Where a few days of pre-planning would have pointed out some areas where we were likely to get stuck and given us enough foresight to think up a better (but not perfect) architecture that we could implement in the time allotted. It still wouldn't be perfect, but it would be good instead of bad, which is what we end up shipping usually.

darkerside 9y ago
What I've found is that those days of pre-planning can be hit or miss. Yes, you might uncover a design flaw or missed requirement that would have set you off in the wrong direction. However, a prototype implementation is much more likely to uncover those same flaws, and probably also a few that you never would have found without building a prototype. I've found the prototype approach leads to a far higher likelihood of success. I think the real challenge with it is getting management to understand what is a prototype and what is a finished product, the danger being that you ship the prototype. Of course, this is all highly dependent of the nature of your work and length of development cycles. But if you're shipping in weeks, I'd wager you should be planning for hours at a time, not days.

agentgt 9y ago

I'm fairly certain the lunar landing required perhaps not perfection but pretty damn close planning. Modern heresy is applying anecdotal solutions to situations as learnings for all problems.

awinter-py 9y ago
well, yes and no. The apollo program operated on a tick-tock schedule where they did progressively harder missions. I interpret this as a series of proof-of-concept deliverables which allowed the team to develop expertise. Then later they could define & hit their tolerances for orbital mechanics, fuel budgets, system redundancy. Same deal with faraday / maxwell / einstein. The experimenter (faraday) measured & applied new phenomena, then maxwell came up with general laws, then einstein figured out their implications.

wellpast 9y ago

This is straight from the cowboy coder's mouth. This is Philistinism, plain and simple. > "...deliver something, anything...", no need to make it good, "teams make things better," anyway. No, no, and no. If you want to scale a team you have to deliver quality code. The cowboy coder spews out code, screams "see it works!", and then moves on to produce more diarrhea for "the team" behind him to clean up, "make better"... When one realizes they do not yet have a skill (such as producing quality code), it is tempting to scream "quality/perfection is a heresy" because this is much, much easier to say than the labor it takes to develop the skill. > It’s hard to see more than a week out because anything that takes more than a week to build involves R&D. Wrong, wrong, and wrong. MOST of what we do as practitioners (for those that have been doing it for at least some time) is NOT novel. Estimation is a skill. Estimates can be extremely accurate for those of us that have developed that skill. It is much easier to say "estimation is worthless" when it is a skill that you have not yet developed. Because it is only developed through (often frustrating) practice. Record the time it takes to do your work. Notice the patterns of problems that you face and how often they repeat themselves. --- Perfection per se has its hazards but in no way should that truth get us off the hook from developing ourselves and doing our work well. This post is nothing but dangerous to the nascent programmer-practitioner as it attempts to lull them away from what is possible and the work it takes to get there. Perfection is not attainable, but if we chase perfection we can catch excellence. -- Vince Lombardi

mjw1007 9y ago
Some new programmers need the advice to spend longer improving their code before sharing it; some need the opposite advice. Unfortunately, some people who dispense advice pick one of those "directions" and argue strongly for it, rather than trying to describe how to recognise when you've got the balance right.
- hashmal 9y ago
  Sadly a lot of people have a hard time understanding nuance and middle-grounds. In programming or in anything else. If your code is to be thrown away in one week, why make it perfect? If you have to maintain it for years, why make it a pile of shit? Funnily enough you can't often predict the lifetime of code.

b1daly 9y ago

One thing to consider is that different types of projects have different "thresholds " of "good enough." This is also highly dependent on the available competition to your product. At this point, unless there is some fantastic new application, anything intended for use by "ordinary consumers" better be nearly perfect to even have a chance. I've observed with user interface design that there is often a stark threshold between "usable " and "unusable", and that it takes a perfectionist mindset to reach it.

mwfunk 9y ago

This is one of those conversations that has been going on for decades (if not centuries or millennia). If your life involves making something in private, then putting it out there for other people to see/buy/whatever, every such project requires you to decide when its done and ready for the world. Getting it out there sooner can be appealing if time is a factor. Spending extra time perfecting it is appealing if time is not a factor. It's just two poles between which you set a cutoff point, and in team efforts everyone will not only have different ideas about whether time or quality is more important, but they will have different perceptions about what it even means to be closer to one pole. You're always compromising something in engineering, no matter which pole exerts a stronger pull on you. Putting a flawed product out early might kill the product; you should've put the development time cutoff point closer to the 'perfection' pole. On the other hand, spending extra weeks or months or years polishing something that ends up not being not quite what anyone wanted is also bad, because if you had just gotten something out there sooner, you could've spent the same amount of time iterating on it in response to feedback. Lots of extra time spent on something often also translates into getting locked into technical choices that can be more difficult to back out of later if necessary. So there's definitely something to be said for putting a simpler and less-polished product out sooner to get feedback and test your initial assumptions vs. reality. I think these conversations never cease in part because so many people who argue about this stuff are treating it as a binary choice. They're not picking a cutoff point between two poles, they're picking a pole and going all in on it. In reality, they see different sets of pros and cons and weight them differently and see risk differently. The solution is better communication between people so that there is at least a shared set of known pros and cons. People might still not agree, but they can at least have the same conversation when weighing compromises. People who get into binary thinking patterns about situations which no one person fully grasps are being rational in their own way; they just don't understand that they are compromising something else. In my experience, people rarely see things in black and white once they understand how the opposing side views the situation. Both sides are rational, they just have disjoints areas of knowledge and thus priorities.

CM30 9y ago

Well, while I don't think perfectionism is always a bad thing and releasing 'any old thing' as quickly as possible it's always a good idea, I definitely see where he's coming from. There's a balance you have to strike here between 'done quickly' and 'done perfectly', and pushing towards either end can doom your project. I mean, look at Duke Nukem Forever. The game spent 15 years in development because the creators were never happy with it, constantly felt it needed to be better than the competition and always fretted about what engine might be the 'best possible choice' for the title. That wasted millions of dollars, years of people's lives and all manner of resources for a game that would have been better released after three or four years with a couple of sequels down the line. And lots of non game examples exist there too. I'm sure you can name amazing systems that took so in development due to 'doing everything properly no matter the cost' that their nimbler competitors ate them for lunch. At the same time, you can also likely remember many examples where products got released without enough care and attention put into the coding site (or quality control in general) and it just slaughtered their reputation and long term popularity. It's a fine line you have to wander, and one that can sink a product or service if you go too far off track.

jrochkind1 9y ago

> People talk about executive functioning like it’s a general thing, but I’m just as helpless as my nephew when digging into a new codebase or project. Spending all your energy on details means having no attention left over to plan. Each problem you solve becomes an all-consuming distraction. This.

mjevans 9y ago

There still needs to be a clear understanding of what 'done' is. By my reading the old definition of 'perfect' is "fulfills the important criteria of being done". For a boat that meant "didn't sink" (so done is like completed, while perfect is 'completed and useful').

daemonk 9y ago

"Good enough" is often very subjective.

panic 9y ago

Maybe this works in the short term, but if your policy is always to "deliver something, anything", you'll find it harder and harder to deliver anything, and more and more bugs appearing when you do. You need to understand the meaning of the code to successfully change it. Code written following this "deliver anything" policy will tend to have unclear, inconsistent, or flat-out nonexistent meaning. Further changes written like this will keep eroding the meaning until you're left with a program that can only be understood in terms of what happens when you run it. You can never be confident making changes to a program like this, because you don't have a coherent understanding of how each change will affect the system as a whole: all you know is how it will change the behavior when the system is run in a particular way. You don't have to be a perfectionist to understand this!

btschaegg 9y ago
> Code written following this "deliver anything" policy will tend to have unclear, inconsistent, or flat-out nonexistent meaning. Funnily enough, "quick & dirty" code also often seems to ignore obvious easy solutions to any given problem and instead pursuits more cryptic/unmaintainable ones. That's the thing that bothers me the most when I'm encountering that sort of thing: It isn't just "a bit ugly" - more often than not it's hacked together using methods that merely almost work when there's a perfectly viable option that has been there since the 70s. And - on top of that - it usually even locks you in on those horrible decisions. Example: You have to configure a piece of software. The configuration is highly critical and must be maintainable and synchronizable between systems. There are tools that put their entire configuration in a database and sell it as a feature. To sum up: - You can't properly version said database - You can't diff said database - You can't grep said database - Reading the config takes ages if you can't use a different shoddy tool - Writing it manually is nigh on impossible - Errors get very obscure since you have to provide tables and IDs as references ...then why the hell aren't we just using text files for that? You could even insert the text verbatim into a table record and be better off.

flohofwoe 9y ago

When I went through my toolmaker apprenticeship a long time ago, the first rule that our master hammered into our brains was "Not as accurate as possible, but as accurate as required". The tool didn't work any better if the accuracy was better than specified, so trying to make it better was considered a waste of time. It helped that the required accuracy was usually part of the specification, while software quality is mostly a subjective thing.

deleted 9y ago
[deleted]

acscott 9y ago

If everything is always changing, then the perfect happens only one moment in time and the next moment the perfect is gone. Secondly, you can only influence things to perfection and when they hit perfect, you got lucky. You cannot make it happen. With design, there must be some way to be objective to evaluate a design. If there is no objective, then how can you establish, know and recognize what is perfect? A witty saying proves nothing -- Voltaire.

combatentropy 9y ago

The merits of the advice aside, the foundation of his argument and the headline itself are wrong. What about Platonism? And the Sapir-Whorf hypothesis needs to die. I guess this isn't meant to be a serious work of scholarship anyway, with footnotes like, "For the life of me I can’t remember where I read this."