Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Perfection is not over-engineering

var0.xyz

Post reply on HN
Print view View original

121–130 of 132 posts

Re: Perfection is not over-engineering

#121

Post by ChrisMarshallNY »

bch wrote: post #100
ChrisMarshallNY wrote: post #97

Earlier quoted context omitted.

I always thought of that as “yak-shaving,” or “bikeshedding.” Quality takes longer. Sometimes, significantly longer, for many reasons. That’s why something top-shelf, costs so much more than commodity, when it doesn’t seem to have much more, in the way of features. Many orgs aren’t interested in spending that much extra time on it (which is their prerogative). The customer base tends to be smaller, and a lot more fic…

I love the social/cultural aspects of our engineering discipline. > I always thought of that as “yak-shaving,” or “bikeshedding.” I think of yak-shaving as ending up (by lack of discipline, or perhaps out of necessity) working on some supporting aspect of a supporting aspect of a supporting aspect... in service of the original task. So, a potential time suck, for sure, but "perfection is the enemy of completion" does…

Sorry if your reply got dinged (looks all right to me, now). It was spot-on.

I think of "Yak-Shaving" as working on peripheral aspects of the project, to the detriment of the main path. Easy to justify, as they are "working on the project," but maybe not helping to significantly advance it.

I think of "Bikeshedding" as working on another aspect of the project (or a completely different project), because we want to (often, because it is more approachable or pleasant). This often becomes a problem, when the project is getting near shipping, as there's a ton of really boring stuff that needs to be done.

"Perfecting," on the other hand, can look like either of the above, but is, indeed, working on the main path, and advancing the project; just maybe not quickly.

Re: Perfection is not over-engineering

#122

Post by zephen »

xnx wrote: post #24
var0xyz wrote: post #9

Earlier quoted context omitted.

> but the team was spending time building an absurd Rube-Goldberg contraption of microservices This is literally the example that I use, the most common case of over-engineering, having more microservices than team members. Microservices are the right solution for certain problems, but those were not problems they had. Some anecdotal evidence. I worked in many of these places, and the most common tell of over-enginee…

> more microservices than team members Or more microservices than customers

You need to be careful with this one, or reductio ad absurdum might lead you to not build microservices, or even a monolithic app, before you have acquired your first customer.

Re: Perfection is not over-engineering

#123

Post by xnx »

zephen wrote: post #122
xnx wrote: post #24

Earlier quoted context omitted.

> more microservices than team members Or more microservices than customers

You need to be careful with this one, or reductio ad absurdum might lead you to not build microservices, or even a monolithic app, before you have acquired your first customer.

True, but also "Do Things that Don't Scale" (https://www.paulgraham.com/ds.html). There are many examples of successful companies that had customers before they had products.

Re: Perfection is not over-engineering

#124

Post by Daishiman »

axus wrote: post #52
__MatrixMan__ wrote: post #5

I'm all for pushing back against "let's not make perfect the enemy of good." I hear that all the time in reference to software that is usually quite bad, and often a little evil to boot--nothing good anywhere in sight except some poor schmuck trying to find a way to make their job something worth taking pride in. I'm not sure I agree that systems are products though. The product mindset is toxic. It means that you've…

Let's not make fixing bugs and backwards compatibility the enemy of shoveling out more features

You're saying it in jest but this is closer to the right answer. Features make you money. A large enough project has an infinite backlog. You will be unlikely to make much money from clearing out your backlog.

Re: Perfection is not over-engineering

#125

Post by FromTheFirstIn »

> I believe a perfect solution exists. With one big caveat: you need a very clear set of requirements. Every constraint on the table. Tighten those enough and something interesting happens, you end up with only one possible solution.

This is the kind of naive thinking people are actually pushing back on when they’re telling you not to build perfect products. One of the constraints that the author refuses to acknowledge is the social constraint of leading people to a shared goal- if people keep telling you your perfect solution isn’t viable and they do not want to do it, then it’s not perfect, is it?

In general, any approach that believes there’s a One True Answer is either looking at trivial problems or naive egocentrism, in my experience.

Re: Perfection is not over-engineering

#126

Post by [deleted] »

close04 wrote: post #56
axus wrote: post #52

Earlier quoted context omitted.

Let's not make fixing bugs and backwards compatibility the enemy of shoveling out more features

The expression is “the enemy of good ” not “the enemy if something” so in the end it’s about defining “good”. It varies with context. What’s good, move fast and break things or go slow and considerate? Is risking bugs worth it to launch a feature? How important is that feature? How important is it to have it now vs. later? And how do you reconcile it when what’s good for you is bad for me?

[deleted]

Re: Perfection is not over-engineering

#127

Post by BloodyIron »

__MatrixMan__ wrote: post #96
BloodyIron wrote: post #95

Earlier quoted context omitted.

So is a screwdriver a tool or a product? I think you're getting caught up on nomenclature and limited sample sizes.

What it is to you depends on if you want to sell a screwdriver or if you want to drive a screw. If you're looking for somebody to design a screwdriver for you, you're better off with the guy who wants to drive a screw.

Well I sell various IT systems as products. For example, turnkey TrueNAS systems that were built on refurbished hardware that I/my business personally validated for reliability, and various other metrics. We don't make the hardware, nor the software, but we combine them, validate it does what is expected, and from my perspective that's fair to consider it a "product". How does that line up for you?

Re: Perfection is not over-engineering

#128

Post by pdimitar »

KaiserPro wrote: post #109
__MatrixMan__ wrote: post #5

I'm all for pushing back against "let's not make perfect the enemy of good." I hear that all the time in reference to software that is usually quite bad, and often a little evil to boot--nothing good anywhere in sight except some poor schmuck trying to find a way to make their job something worth taking pride in. I'm not sure I agree that systems are products though. The product mindset is toxic. It means that you've…

Its about pragmatism. The problem is that a lot of software engineering tends to be not about building a product to service the buisness need. Lets be honest, a lot of the time engineering decisions are made because "it would be cool to use x" rather than "this is the fastest path to achieving business goal z" "over engineering" in a lot of cases is just either engineering gate keeping "oh you don't know how to do x…

Popular view to dunk on meaningless perfectionists, sure, but your comment conveniently does not address "let's have this architecture because we know these new requirements are coming and we know we can't accommodate them with the current one".

Arguing extremes is easy.

Re: Perfection is not over-engineering

#129

Post by pdimitar »

Daishiman wrote: post #124
axus wrote: post #52

Earlier quoted context omitted.

Let's not make fixing bugs and backwards compatibility the enemy of shoveling out more features

You're saying it in jest but this is closer to the right answer. Features make you money. A large enough project has an infinite backlog. You will be unlikely to make much money from clearing out your backlog.

As a guy who was a part of projects with an infinitely growing backlog (multiple times), I can tell you for certain that _not_ periodically addressing parts of your backlog absolutely will stop you from making more money; even lose you some due to customer churn.

Re: Perfection is not over-engineering

#130

Post by caarmen »

> A team of three people maintains five microservices.

How about a team of 2 people maintaining 15+ microservices? :/

Add to this: at any given time, we have several features at different phases, so some microservices have multiple open PRs. And some features impact multiple microservices.

When we release a feature, we deploy all impacted microservices at the same time.

Post reply on HN