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.
> I'll take a 95% solution delivered in 2 weeks over a 99% one delivered in 2 months.
This depends a lot on the context. If I deliver the 95% in 2 weeks can I ship an update in 2 months that delivers the 99%, or are we stuck forever at 95% (due to technical limitations or business reality)?
If I'll be able to deliver the 99% soon, then sure, let's ship the 95% sooner rather than later.
But if for whatever reason I realistically cannot do that, then you have to consider the context. What is left out in the 95%? How soon will it be a problem that we're missing that remaining 4%? Who will notice the missing pieces? Will they be able to work around their absence?
Many times you may still come to the conclusion that the 95% is the right move, but sometimes it's better to not offer the two-week plan as an option if the fallout from that missing 4% is going to be high.
This is exactly the analysis that is missing from the article and any facile, absolutist statement decrying “perfectionism”. Productivity is an optimization problem. There are tradeoffs which have to be managed. Depending on the context (e.g. prototype phase vs mature, widely used software) you manage those tradeoffs differently.
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.
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.
This article is fluff trying to fill up their blog so they can sell paid subscriptions and have "engagement". They even link to one of their paid blog posts.
And said engineers often end up wishing they hadn't. Interacting directly with stakeholders isn't all it's cracked up to be.
Maybe I've just had good luck with product managers, but I tend to enjoy my work the most when someone else is filtering the stakeholders' long and constantly changing wishlist for me and turning it into something coherent and actionable.
That's how it was in the initial days/years. However those days are long gone.
Now there are these Product Managers who have absolutely no clue how software is built.
Interestingly I'm seeing similar trend in many other fields; my car goes to servicing and there's some dude who just knows jargons interfacing with me, for the minutest of my questions he will "get back to me after consulting the line workers", same with my house construction. I had to get through 4 layers of people to finally get to the person who is actually doing the electrical wiring to clearly explain what is it that I wanted.
> my car goes to servicing and there's some dude who just knows jargons interfacing with me, for the minutest of my questions he will "get back to me after consulting the line workers"
That's because he's not there to explain what they are doing. He likely doesn't know a spark plug from a fuel injector. He's there to sell you more services.
I see no tools in this article for managers who wish to optimize the productivity of their team while taking into account the natural, unfortunate, human tendency towards perfectionism. It’s an unsophisticated and unrevealing analysis.
Spot on, it’s so frustrating with all these hoops some companies put in place, and the middle managers at some point start to act as wranglers.. Not to mention the gap that always happens between the engineers (who build and do the work) and the clients or stakeholders (who require the work), which always ends up with last-minute changes and fixes before the demo.
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.
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.
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.
In the second paragraph you name what seems to be your definition of perfectionism. I can't say I agree with it, because to me it seems to move away from perfect.
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.
Tom DeMarco (co-author of 'Peopleware' and other SE classics) has argued that the market is a better selection mechanism than a certifying body, which tends toward seizure of power rather than societal good. I can't turn up the original article, but Jeff Atwood quotes the relevant bits [0].
I'm not convinced that either certification itself or the market represent the most effective means to achieving societal good. I think what history shows is that real consequences for shoddy work are required [1]. To date, software makers haven't really been held liable for consequences, but I expect that will change if we don't clean up our act.
[1] "229 If a builder builds a house for someone, and does not construct it properly, and the house which he built falls in and kills its owner, then that builder shall be put to death."
I think it any make sense for critical infrastructure, but the software industry is still in high growth mode.
Allowing individual engineers to be de-licensed creates a culture adherence to norms is the priority. If you ever worked with a civil engineering organization… it’s not exactly a hotbed of innovation. Alot of the professional associations spend more time creating make-work regulations than actual safety or engineering. For example, in New York, something as trivial as refurbishing a moderate volume street crossing in an urban area requires $750k-$1M of services to address ADA compliance, multi-modal transit accommodation and other factors.
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.
Whatever the reason for CrowdStrike's failure, a lazy attitude toward allowing vendors to push updates at any time in the name of a dubious "best practice" for security reasons let the bug have massively wider reach than it should have. Sysadmins should have instead thought more critically about the value disallowing such updates and pinning dependency versions to ensure they can predictably know what's running on the machines they manage, and subscribing to alerts about security holes they need to update and making informed decisions like seeing how the new updates are actually working in the wild instead of handing over the keys blindly. Want to call that "perfectionism"? Be my guest.
By what standard would you evaluate a AV definition?
Crowdstrike had a sloppy process without meaningful testing, only parser validation. Assigning that task to tens of thousands of admins, most of whom have no idea what they are doing just shifts blame, not accountability.
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”.
The startup culture celebrates an even lower bar, "not viable but appears to be minimum viable". Think of the fireside stories about launching e.g. an AI image recognizer, while secretly using humans to do the recognition.
Yep. And that deception is presented as wisdom! We are supposed to admire how cunning they are with their fakery.
And what do they all say? “We should have launched sooner.”
That’s what happens when the goal of the vast majority of startups is not to build an actual business. Their goal is to “get funded”. It just feels rotten.
The bar can always be lower, too. Think slideware and vaporware. You don't even need to have a product, let alone a minimally viable one. You just need to convince someone to give you money.
There’s a lot of fluff, that boils down to “we tested the code in march”, “we did not test subsequently”, “we validate the content we push”, and “there was a defect in the content validation process”
Correct. It sounds like they test changes to code in such a facilty, but “content” is only validated by a parser. Mcafee did something similar a decade ago.
It’s a hard problem - the whole point of Crowdstrike is to quickly respond to threats. (And they are very good at it) So you want time to market for marginal changes to be very fast. Normally I’d give them the benefit of the doubt, but their arrogance and poor response triggers my spidey-sense.
MS just provided theirs, it's a bad architecture issue where CS overused the kernel mode, and should have instead done a listener in the kernel and logic in User land.
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.
Clean code leads to more testable code leads to more tests leads to better products.
Don't be so quick to dismiss "clean code" as some BS.
I've seen first hand how someone writing a 500 line function struggles to test it. But splitting it up into more manageable chunks of functionality makes it easier to write a test.
Imo perfectionism is chasing that last 5% performance.
Clean code, design patterns etc are just good engineering practices... Not perfectionism ....
> Clean code, design patterns etc are just good engineering practices... Not perfectionism ....
This is what I don’t like about software engineering. The dogmatism. The absolutism. The more I work in the field, the less I talk about “clean code”, “ddd”, “good practices”. I find myself saying more and more “it depends”, and more often than not what the business requires is not 5 layers of code in which the concerns are separated among dozens of files and following good design patterns, but a damn single file that get things done.
There’s place for what you call good practices and clean code, but many times those things don’t lead to good products.
I really liked how jmac03 put things, and I don’t see the dogma you’re seeing — consider that it’s “struggles to test” not “impossible”. I don’t see any advocacy for ”dozens of files”, just breaking functionality down into “manageable chunks” to facilitate testing. In fact, “dozens of files” are arguably not “manageable“, and I don’t see an argument for that, any more than you’re arguing that every function needs to be 500 lines.
Every single startup I’ve worked for has eventually come to terms with needing some best practices. In my view, there actually is a baseline: CI, partial coverage unit tests for the most easily testable code, and modularization/loose-coupling so that unwinding tech debt has linear rather than exponential cost. But even that is driven by my opinions about ROI, not theory in isolation.
>There’s place for what you call good practices and clean code, but many times those things don’t lead to good products.
Clean code for a bad product won't turn it into a good product. That's the core issue. These are engineering principles but you are looking at them through business logic.
The best metphor here is to compare clean code to insurance. You don't want to insure this? Okay, you can take that risk and maybe save if nothing happens. But if/when something happens it'll be more expensive than if you paid the insurance up front.
Meanwhile, Clean code from a good product will make it resiliant to becoming a bad product. I'm sure if you played any modern video games that you've had at least a few games that you loved but had horrible technical hiccups. Unoptimized, untested logic, crashing. The issue is some of these games still sell, so maybe the business logic prevailed over properly engineered code. But they are entertainment at the end of the day, not Crowdstrike.
In my experience, the people who are best at error handling, performance, test coverage, nailing down invariants/validation/parsing, etc, are also the people pushing for those nebulous perfections like "cleaner" code. Getting all those things right requires the code to be pretty darn clean.
To be cynical and uncharitable, in my experience non-engineering leadership tends to be receptive to the idea that engineers are by their nature wasteful and self indulgent, and saying “just don’t do that stuff for it’s own sake” reinforces said leadership’s prejudices and will ingratiate you with them. I’ve most often heard such arguments from people shitting on me for advocating for tests.
But the bulk of my experience is with small startups where the stakes are high; tensions around productivity are natural, and working through them is essential.
Personally, the "Rule of Three of Software Engineering" has been a good enough practice for most cases, as usual with any rule of thumb there are exceptions but most of the time I can apply it.
I've been using it for many, many years and it has saved me a countless hours by postponing abstractions, modularisation, etc. to the point where it actually emerges as a pattern in the software I'm working with. Let the code repeat itself, copy and paste, and only after some pattern repeat itself for the 3rd time I start to think on how to abstract, or modularise it.
It's always so much easier to rework repeated code/patterns into abstractions than fixing misguided abstractions done too early.
if we're being frank: When you care about the company and feel the company cares about the tech. Both of those aligning are rare. Broken windows and all that.
Now for a proper engineering answer, there's a few (but not limited to) factors to consider when determining software rigidity:
- Halo effect: How much code does this module affect? The more things that can break when the module fails, the more need to get proper testing/architecture.
- Frequency (in both ways): How often are you changing the code (is it cutting edge, or bog standard 50+ year old algorithms?) as well as how often the application calls the code. The more times its called or changed, the more you may appreciate ways to test new implementations with minimal impact to the current iteration.
- Understanding: pretty straightforward. The less you or the team understands the code, the more need to validate that code through tests. This often falls into frequency, because inevitable the less you understand the more you will need to tinker, possibly for unknown unknowns.
It's still subjective at the end of the day, but there are metrics you can use to make your case.
Given the choice between fixing a quality issue that can be easily measured/detected and one that cannot, a lot of people will prefer the measurable, easy-to-detect one.
So the folks on the 'code quality' committee end up introducing tools that make it impossible to merge if your markdown file has two consecutive blank lines - rather than spending the time on performance or security which are much harder to keep on top of with automated tooling.
IMHO article defines perfectionism doing both things you have mentioned too early. E.g. you do prototype and instead of showing that to stakeholders you clean it up, cover with tests and etc.
Jordan seemed to be talking about it: prioritizing; helping, rather than burdening others. Gregor seemed to be describing a lack of diligence: not fleshing out learning, fretting over less relevant details.
In my mind arguing for dilegence is a better here. It implies that the product matters, even if it is imperfect. Arguing against perfectionism is bad. To some it will imply that the product does not matter, that sloppy work is okay if you can somehow justify it (getting the job done, doing more, etc.).
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.
Exactly! And it's important to remember that while the outage did economic damages north of $5 billion, that this is not a cost to Crowdstrike, but to their customers. So the take away is ship fast because the costs of shitty code will be felt mostly by people who are not you!
Sarcasm aside, you're not wrong about people being caught up in perfectionism but that doesn't make you right about people/managers conflating perfectionism with goodenoughism. I'm sure with this error (and many others) you can find someone who was trying to solve the problem/s and someone else that accused them of perfectionism. I rarely see actual perfectionism, but I do frequently see people disagreeing what is good enough. I also frequently see problems that would have been small at the time but to fix later on require massive expenditures. The problem is that not-good-enough compounds while good-enough is neutral. You need to also dedicate time to maintenance and repair, because that's what fixes not-good-enough, which frequently happens simply because we aren't omniscient.
while the outage did economic damages north of $5 billion
If you're going to measure the dollar value cost of their errors as a cost of CrowdStrike being in business, shouldn't you balance that against the dollar value of savings from the attacks they've stopped?
Not exactly, but close. You need to balance against the dollar value of savings from attacks they've stopped BUT that their competitors would not have.
Just comparing against the attacks they stopped is a naive and gross overestimation because it requires an assumption that if a customer did not use CrowdStrike they did not use _any_ alternative. In reality, Crowdstrikes customers would have used some other product. So the attacks that competitors could have also defended against cannot be accurately attributed to Crowdstrike. i.e. if Edison didn't invent the light bulb someone else would have. We know this because he didn't invent it, though he did make the first practical version[0].
But since we're on topic, I'd call what I suggested a "good enough" estimation. We have a reasonable estimate under reasonable constraints. It's more complex, but the amount of accuracy gained is tremendous. Arguably the other model is so inaccurate it is less than meaningless (it isn't even "back of the envelope") because its conclusions would lead us to believe things that are not true, and far from the truth. But if we want to talk about _actual perfectionism_, well this gets much more complicated much more quickly. In fact, gets exponentially complex in exponential time.
A true analysis needs to consider the counterfactual question of what if Crowdstrike did not exist at all. This is far more complicated and contains many subltities that could dramatically change the results. Because we need to understand things like how other companies would have advanced and developer were the money/manpower/resources that were allocated to CrowdStrike were allocated to others. To understand how CrowdStrike both creates and discourages competition in the space. Systems like these are (mathematically) chaotic. Who knows, maybe a manager at Crowdstrike pissed off an employee who then turned blackhat. But maybe Crowdstrike gave a job to someone who would have turned black hat would they not have gotten hired. Maybe because they were laid off from a competitor! Realistically performing these calculations to a solution that is accurate (which would still be probabilistic in nature) is intractable. Of course we can improve our earlier model by using some of these factors, but I want to illustrate that there's a difference in perfectionism which is unachievable from being reasonably accurate ("good enough").
[0] Left unknown is how quickly someone else would have come to similar practicality but my best understanding of this specific story is that it would not have been long. This is not an uncommon story in science and technology and if you look hard enough you'll almost always find that any discovery or invention was also being pursued by another group. There are exceptions, but they are rare. You just never hear about the other groups, but you can confirm this by watching advancements that happen while we're alive and can see the competition in real time. Specifically in domains where you are close to.
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.
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.
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.
I think you have hit the nail on the head, focusing on the wrong things.
The problem is that software engineering is still, in many ways, in a pre-scientific era [1]. For example, civil engineers know how to build bridges that are good enough, i.e. that barely stand.
In the software field, we don't really know how to proceed in the same way. We have formal methods, but they are quite costly, and therefore not used very often.
> For example, civil engineers know how to build bridges that are good enough, i.e. that barely stand.
And "good enough" is a relative and changing thing. What was "good enough" thousands of years ago is nowhere near standards today. This is even true a hundred or 50 years ago with the specific example of bridges. Engineers learn this the hard way because the results are visibly catastrophic and usually through the loss of many lives. But I think one of the difficulties of software is that failures are often less apparent and can be difficult to accurately attribute. But then again, when a bridge fails there are both internal and independent investigations that are extremely thorough and result in updated policies. This does not seem to be the same in software (at least to nearly the same degree), in part due to the abstracted nature of how software can cause harm. It is actually harder to attribute error (like you said, formal methods exist, but are costly and not just in the monetary sense).
> 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).
I think there is an irony in this because often someone managing a group will accuse them of perfectionism when they themselves do not have the appropriate context to understand that the arguments are really about goodenoughism. I do think this is why companies that are fairly transparent to their employees have been successful. Because it helps them understand the balance and constraints of which they are operating under. To have an environment which is closed and groups are unable to communicate (e.g. in a highly classified setting[0]), the person managing the groups needs to have intimate knowledge of all the pieces coming together, because somewhere along the line someone needs to glue all the puzzle pieces together.
So I wouldn't call what you express perfectionism. Perfectionism doesn't really exist because perfection doesn't exist. Rather it sounds like you are detail minded. It also sounds like you've learned to understand what details can (or have to) be ignored, what details can be temporarily ignored but need to be revisited, and to understand that keeping track of details is still important to understand how one needs to improve and mitigate future catastrophes. Obviously there is a balance, but I think this is very different from someone who is trying to turn a map into the territory.
[0] I should mention in many classified settings people are still encouraged to communicate and bounce ideas off of one another. Just to do so exclusively in secure areas and to ensure the other person also has the requisite clearance.
To be clear, I literally experience the clinical definition of perfectionism, at a level that is arguably disordered [0]:
> the tendency to demand of others or of oneself an extremely high or even flawless level of performance, in excess of what is required by the situation. It is associated with depression, anxiety, eating disorders, and other mental health problems.
At my worst, every single mistake I made would give me hours to days of stress and anxiety. I've gotten it much better under control in general, but it still does cause a lot of stress from time to time.
This is why I object to people equating "perfectionism" with "being bad at prioritizing truly important work". I'm pretty darn good at prioritizing what's important. I actually perceive wasting time on unimportant work as a mistake, the opposite of perfection, and if I do it and realize my mistake I get stressed about it.
Perfectionism is holding yourself (and/or others) to excessively high standards, often met by anxiety or depression when those standards aren't met. The amount of perfectionism someone has is completely orthogonal to the question of how you measure perfection—a perfectionist with a definition of perfection that is well aligned with reality may accomplish a lot while a perfectionist with a definition that's less well aligned ends up wasting a lot of time.
And while you're right that perfect doesn't exist, that doesn't stop a perfectionist from pursuing it.
> To be clear, I literally experience the clinical definition of perfectionism
To be clear, I was trying to make the point that this is ill-defined due to what is a reasonable level of acceptance is difficult to define and how the common usage of the terminology can be ill suited due to this being dependent on understanding what one is conditioning on. I'm not saying you don't place too strong conditions, I don't know you. Despite running into you here often, I don't know that side of you and it isn't something I can reasonably conclude in either way. But I do know it is common that too lax of conditions are placed. It's a spectrum after all and either end is bad.
> every single mistake I made would give me hours to days of stress and anxiety.
I can definitely empathize with this and have been there.
I think you and I are decently aligned in our belief. Maybe we're bad at explaining and/or bad at interpreting. But there are enough similarities that I think we should not discount. But I do think we were using the word perfectionism in different ways. I was trying to use the version we'd see in normal language and how it is used in the article to agree with you in that this actually isn't perfectionism (certainly not the clinical definition). Though you're right to also point out that the clinical definition of perfectionism is not about actual perfection. But I don't think this invalidates my point that the true difficulty is in determining what is appropriate levels of standards, that this is a difficult balance to strike, and that many conflate comments of details/nuance with excessive standards when they may or may not be, including that the recognition of details is important in determining this. And I do think there is a natural bias in that it is easier to identify excessive standards than it is to identify insufficient ones.
> In other words, it's not perfectionism that's the productivity killer they've identified, it's inexperience.
experience without growth is just inexperience with more "years of experience".
This is pretty much what happens in more technical parts of industry when you have your best workers jumping every year, poor documentation of proprietary tech, and a lack of proper training because you expect "experienced" developers to simply grasp your entire tech stack from day one. You have people falling into the same pitfalls every year (or few months even) and building on a foundation that is not fully understood. Because there is no time to properly understand.
Maybe there should be some "perfectionism". Maybe not in shipping "things that actually matter" (as business defines it), but in the boring stuff that keeps a ship afloat. They could also simply give raises to their best workers instead of having them walk, but clearly that's not in the cards.
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.
I think optimal level of perfectionism depends on impact of the decision and how hard it will be to change in the future. I think it's worth to be perfectionist when it comes to architecture, which is hard to change. So you want to make sure you do things right (or extensibly), and consistently. However, in minor things like method names or code structure, it's OK not to be consistent.
I would also say being able to identify where you should be consistent can be itself a huge productivity enabler.
It's complicated. It can become an excuse too: "if only they (waves in the general direction of customer relations) could give us good requirements". Some stuff is just difficult to figure out.
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.
Back of the napkin graphs that are not based on any collected data have grown to aggravate me. Although it shows the mental model of the author, it adds an air of empiricism that gives it more authority.
In this case, how do we know it is an exponential chart at all or there is not discontinuous jumps in value at “perfect”?
For starters, the graph would have been easier to intuit if time had been on the usual horizontal axis. That would better illustrate the “point of diminishing returns”, which is the theme they’re trying to explore. By presenting it in this confusing configuration it seems more profound than it is.
Yes, I interpreted it as a sum of total value over lifetime; but when you are building it, the software could live for 1 year or 20, in very unpredictable ways.
Yeah, no. Most software is cludged together with little design and grows organically. Overall, putting on the time to do it right -- if possible -- parts give dividends.
Software done right from 30+ years ago is still in broad use. There is huge value in that
Doing things right involves prototypes, iterations, and experiments, so high velocity is good. However, if a prototype ships, you often get on trouble.
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.
"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.
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.
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.
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…
138 comments
[ 2.0 ms ] story [ 194 ms ] threadI think we see the results of rushing in all the software around us much more than we see the delays of perfectionism.
Thankfully the market correction made this much less of an issue.
I'll take a 95% solution delivered in 2 weeks over a 99% one delivered in 2 months.
This depends a lot on the context. If I deliver the 95% in 2 weeks can I ship an update in 2 months that delivers the 99%, or are we stuck forever at 95% (due to technical limitations or business reality)?
If I'll be able to deliver the 99% soon, then sure, let's ship the 95% sooner rather than later.
But if for whatever reason I realistically cannot do that, then you have to consider the context. What is left out in the 95%? How soon will it be a problem that we're missing that remaining 4%? Who will notice the missing pieces? Will they be able to work around their absence?
Many times you may still come to the conclusion that the 95% is the right move, but sometimes it's better to not offer the two-week plan as an option if the fallout from that missing 4% is going to be high.
E.g., the Twitch codebase
They can't change it or add new features or fix problems because it's too much of an unholy startup crack-fueled mess.
Not even companies who stole the leaked codebase can improve the horrible user experience on their Twitch clones whatsoever.
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!"
Maybe it's the pessimism of age, but it feels like that describes all biology, economies, politics, etc...
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.
The "we'll fix it later" turning into "no one ever fixed it" is way too common of a pitfall.
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.
Give the engineers clear requirements and let them interact with the stakeholders. Get rid of the intermediaries and knowledge brokers.
Maybe I've just had good luck with product managers, but I tend to enjoy my work the most when someone else is filtering the stakeholders' long and constantly changing wishlist for me and turning it into something coherent and actionable.
Now there are these Product Managers who have absolutely no clue how software is built.
Interestingly I'm seeing similar trend in many other fields; my car goes to servicing and there's some dude who just knows jargons interfacing with me, for the minutest of my questions he will "get back to me after consulting the line workers", same with my house construction. I had to get through 4 layers of people to finally get to the person who is actually doing the electrical wiring to clearly explain what is it that I wanted.
That's because he's not there to explain what they are doing. He likely doesn't know a spark plug from a fuel injector. He's there to sell you more services.
There are several reasons why this is not a good idea. And those reasons show itself usually quickly once that is tried.
And most people are wrong about which group they're in.
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.
Other engineering professions do have precedent shown for this.
I'm not convinced that either certification itself or the market represent the most effective means to achieving societal good. I think what history shows is that real consequences for shoddy work are required [1]. To date, software makers haven't really been held liable for consequences, but I expect that will change if we don't clean up our act.
[0] https://blog.codinghorror.com/do-certifications-matter/
[1] "229 If a builder builds a house for someone, and does not construct it properly, and the house which he built falls in and kills its owner, then that builder shall be put to death."
- Hammurabi's Code, ~1750 BC
Allowing individual engineers to be de-licensed creates a culture adherence to norms is the priority. If you ever worked with a civil engineering organization… it’s not exactly a hotbed of innovation. Alot of the professional associations spend more time creating make-work regulations than actual safety or engineering. For example, in New York, something as trivial as refurbishing a moderate volume street crossing in an urban area requires $750k-$1M of services to address ADA compliance, multi-modal transit accommodation and other factors.
Crowdstrike had a sloppy process without meaningful testing, only parser validation. Assigning that task to tens of thousands of admins, most of whom have no idea what they are doing just shifts blame, not accountability.
There’s an epidemic of “minimum viable” when it comes to software, and that results in flying really close to “not viable”.
And what do they all say? “We should have launched sooner.”
That’s what happens when the goal of the vast majority of startups is not to build an actual business. Their goal is to “get funded”. It just feels rotten.
Perfectionism is a disease
That results in other shipping sub optimal stuff
It’s perfectly ok to ship 50% of the features 100% well and keep shipping
I got you! It’s relatively new, published four days ago. The relevant section is called “what went wrong and why”:
https://www.crowdstrike.com/falcon-content-update-remediatio...
It’s a hard problem - the whole point of Crowdstrike is to quickly respond to threats. (And they are very good at it) So you want time to market for marginal changes to be very fast. Normally I’d give them the benefit of the doubt, but their arrogance and poor response triggers my spidey-sense.
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've seen first hand how someone writing a 500 line function struggles to test it. But splitting it up into more manageable chunks of functionality makes it easier to write a test.
Imo perfectionism is chasing that last 5% performance.
Clean code, design patterns etc are just good engineering practices... Not perfectionism ....
The reason I wrote the above comment is because I've seen this being flipped on its head too often by myself and others.
This is what I don’t like about software engineering. The dogmatism. The absolutism. The more I work in the field, the less I talk about “clean code”, “ddd”, “good practices”. I find myself saying more and more “it depends”, and more often than not what the business requires is not 5 layers of code in which the concerns are separated among dozens of files and following good design patterns, but a damn single file that get things done.
There’s place for what you call good practices and clean code, but many times those things don’t lead to good products.
Every single startup I’ve worked for has eventually come to terms with needing some best practices. In my view, there actually is a baseline: CI, partial coverage unit tests for the most easily testable code, and modularization/loose-coupling so that unwinding tech debt has linear rather than exponential cost. But even that is driven by my opinions about ROI, not theory in isolation.
Clean code for a bad product won't turn it into a good product. That's the core issue. These are engineering principles but you are looking at them through business logic.
The best metphor here is to compare clean code to insurance. You don't want to insure this? Okay, you can take that risk and maybe save if nothing happens. But if/when something happens it'll be more expensive than if you paid the insurance up front.
Meanwhile, Clean code from a good product will make it resiliant to becoming a bad product. I'm sure if you played any modern video games that you've had at least a few games that you loved but had horrible technical hiccups. Unoptimized, untested logic, crashing. The issue is some of these games still sell, so maybe the business logic prevailed over properly engineered code. But they are entertainment at the end of the day, not Crowdstrike.
Just don't do them for their own sake.
But the bulk of my experience is with small startups where the stakes are high; tensions around productivity are natural, and working through them is essential.
I've been using it for many, many years and it has saved me a countless hours by postponing abstractions, modularisation, etc. to the point where it actually emerges as a pattern in the software I'm working with. Let the code repeat itself, copy and paste, and only after some pattern repeat itself for the 3rd time I start to think on how to abstract, or modularise it.
It's always so much easier to rework repeated code/patterns into abstractions than fixing misguided abstractions done too early.
Now for a proper engineering answer, there's a few (but not limited to) factors to consider when determining software rigidity:
- Halo effect: How much code does this module affect? The more things that can break when the module fails, the more need to get proper testing/architecture.
- Frequency (in both ways): How often are you changing the code (is it cutting edge, or bog standard 50+ year old algorithms?) as well as how often the application calls the code. The more times its called or changed, the more you may appreciate ways to test new implementations with minimal impact to the current iteration.
- Understanding: pretty straightforward. The less you or the team understands the code, the more need to validate that code through tests. This often falls into frequency, because inevitable the less you understand the more you will need to tinker, possibly for unknown unknowns.
It's still subjective at the end of the day, but there are metrics you can use to make your case.
Given the choice between fixing a quality issue that can be easily measured/detected and one that cannot, a lot of people will prefer the measurable, easy-to-detect one.
So the folks on the 'code quality' committee end up introducing tools that make it impossible to merge if your markdown file has two consecutive blank lines - rather than spending the time on performance or security which are much harder to keep on top of with automated tooling.
sigh
Jordan seemed to be talking about it: prioritizing; helping, rather than burdening others. Gregor seemed to be describing a lack of diligence: not fleshing out learning, fretting over less relevant details.
In my mind arguing for dilegence is a better here. It implies that the product matters, even if it is imperfect. Arguing against perfectionism is bad. To some it will imply that the product does not matter, that sloppy work is okay if you can somehow justify it (getting the job done, doing more, etc.).
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.
It wouldn’t have existed lol
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.
Sarcasm aside, you're not wrong about people being caught up in perfectionism but that doesn't make you right about people/managers conflating perfectionism with goodenoughism. I'm sure with this error (and many others) you can find someone who was trying to solve the problem/s and someone else that accused them of perfectionism. I rarely see actual perfectionism, but I do frequently see people disagreeing what is good enough. I also frequently see problems that would have been small at the time but to fix later on require massive expenditures. The problem is that not-good-enough compounds while good-enough is neutral. You need to also dedicate time to maintenance and repair, because that's what fixes not-good-enough, which frequently happens simply because we aren't omniscient.
If you're going to measure the dollar value cost of their errors as a cost of CrowdStrike being in business, shouldn't you balance that against the dollar value of savings from the attacks they've stopped?
Just comparing against the attacks they stopped is a naive and gross overestimation because it requires an assumption that if a customer did not use CrowdStrike they did not use _any_ alternative. In reality, Crowdstrikes customers would have used some other product. So the attacks that competitors could have also defended against cannot be accurately attributed to Crowdstrike. i.e. if Edison didn't invent the light bulb someone else would have. We know this because he didn't invent it, though he did make the first practical version[0].
But since we're on topic, I'd call what I suggested a "good enough" estimation. We have a reasonable estimate under reasonable constraints. It's more complex, but the amount of accuracy gained is tremendous. Arguably the other model is so inaccurate it is less than meaningless (it isn't even "back of the envelope") because its conclusions would lead us to believe things that are not true, and far from the truth. But if we want to talk about _actual perfectionism_, well this gets much more complicated much more quickly. In fact, gets exponentially complex in exponential time.
A true analysis needs to consider the counterfactual question of what if Crowdstrike did not exist at all. This is far more complicated and contains many subltities that could dramatically change the results. Because we need to understand things like how other companies would have advanced and developer were the money/manpower/resources that were allocated to CrowdStrike were allocated to others. To understand how CrowdStrike both creates and discourages competition in the space. Systems like these are (mathematically) chaotic. Who knows, maybe a manager at Crowdstrike pissed off an employee who then turned blackhat. But maybe Crowdstrike gave a job to someone who would have turned black hat would they not have gotten hired. Maybe because they were laid off from a competitor! Realistically performing these calculations to a solution that is accurate (which would still be probabilistic in nature) is intractable. Of course we can improve our earlier model by using some of these factors, but I want to illustrate that there's a difference in perfectionism which is unachievable from being reasonably accurate ("good enough").
[0] Left unknown is how quickly someone else would have come to similar practicality but my best understanding of this specific story is that it would not have been long. This is not an uncommon story in science and technology and if you look hard enough you'll almost always find that any discovery or invention was also being pursued by another group. There are exceptions, but they are rare. You just never hear about the other groups, but you can confirm this by watching advancements that happen while we're alive and can see the competition in real time. Specifically in domains where you are close to.
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.
The problem is that software engineering is still, in many ways, in a pre-scientific era [1]. For example, civil engineers know how to build bridges that are good enough, i.e. that barely stand.
In the software field, we don't really know how to proceed in the same way. We have formal methods, but they are quite costly, and therefore not used very often.
[1] https://www.di.uminho.pt/~jno/ps/pdbc.pdf
And "good enough" is a relative and changing thing. What was "good enough" thousands of years ago is nowhere near standards today. This is even true a hundred or 50 years ago with the specific example of bridges. Engineers learn this the hard way because the results are visibly catastrophic and usually through the loss of many lives. But I think one of the difficulties of software is that failures are often less apparent and can be difficult to accurately attribute. But then again, when a bridge fails there are both internal and independent investigations that are extremely thorough and result in updated policies. This does not seem to be the same in software (at least to nearly the same degree), in part due to the abstracted nature of how software can cause harm. It is actually harder to attribute error (like you said, formal methods exist, but are costly and not just in the monetary sense).
I think there is an irony in this because often someone managing a group will accuse them of perfectionism when they themselves do not have the appropriate context to understand that the arguments are really about goodenoughism. I do think this is why companies that are fairly transparent to their employees have been successful. Because it helps them understand the balance and constraints of which they are operating under. To have an environment which is closed and groups are unable to communicate (e.g. in a highly classified setting[0]), the person managing the groups needs to have intimate knowledge of all the pieces coming together, because somewhere along the line someone needs to glue all the puzzle pieces together.
So I wouldn't call what you express perfectionism. Perfectionism doesn't really exist because perfection doesn't exist. Rather it sounds like you are detail minded. It also sounds like you've learned to understand what details can (or have to) be ignored, what details can be temporarily ignored but need to be revisited, and to understand that keeping track of details is still important to understand how one needs to improve and mitigate future catastrophes. Obviously there is a balance, but I think this is very different from someone who is trying to turn a map into the territory.
[0] I should mention in many classified settings people are still encouraged to communicate and bounce ideas off of one another. Just to do so exclusively in secure areas and to ensure the other person also has the requisite clearance.
> the tendency to demand of others or of oneself an extremely high or even flawless level of performance, in excess of what is required by the situation. It is associated with depression, anxiety, eating disorders, and other mental health problems.
At my worst, every single mistake I made would give me hours to days of stress and anxiety. I've gotten it much better under control in general, but it still does cause a lot of stress from time to time.
This is why I object to people equating "perfectionism" with "being bad at prioritizing truly important work". I'm pretty darn good at prioritizing what's important. I actually perceive wasting time on unimportant work as a mistake, the opposite of perfection, and if I do it and realize my mistake I get stressed about it.
Perfectionism is holding yourself (and/or others) to excessively high standards, often met by anxiety or depression when those standards aren't met. The amount of perfectionism someone has is completely orthogonal to the question of how you measure perfection—a perfectionist with a definition of perfection that is well aligned with reality may accomplish a lot while a perfectionist with a definition that's less well aligned ends up wasting a lot of time.
And while you're right that perfect doesn't exist, that doesn't stop a perfectionist from pursuing it.
[0] https://dictionary.apa.org/perfectionism
To be clear, I was trying to make the point that this is ill-defined due to what is a reasonable level of acceptance is difficult to define and how the common usage of the terminology can be ill suited due to this being dependent on understanding what one is conditioning on. I'm not saying you don't place too strong conditions, I don't know you. Despite running into you here often, I don't know that side of you and it isn't something I can reasonably conclude in either way. But I do know it is common that too lax of conditions are placed. It's a spectrum after all and either end is bad.
> every single mistake I made would give me hours to days of stress and anxiety.
I can definitely empathize with this and have been there.
I think you and I are decently aligned in our belief. Maybe we're bad at explaining and/or bad at interpreting. But there are enough similarities that I think we should not discount. But I do think we were using the word perfectionism in different ways. I was trying to use the version we'd see in normal language and how it is used in the article to agree with you in that this actually isn't perfectionism (certainly not the clinical definition). Though you're right to also point out that the clinical definition of perfectionism is not about actual perfection. But I don't think this invalidates my point that the true difficulty is in determining what is appropriate levels of standards, that this is a difficult balance to strike, and that many conflate comments of details/nuance with excessive standards when they may or may not be, including that the recognition of details is important in determining this. And I do think there is a natural bias in that it is easier to identify excessive standards than it is to identify insufficient ones.
experience without growth is just inexperience with more "years of experience".
This is pretty much what happens in more technical parts of industry when you have your best workers jumping every year, poor documentation of proprietary tech, and a lack of proper training because you expect "experienced" developers to simply grasp your entire tech stack from day one. You have people falling into the same pitfalls every year (or few months even) and building on a foundation that is not fully understood. Because there is no time to properly understand.
Maybe there should be some "perfectionism". Maybe not in shipping "things that actually matter" (as business defines it), but in the boring stuff that keeps a ship afloat. They could also simply give raises to their best workers instead of having them walk, but clearly that's not in the cards.
1. Crowdstrike 2. Microsoft 3. The companies that think it’s a good idea to run what is essentially an enterprise rootkit
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.
this was not the failure of a single company.
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.
I would also say being able to identify where you should be consistent can be itself a huge productivity enabler.
Now that the prevailing school of thought is that shipping crap is OK we have a checks notes Boeing Starliner.
In this case, how do we know it is an exponential chart at all or there is not discontinuous jumps in value at “perfect”?
Software done right from 30+ years ago is still in broad use. There is huge value in that
Doing things right involves prototypes, iterations, and experiments, so high velocity is good. However, if a prototype ships, you often get on trouble.
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.
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.
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…