Software engineering fetishes

There are a few concepts/principles in software engineering that are over-emphasised and prioritised without enough actual thinking.

• Time to first byte
• DRY
• A really amazing to read commit history

Teams will introduce elaborate software development process, stop all conversations & thinking, bring weird and wonderful tech choices all to accommodate these things.

They do have some value but people love to obsess over them without ever thinking about the costs.

Time to first byte

This is very important, we want our websites to respond quickly when our user first reaches them.

What happens

• Build an SPA with a framework released last month so that we can continue to shovel 12mb of useless resources at a user.
• Website still performs terribly but at least something appears quickly!
• Endless rewrites, messing around with build/packaging tools
• Website doesn't work without Javascript.

What you should do

The performance of your website is more complicated than just one metric and by over-emphasising time to first byte you could be harming everything else.

Think about:

• Total number of requests
• Size of resources
• CPU impact of executing JS
• How cacheable it is

DRY

DRY (don't repeat yourself) is when you take some repeated code and refactor it into a function/class/interface/whatever so it can be re-used elsewhere.

Repeating code is annoying and can be wasteful. If you want to fix a bug and you have repeated code that would be sad.

What happens

• Weird Frankenstein functions/classes with optional arguments or boolean flags passed in to concepts that are loosely related, but are not really.
• INTENSE COUPLING

What you should do

• If a concept is shared by more than 2 things, you can probably safely refactor. Just hold off. Someone clever said bad abstractions are worse than none. Wait until it is clear that there is something really there to DRY up.
• If you end up adding flags to functions to make them behave differently, that is a red-flag.
• When making a simple change, do lots of tests fail? Lots of compilation problems? That's usually an indicator of tight-couping and that is often born from engineers worrying too much about making DRY code.
• Acknowledge that making re-usable code is difficult and risky. Multiply this by 10 for re-usable services.

A really amazing to read commit history

We want it so that people can look at a git history to have an idea of the motivations behind the changes in a project.

We will typically not accept changes directly into master but instead insist on carefully crafted pull requests that get evaluated before being merged.

What happens

• Actually shipping software becomes an insane discussion full of bike-shedding. Pull requests lasting days, weeks for the most trivial of changes that should've been released yesterday.
• Job ads still hilariously saying that they practice continuous integration, meanwhile the devs have a tremendous time dealing with merge conflicts or just flat-out scared to change the code because of competing pull requests.
• Still no one has any actual hope of understanding the code base just from looking at the git history, because of course you cant. You understand a code base by reading it and changing it.

What you should do

• Good, descriptive tests.
• Pair programming.
• Try out ADRs.
• Actually talk to each other, build a team.

There are caveats to this. For a distributed team pull requests make sense as they aid conversations etc. You acknowledge that the constraints on this kind of approach means you will iterate slower than other teams.

If you are in a colocated team who want to build and iterate on a product quickly this kind of approach is extremely wasteful. Just push to master as quickly as you can and talk to each other.

Comments

[Adrian B.G.]

In common parlance, the word fetish is used to refer to any sexually arousing stimuli, not all of which meet the medical criteria for fetishism.[5] This broader usage of fetish covers parts or features of the body (including obesity and body modifications), objects, situations and activities (such as smoking or BDSM).[5] Paraphilias such as urophilia, necrophilia and coprophilia have been described as fetishes.[6]
Source Wikipedia

Anyway, just a few words on the 3 points

• Unfortunately most business/product owners do not put the performance in top 3 priorities, at least not until is verrry slow or paying customers complain, so we cannot dedicate time to improve it.
• Is hard to draw the line but I saw some devs where they took it too seriously and trying to fix a small repetition they added new layers of complexity.
• When I was a Lead I cared more about the actual real history, and dates of the commit and authors, and less about the actual message. We didn't squash/rebase them and I had an advantage by doing so, I could see who did what exactly when. I can deduct from the code what does the actual commit does, especially in the lack of tests.

[David Wickes]

To be super clear (if we're all off quoting Wikipedia YAWN)

Essentially, fetishism is the emic attribution of inherent value or powers to an object.

Where 'emic' means within the social group.

What Chris is saying (I think) is that the social group of developers attribute to the three objects (DRY, time to first byte, and 'clean' commit histories) inherent supernatural powers which they have in and of themselves.

If you are sexually aroused in any way by having a clean commit history, seek help.

[Chris James]

Also

Unfortunately most business/product owners do not put the performance in top 3 priorities, at least not until is verrry slow or paying customers complain, so we cannot dedicate time to improve it.

This is not really the point I'm trying to make.

If you are fetishising time to first byte then you are prioritising performance. The point is that you should not be prioritising that above everything else in respect to performance.

[Chris James]

I wouldn't get too caught up about the definition of "fetish".

is an object believed to have supernatural power

Wikipedia

[Moe]

Very good article! I really like your advice on DRY coding. I find myself overthinking when I put too much focus on DRY.

[Moe]

I was about to create some overly complicated DRY solution to two very similar functions today. But thinking about this post again, i decided against it. 🤗

[Chris James]

See the other comments, fetish is appropriate (if exaggerated) :)

[Scott Hannen]

I'm intrigued by the build-a-framework fetish, which - unlike the others you describe - isn't quite based on any useful principles.

What am I talking about? Let's say that as a .NET developer I need to store some data in some Azure tables. My tendency will be to create abstractions that aren't specific to Azure at all, and then in the implementation I'll use the classes Microsoft provides. The same is true for pretty much anything. Sometimes someone produces a really great library that simplifies the use of another, and if it seems really helpful then I'll use it.

The fetish I see is that developers immediately want to start building pointless, unnecessary "frameworks" to wrap existing classes, and then they want everyone else to use them for the sake of consistency. (This is much worse when it's a developer who can enforce it.) So now if I want to use an Azure table I have to use their weird, buggy wrapper class in a library named CompanyName.Frameworks.Storage.AzureTableStorage. Existing code is littered with dependencies on IMySpecialAzureTableStorageWrapperClass which a) isn't an abstraction because it can't represent anything other than Azure table storage, and b) hides or confuses the methods I need on the underlying classes. The solution? Add to the problem by modifying the wrapper. (I'm sorry, I meant "framework.")

It forces developers to learn someone else's bad proprietary code while denying the opportunity to learn the underlying API. In return it adds nothing except bugs and overhead.

It also gives some developers an opportunity to appear productive because they're constantly writing wrappers for stuff that doesn't need to be wrapped, and the fact that it's used everywhere creates the illusion that it serves a purpose.

[Ben Halpern]

I agree with this, but if I were going to debate anything it might be that conflating performance and usability with "doesn't work without Javascript". This is a possible consequence for some apps, but on the web, as it has evolved, delivering a fully-functional JS-free web experience seems like a reach.

For many sites, sure, it is silly to glob on all this JS. Probably most even, but many applications are built in a way to use the web as a JavaScript platform. So I think you have to distinguish between these use cases.

[Chris James]

The conflation was accidental on my part. The main point I was trying to drive was the over-emphasis on time to first byte can end up with teams ignoring other factors (like number of resources to fetch) and also the proposed solutions to improve time to first byte can also hurt the other performance metrics I mentioned.

[Rob Hoelz]

Thanks for sharing! Regarding DRY, were you referring to this article by Sandi Metz? sandimetz.com/blog/2016/1/20/the-w...