Last week half of civilization came to a grinding halt because of the crappy engineering practices of a single company. I don't know if now is the right time to complain about perfectionism in IT.
The article is pretty muddled, in large part because they don't seem to really understand what perfectionism is. Their anecdotes aren't really about perfectionism at all, they're about times when they didn't pay attention to the context they were working in and made poor decisions as a result (usually because of inexperience).
In other words, it's not perfectionism that's the productivity killer they've identified, it's inexperience.
I'm a perfectionist in the clinical sense. Shipping something that I know is imperfect gives me a high amount of anxiety. But I also have enough experience to avoid wasting my time on things that I now understand don't matter.
I don't get anxiety about not having the perfect abstraction anymore, I get anxiety about things like whether we have enough monitoring in place, whether our release plan will cause problems in prod, or whether I considered all the edge cases in this critical piece of security-related code.
The perfectionism isn't gone, but it's not really hindering my progress in my career because it's focused on the things that actually matter. I'm working on addressing the anxiety aspects of my perfectionism, but that's a mental health issue, not a software development cycle issue.
It depends entirely on how you define perfectionism. The article unfortunately doesn't explain well what they meant.
Assuming it is following, paradigms, design patterns and making the code "cleaner", then I would agree with the article 100%.
However if it was about actual engineering concerns like better error handling, performance, test coverage, nailing down invariants/validation/parsing, etc. Then I would say that we should probably be more diligent rather than less.
The issue is that the former gets too much attention and the latter too little.
I was thinking the same thing. The state of software is generally so poor, lacking any attention to detail and showing a disregard for the customer (who has been reduced to a single “revenue” line item in a financial analysis).
There’s an epidemic of “minimum viable” when it comes to software, and that results in flying really close to “not viable”.
How do you know perfectionism didn’t cause the issue? Perhaps some team has been laboring for months or years on an actual rollout system to replace what they’ve got, but have never shipped because things took too long.
If we had a professional association for software engineers that was nationally recognized one benefit of this would be around standards and practices being set industry wide and having a professional association that advocates on behalf of engineers to have them enforced.
Other engineering professions do have precedent shown for this.
The perfectionists I have worked with were never the ones advocating for rolling out releases to users. The _only_ thing that can prevent catastrophes like Blue Friday.
I think standards could be higher while perfectionism could be lower. I'd even go as far as to argue that perfectionism is a contraindicator to quality software and high standards.
Perfectionism doesn't necessarily mean better implementations, good practices, or even doing the right thing. Chasing and stacking needless abstractions to make things appear clean is an example of such perfectionism that actually harms the industry and erodes standards.
Perfectionism is not a fix for this. Indeed, perfectionism can be a cause, by diverting energy and attention away from critical things toward polishing the spot on the wall in the basement while the load bearing walls and electrical wiring remains unaddressed.
I would argue that perfectionism is also about an inability to prioritize, something which, in the real word with all its time limits, will bite you.
Only in the scope of the IT nerds. Average people I'm betting have no idea that anything happened especially if you work with your hands. Its the same old day to day out the window. The sky didn't fall.
Yeah, but I don't think we all need to define our engineering practices by what should be considered the norm for a company deploying software that operates in kernal mode to millions of devices globally. Most of us aren't doing that (thankfully).
On the other hand, I couldn't count the hours of my career that I've wasted perfecting some piece of functionality - either at someone else's behest, or due to my own motivation/professional pride - that ultimately nobody gave a shit about.
I don't really want to do that any more, and I get pretty fed up pretty quickly when some PM (or whoever else) pushes me to do something that I know ultimately isn't going to matter. I can add a lot more value to a team than by simply churning out code, and it's frustrating being in situations where I'm not allowed to do that and am instead forced to waste time endlessly fiddling with stuff that doesn't add a lot of value for users and customers.
And I'm not talking about compromising on UX or anything like that: I mean actually spending time building functionality that doesn't get used. Or spending too long on barely used and non-key workflow aspects[0].
What's the point?
[0] A really great example of a barely used but ABSOLUTELY CRITICAL piece of functionality is the export/publish functionality in Ableton Live (it's a while since I used it so I can't remember exactly how it's labelled). This is a piece of functionality that is barely used compared with other functions, at least by many of us, but it's also - in some sense - the whole point of the application in the first place because it enables you to export or publish a finished piece of music, so it needs to work and work well.
Perfectionism is the practice of seeking perfection, not achieving it. Lots of devs spend time not shipping because they feel their code isn't good enough. Meanwhile Crowdstrike built a $62bn company shipping things. Poor quality things that break the internet, but that's kind of besides the point.
If you want to build value you must ship, even if the thing isn't ready yet because otherwise it will never ship and there will never be any value realized.
I have very rarely run into the situation where I have put too much polishing into a piece of software to the point where its had a material impact on the project. However the opposite where there is pressure to rush and push out something that isn't really ready has been a very common problem to have to manage.
I think we see the results of rushing in all the software around us much more than we see the delays of perfectionism.
Depends on who's calling the shots. Last few years dev market was so crazy management walked on eggshells to avoid pissing off engineers in most places I've worked at. As a result I've seen plenty of situations where abstractions and tech choices lead to delivery delays and business impact - followed by engineers responsible scramming for next position with latest buzzwords added to CV.
Thankfully the market correction made this much less of an issue.
Yes, most places I've seen could barely get a minimally functioning product out. There is never even the opportunity to get to the point where an engineer's perfectionism might kick in. I've seen projects that spit out an average of 5 lines of compiler warnings for 1 line of source code, and that's when the code actually could be built successfully. The big open secret of the software industry is how barely everything works.
I practice my perfectionism at home, on hobby projects, where I can run lint with every option if I want, and resolve every warning, static analysis issue, style issue, I can profile my code and find/fix slow parts. I can run valgrind on it and find memory leaks. And I never have to release the software! None of these things were common practice in any software job I've ever had. It was always "Get it to barely work and then ship ship ship!"
I've seen many people treat software like some sort of art project, and spend much time refactoring things, rewriting perfectly functioning systems, and generally creating little to nothing of value and generating tons of meaningless churn.
While the article doesn't offer specific examples, it's probably talking about this sort of stuff. e.g. "perfecting code, often code that hadn’t been touched in years and didn’t need to be touched". This sounds like a classic "oh, this isn't how I would have written it, so let me just refactor everything here".
"Not how I would have written it" does not equal "bad".
This isn't making the code better, less bug-free, or "more perfect" in any way. Actually, it often introduces bugs.
My favorite quote on perfectionism and one I often think about,
"You know, the whole thing about perfectionism — The perfectionism is very dangerous, because of course if your fidelity to perfectionism is too high, you never do anything. Because doing anything results in … It’s actually kind of tragic because it means you sacrifice how gorgeous and perfect it is in your head for what it really is." - David Foster Wallace
Anyone that has built and shipped something has likely struggled with it. You have a great idea. You build it and it's never as great as it was in your head. You need to ship it anyway, but doing so means getting over that perfectionism. Some can. Most can't.
Thanks, I needed to have this thought formalized. I see now why I have a hard disk full of perfectly architured dead projects, and also why the live ones are never going to be perfect
This feels a little like confusing early career learning with perfectionism. The stories involve their own junior career where they were learning what good code should be and trying to apply it. Later, as they write better code without needing to learn they are shipping higher quality code faster.
That depends. Shipping too much too fast without making the base that can handle it properly results in a ton of tech debt that will bite you in the end one way or another. So there must be some balance about it.
The "we'll fix it later" turning into "no one ever fixed it" is way too common of a pitfall.
Yeah, that's a big one. In one case I reproduced a bug that had been plaguing us for a decade but could never seem to reproduce when it happened to a customer.
Then the lore came out that the original programmer had slapped it together over a weekend. It worked in the lab, and mostly worked in the field but failed sometimes in weird ways.
Then engineering tried fixing it. They failed three times, so they decided to replace that feature. It took two years to replace that one feature and get it to work right. It didn't kill the company, because it was a less used feature, but it reduced trust in the marketplace so growth took a hit that let other take and keep the lead.
Also the reason we can cross rivers without the bridges collapsing, why we have skyscrapers that withstand earthquakes in Japan, and we were able to launch an international space station into orbit.
Now that the prevailing school of thought is that shipping crap is OK we have a checks notes Boeing Starliner.
Something to consider is that if you cut quality to the point that your colleagues believe you are pushing a half-baked product, or they have to spend even a small amount of time fixing what they know could have never been a problem in the first place, their morale is going to tank - and the brightest are going to leave first.
On an individual level, if you are prone to perfectionism, take heed of its dangers to your mental health and productivity.
On an organizational level, perfectionism is a red herring. Yes, there is such thing as debilitating perfectionism, but 95% of "perfectionists" are really just people who care a lot about doing things properly (providing all the benefits that begets), but who aren't 10x greybeards, so they take longer to do it than a cheap dev would to shit out what looks like the same product at first glance.
(You can say the same thing about "premature optimization", perhaps to a lesser extent.)
I’m more of a 75-80% perfect guy at most Fortune 500 companies. That 90-95% perfectionism is very hard to achieve and honestly not worth the effort.
Nothing wrong with “perfectionism” but it should be achieved as a team and that requires getting good people around you. Unfortunately, in my experience, that’s where it usually falls apart.
Clueless management continues to think hiring at the bottom of the barrel and “training” them is the right way to go. There’s a reason why they are taking the lowest possible bid…
My experience with software is 80% or more is slop that could have used more perfectionism. Most engineers couldn’t create a perfect piece of software even if they wanted to. Get to the point where you have that ability and then dial it back as needed. Don’t spend your entire life writing slop that users hate but makes your managers look good because they hit some arbitrary shipping KPI.
Jordan says that a high volume of changes early in their career was a waste. Maybe for the team, but I would argue the experience gained from many low impact changes was probably better in the long run. It’s better to overshoot and dial back than be lacking, especially early on in a career.
"Productivity" means shipping the first 3 features fast, then getting overwhelmed in spaghetti and unreliability, things slow down to a halt, and the features you shipped turn out to be buggy.
The desire of money people to sell hack/slash/burn kind of products to customers is so pervasive nowadays, that there is no wonder why we have:
- the Boeing travesty (people actually die because of this)
- the CrowdStrike debacle (who needs functioning airports and hospital appointments?)
- the AT&T hacks
And some manager type (who probably did a 1 month business course and is also a certified Scrum master) is gonna tell you to "ship faster, value, value, value". The disdain I have for them has no bounds.
Absolutely guilty of that! Although the article mainly focuses on software that I also assume isn’t critical, sometimes you have to get the work done perfectly, or it’s a major risk or an overall issue for the project success. For example, if you are designing, building, and programming a drone, the margin for error is slim. A single issue that you are not even directly responsible for can jeopardize the whole project, like if a cellular drone control link (C2) is down. Or you are working on an ICS that controls utilities or nuclear plants. So, you have to perfect all scenarios and outcomes, plus all possible testing too.
Don't even want to read this, especially considering software nowadays is not nearly as good or even close to perfection.
Last year's CrowdStrike crapware incident made critical infrastructure crash, flights delayed, hospital appointments delayed.
I'd say to the business people to f*ck off and leave the engineering to us, the engineers. Stop trying to squeeze every drop of "productivity" from everything.
It's done when we say so, and it's good enough when we say so. Go sit in some Zoom meetings or something, and leave us to work.
[+] [-] jsiepkes|1 year ago|reply
[+] [-] lolinder|1 year ago|reply
In other words, it's not perfectionism that's the productivity killer they've identified, it's inexperience.
I'm a perfectionist in the clinical sense. Shipping something that I know is imperfect gives me a high amount of anxiety. But I also have enough experience to avoid wasting my time on things that I now understand don't matter.
I don't get anxiety about not having the perfect abstraction anymore, I get anxiety about things like whether we have enough monitoring in place, whether our release plan will cause problems in prod, or whether I considered all the edge cases in this critical piece of security-related code.
The perfectionism isn't gone, but it's not really hindering my progress in my career because it's focused on the things that actually matter. I'm working on addressing the anxiety aspects of my perfectionism, but that's a mental health issue, not a software development cycle issue.
[+] [-] dgb23|1 year ago|reply
Assuming it is following, paradigms, design patterns and making the code "cleaner", then I would agree with the article 100%.
However if it was about actual engineering concerns like better error handling, performance, test coverage, nailing down invariants/validation/parsing, etc. Then I would say that we should probably be more diligent rather than less.
The issue is that the former gets too much attention and the latter too little.
[+] [-] trentnix|1 year ago|reply
There’s an epidemic of “minimum viable” when it comes to software, and that results in flying really close to “not viable”.
[+] [-] lostdog|1 year ago|reply
And most people are wrong about which group they're in.
[+] [-] savanaly|1 year ago|reply
[+] [-] no_wizard|1 year ago|reply
Other engineering professions do have precedent shown for this.
[+] [-] fmbb|1 year ago|reply
[+] [-] PartiallyTyped|1 year ago|reply
Perfectionism doesn't necessarily mean better implementations, good practices, or even doing the right thing. Chasing and stacking needless abstractions to make things appear clean is an example of such perfectionism that actually harms the industry and erodes standards.
[+] [-] lo_zamoyski|1 year ago|reply
I would argue that perfectionism is also about an inability to prioritize, something which, in the real word with all its time limits, will bite you.
[+] [-] kjkjadksj|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] raxxorraxor|1 year ago|reply
[+] [-] ttymck|1 year ago|reply
[+] [-] bartread|1 year ago|reply
On the other hand, I couldn't count the hours of my career that I've wasted perfecting some piece of functionality - either at someone else's behest, or due to my own motivation/professional pride - that ultimately nobody gave a shit about.
I don't really want to do that any more, and I get pretty fed up pretty quickly when some PM (or whoever else) pushes me to do something that I know ultimately isn't going to matter. I can add a lot more value to a team than by simply churning out code, and it's frustrating being in situations where I'm not allowed to do that and am instead forced to waste time endlessly fiddling with stuff that doesn't add a lot of value for users and customers.
And I'm not talking about compromising on UX or anything like that: I mean actually spending time building functionality that doesn't get used. Or spending too long on barely used and non-key workflow aspects[0].
What's the point?
[0] A really great example of a barely used but ABSOLUTELY CRITICAL piece of functionality is the export/publish functionality in Ableton Live (it's a while since I used it so I can't remember exactly how it's labelled). This is a piece of functionality that is barely used compared with other functions, at least by many of us, but it's also - in some sense - the whole point of the application in the first place because it enables you to export or publish a finished piece of music, so it needs to work and work well.
[+] [-] j45|1 year ago|reply
It wouldn’t have existed lol
[+] [-] Gud|1 year ago|reply
this was not the failure of a single company.
[+] [-] smcleod|1 year ago|reply
1. Crowdstrike 2. Microsoft 3. The companies that think it’s a good idea to run what is essentially an enterprise rootkit
[+] [-] onion2k|1 year ago|reply
If you want to build value you must ship, even if the thing isn't ready yet because otherwise it will never ship and there will never be any value realized.
[+] [-] PaulKeeble|1 year ago|reply
I think we see the results of rushing in all the software around us much more than we see the delays of perfectionism.
[+] [-] actionfromafar|1 year ago|reply
[+] [-] rafaelmn|1 year ago|reply
Thankfully the market correction made this much less of an issue.
[+] [-] ryandrake|1 year ago|reply
I practice my perfectionism at home, on hobby projects, where I can run lint with every option if I want, and resolve every warning, static analysis issue, style issue, I can profile my code and find/fix slow parts. I can run valgrind on it and find memory leaks. And I never have to release the software! None of these things were common practice in any software job I've ever had. It was always "Get it to barely work and then ship ship ship!"
[+] [-] arp242|1 year ago|reply
While the article doesn't offer specific examples, it's probably talking about this sort of stuff. e.g. "perfecting code, often code that hadn’t been touched in years and didn’t need to be touched". This sounds like a classic "oh, this isn't how I would have written it, so let me just refactor everything here".
"Not how I would have written it" does not equal "bad".
This isn't making the code better, less bug-free, or "more perfect" in any way. Actually, it often introduces bugs.
[+] [-] TylerE|1 year ago|reply
I'll take a 95% solution delivered in 2 weeks over a 99% one delivered in 2 months.
[+] [-] candiddevmike|1 year ago|reply
Give the engineers clear requirements and let them interact with the stakeholders. Get rid of the intermediaries and knowledge brokers.
[+] [-] llmblockchain|1 year ago|reply
"You know, the whole thing about perfectionism — The perfectionism is very dangerous, because of course if your fidelity to perfectionism is too high, you never do anything. Because doing anything results in … It’s actually kind of tragic because it means you sacrifice how gorgeous and perfect it is in your head for what it really is." - David Foster Wallace
Anyone that has built and shipped something has likely struggled with it. You have a great idea. You build it and it's never as great as it was in your head. You need to ship it anyway, but doing so means getting over that perfectionism. Some can. Most can't.
[+] [-] jiiam|1 year ago|reply
[+] [-] rectang|1 year ago|reply
[+] [-] EatFlamingDeath|1 year ago|reply
[+] [-] ozgrakkurt|1 year ago|reply
[+] [-] dgb23|1 year ago|reply
[+] [-] chewbacha|1 year ago|reply
[+] [-] shmerl|1 year ago|reply
The "we'll fix it later" turning into "no one ever fixed it" is way too common of a pitfall.
[+] [-] GarnetFloride|1 year ago|reply
Then the lore came out that the original programmer had slapped it together over a weekend. It worked in the lab, and mostly worked in the field but failed sometimes in weird ways.
Then engineering tried fixing it. They failed three times, so they decided to replace that feature. It took two years to replace that one feature and get it to work right. It didn't kill the company, because it was a less used feature, but it reduced trust in the marketplace so growth took a hit that let other take and keep the lead.
[+] [-] fefe23|1 year ago|reply
Now that the prevailing school of thought is that shipping crap is OK we have a checks notes Boeing Starliner.
[+] [-] sigotirandolas|1 year ago|reply
[+] [-] tracerbulletx|1 year ago|reply
[+] [-] trentnix|1 year ago|reply
[+] [-] thelastparadise|1 year ago|reply
The thing that's killing productivity is the pushing out of half baked garbage.
There's simply no solid foundation to build upon.
OK short game but horrible long game.
[+] [-] happytoexplain|1 year ago|reply
On an organizational level, perfectionism is a red herring. Yes, there is such thing as debilitating perfectionism, but 95% of "perfectionists" are really just people who care a lot about doing things properly (providing all the benefits that begets), but who aren't 10x greybeards, so they take longer to do it than a cheap dev would to shit out what looks like the same product at first glance.
(You can say the same thing about "premature optimization", perhaps to a lesser extent.)
[+] [-] xyst|1 year ago|reply
Nothing wrong with “perfectionism” but it should be achieved as a team and that requires getting good people around you. Unfortunately, in my experience, that’s where it usually falls apart.
Clueless management continues to think hiring at the bottom of the barrel and “training” them is the right way to go. There’s a reason why they are taking the lowest possible bid…
[+] [-] jackblemming|1 year ago|reply
[+] [-] dexwiz|1 year ago|reply
[+] [-] dgeiser13|1 year ago|reply
[+] [-] Buttons840|1 year ago|reply
Half the nation's personal data is breached every week and we're over here talking about how we need more productivity and less perfection.
[+] [-] ath3nd|1 year ago|reply
The desire of money people to sell hack/slash/burn kind of products to customers is so pervasive nowadays, that there is no wonder why we have:
- the Boeing travesty (people actually die because of this) - the CrowdStrike debacle (who needs functioning airports and hospital appointments?) - the AT&T hacks
And some manager type (who probably did a 1 month business course and is also a certified Scrum master) is gonna tell you to "ship faster, value, value, value". The disdain I have for them has no bounds.
[+] [-] tamimio|1 year ago|reply
[+] [-] simonw|1 year ago|reply
[+] [-] ath3nd|1 year ago|reply
Last year's CrowdStrike crapware incident made critical infrastructure crash, flights delayed, hospital appointments delayed.
I'd say to the business people to f*ck off and leave the engineering to us, the engineers. Stop trying to squeeze every drop of "productivity" from everything.
It's done when we say so, and it's good enough when we say so. Go sit in some Zoom meetings or something, and leave us to work.