9 ms·

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 proje

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.

actionfromafar 2y ago
When you are the one calling the shots yourself, it can be easy to procrastinate by way of polishing. (Depending on the kind of temperament you have.)
rafaelmn 2y ago
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.
TylerE 2y ago
Yes, but what if you'd just...finished and started working on something else? I'll take a 95% solution delivered in 2 weeks over a 99% one delivered in 2 months.
- lolinder 2y ago
  > 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.
  - rectang 2y ago
    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.
  - shrimp_emoji 2y ago
    > are we stuck forever at 95% (due to technical limitations or business reality)? 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.
ryandrake 2y ago
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!"
- Terr_ 2y ago
  > The big open secret of the software industry is how barely everything works. Maybe it's the pessimism of age, but it feels like that describes all biology, economies, politics, etc...
arp242 2y ago
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.

actionfromafar 2y ago

When you are the one calling the shots yourself, it can be easy to procrastinate by way of polishing. (Depending on the kind of temperament you have.)

rafaelmn 2y ago

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.

TylerE 2y ago

Yes, but what if you'd just...finished and started working on something else? I'll take a 95% solution delivered in 2 weeks over a 99% one delivered in 2 months.

lolinder 2y ago
> 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.
- rectang 2y ago
  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.
- shrimp_emoji 2y ago
  > are we stuck forever at 95% (due to technical limitations or business reality)? 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.

ryandrake 2y ago

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!"

Terr_ 2y ago
> The big open secret of the software industry is how barely everything works. Maybe it's the pessimism of age, but it feels like that describes all biology, economies, politics, etc...

arp242 2y ago

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.