Home improvements vs code improvements

So I've been a bit of a DIY guru at the moment and managed to get a few rooms from our flat refurbished. Surprisingly it's not that interesting when you're painting a wall (slightly better than watching it dry) and my mind started to wander about similarities with how we approach home improvements and how we can approach code improvements.

Yeah ok bear with me this might all be rubbish you can blame it on an access of paint thinning fumes. These are in no particular order but hopeful someone can appreciate what I'm try to say here:

1. Plan it and do it

So I figured I'd hit the bathroom first... probably the hardest of the 3 rooms I was doing and also the one with the most work. But the number one reason to do the bathroom - I had to get it done. The spare rooms could wait but was no way we could last any longer with a crappy shower and toilet (no pun intended).

Comparison? Whenever our dev team is handed a problem we always break things down into features and prioritise them in order of value - what can't we live without? If we nail this feature will it set us up nicely for the next one?

Team discussions around features are generally pretty short, same with DIY - discuss, plan and give it a go. No messing. You'll soon realise the plan is flawed or the tools you are using don't work.

If that is the case - stop. Don't waste any more time. Catch up with your team and think of a better way to produce the feature.

2. It's all in the preparation

I can't believe how often this was said to me by other people who were lending me a hand - "Make sure you sand that down before you paint it", "If you want a good finish make sure the prep is done well first". And they were right.

I see acceptance and unit tests as preparation for a feature. If you want a good 'finish' get the tests down first. In development there are times when we don't know how to test or even how we're going to solve a problem. That's ok, spike some code and get things straight but as soon as you can make sure you revisit and plug in the tests.

3. Look to improve

The reason I was so busy trying to fix our flat up was because I let things slip - the equivalent of technical debt I guess. Had I kept on top of things while I lived there I wouldn't have had to refurb 3 rooms in one hit.

Same with code - don't let that technical debt build up, tidy as you go. It's very rare a dev team is allowed free reign to clear technical debt so let's be up front and if we see something we can fix, fix it. This does come with a big but... BUT make sure any refactoring or improvements are fully tested ideally with acceptance as well as unit tests. Ensure you are improving code and not causing more issues for someone else.

4. Use external sources

The really bad thing about home improvement is the cost. Wow it's expensive. So I tried to do as much as I could myself but there were things that I just couldn't do. Plastering and plumbing for example. Nightmare - so I gave the job to someone who knew how to do it properly.

Going back to code, is there something that can do this feature better than you can? I'm reminded of companies who build their own CMS or blogging system. Why? Use Drupal, Wordpress, Blogger or any other application that has a good reputation within that area.

Don't be afraid to use an expert if it's quicker, cheaper or just a real a bitch to do yourself.

5. ALWAYS add value

Whenever a feature is discussed ask the question:

'What's the best result we can achieve for the least amount of time and money'

That's the reason we look after our property so why should code be any different. I'm no property expert but I'm pretty sure the amount of time and money I put into our home improvements means the value of our property has increased.

Can we always say the same about the features we produce?