DIY - A parallel

Being picky in addition to being creative can lead to frustration.
Frustration that can be transformed into “something”.

DIY: “a term used by various communities that focus on people creating things for themselves” [1].
In the physical world, DIY often means to get one’s hands dirty.
In computer world, that means assembling software components.
In open source, that means doing a patch/pull request for an existing tool and/or creating a new tool altogether.
In all cases, DIY comes in when one needs to reduce the cost or/and to have something that fit perfectly into one’s environment.

I went through building a purpose built shelf and indoor flower hanger. Here is the reflection on the process and how it parallels to software (DIY).

Have a plan

It sounds obvious: the main requirement is to have a plan.
Going into DIY means you likely have a plan already, because you made the choice not to get it of the shelf.
The question is how much thinking went into the plan.

What is the goal

The goal is to fit the requirement into shape, shape that satify the end user(s).
In my case I needed some storage for books, DVDs, a TV stand.
I also needed that piece of furniture to serve as a standing desk.
It might do more, but cannot do less.
These are the minimum set of functions that the unit will serve.

What are the constraints

Cost, skills, time and access to resources needs to be factored in the plan.
I know I cannot afford a custom build shelf unit from a trades man.
I also know that I didn’t find anything fitting my need on the high street.
In order to get things done, I know that it shouldn’t require more than a week end to be completed.
I had the opportunity to get an experienced individual’s help.
I have a limited set of tools and a little appetite to hoard some more.

Constraint and context

Some constraints are equally limiting when writing software or building a shelf.
That said, some limits have greater visibility in the physical world.
I can see the exact space where the shelf will be, I control the runtime.
It is obvious that I need to take the radiator and the pipe going in and out of it into consideration.
In the physical world, things are payable upfront.
It is easier to reason with the cost of raw material than to think about running a LAMP stack on AWS.
I simply cannot buy rivets, screws, nails, epoxy adhesive, wood glue and tape and figure out later what I will need.
On the other hand, software makes some context explicit.
You cannot run some python app with a php interpretor.
You can have plastic garden chair with your freshly designe{r,d} table.

Execution

## Stick to the plan With the first hiccup in the plan, doubts will start to creep in.
The point of doubt is to try to make you change your mind, don’t. You might have to arrange for the fact that you only have 10 screws instead of 12.
You might want to hack things here and there for a non obvious skirting board angle.
You may realise that the end result will be less than optimal, but don’t forget that done > perfect

On tooling

A second obvious take on that DIY adventure is that tooling is important.
There is merit to start from scratch and use a little tooling.
There is also value in using the correct tooling, it’s not simply laziness.
If you have 100 screws and only 1 screwdriver, assembly will take a long time.
Then again, if you only have 100 screws, you don’t need the top of the range power tool. In software world, using top of the range tool is also payable later.
In software world, you pay in unused features and technical debt.

On experience

The last obvious realisation is that experience is worth all the tools in the world.
An experienced crafter delivers even with little to no tool.
The best power tool will let you build crooked furniture.

Build VS Buy

No word on buy vs build here.
There is nothing like the feeling of building something and getting it done.

[1] https://en.wikipedia.org/wiki/DIY_%28disambiguation%29