Software engineering fetishes
Tags: beginners, methodologies, healthydebate
Published: 2018-09-10 15:56:13

---
title: Software engineering fetishes
published: true
description: Some things in software development become conversation-killing, thought-ending truisms. Let's re-evaluate them.
tags: beginner, methodologies, healthydebate
---

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](https://github.com/npryce/adr-tools).
- 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.