Saturday, 3 February 2018

Bush Mechanic Headphones

My Razor Kraken headphones broke. Devastating.

One of the arms was broken through and I wasn't ready to let them go.

So in the great Australian tradition of a trip to Bunnings can solve everything, I ran down the road grabbed some things and bush mechanic-ed them back to health.

I reinforced the broken arm with some flat steel I super glued over the break to hold it together while I added a larger reinforcement to the outside of the arm.  I attached these with clamps made from aluminium bar.

Now they're back in working order.  Happy days.

Sunday, 31 December 2017

2018 Goals

The following are some professional goals I have for 2018. I'm hesitant to call them New Years Resolutions because these goals have emerged over the course of 2017 and are not a spur of the moment list that I've come up with on the 1st of January. That and I have never liked the concept of New Years Resolutions they seem flimsy, unplanned and all too often they seem to be forgotten by the end of January.

So that said this year I aim to:
  • Blog More: In 2017 I posted 9 blogs, not including this one. So I'd like to get at least 10. I'll give myself bonus points if I can average out at 1 a month. 
  • Speak More: in 2017 I spoke at my first conference, DDD Sydney. I'd ideally like to increase that but at least speak a 1 and give several user group talks. That leads to...
  • Submit More CFPs: Last year I only submitted 1. Without giving it much consideration a minimum of 5 seems like a good minimum for this goal. 
  • Keep Coding: This one is a little less S.M.A.R.T. but I really like software development and with my overarching goal of speaking and blogging more I don't want to stop writing code, both at work and in my spare time. 
  • Keep My Job: This should be a bit of a gimmie, but I'd like to have it down anyway. I like my job, I like the people I work with and I want to stay there. Extraneous circumstances aside I'd like to not change jobs in the next 12 months.
I've put this down publicly with the dual purposes of keeping track of my goals and to hopefully inspire me to be open about completing them, or even failing to. 

Friday, 29 December 2017

How bad posture contributed to me loosing a rib.

I was recently given a really strong reminder on the importance of posture. We all know it's important, maybe it might cause your back/shoulder/arm/etc to hurt if you don't do it properly but we put off thinking about it because it's too hard or not that important. The following is a short account of how I was reminded,0 over the course of multiple surgeries and time off work that used up all my sick and annual leave with still more time off unpaid, just how important good posture is.

My reminder came in the form of a 15 cm subclavian blood clot in the left side of my chest. A combination of bad bone architecture, bad posture, compressing my chest cavity, and a little bad luck limited the blood flow through the subclavian vein (running between the collar bone and the first rib) causing a blood clot.

I reported prominent veins in my chest, some swelling in my left arm and some minor soreness under my arm to my GP and she sent me for x-rays and an ultra sound. The ultra sound technician called her and I was told to go straight to the emergency department at the hospital. After a typical wait in the emergency department I was admitted into hospital.

After seeing the surgeon she suggested clearing the clot followed by a 2nd surgery to remove the 1st rib to prevent further clots forming.

The clot removal needed to happen in the next week to have a good chance of success. The risks were reasonably severe with the anti clotting agent capable of causing life threatening bleeds in the brain or gut. Fortunately neither of these things happened.

The 2nd surgery was much less risky but much more painful, she made an incision under my arm and used a tool to nibble the bone of my 1st rib away, well 3/4 of it at least. This resulted in 4 weeks off work taking a lot of pain killers and a patch covering most of my underarm and some space on the back of my arm that will never have proper feeling again.

Now 7 weeks from the 2nd surgery my recovery is going well. I'm allowed to drive again and I'm looking for a physio to help out with better posture, getting my strength and the last of my movement back.

In the end better posture, say not hunching over a laptop, would have helped to prevent much of this. I've written this down to remind me, and anyone who reads it, that there is real world consequences to having bad posture.

Saturday, 23 December 2017

The greatest teacher, failure is.

There is a line in the most recent Star Wars film, The Last Jedi, from Yoda.
The greatest teacher, failure is.
This line resonated with me in relation to software development. Recently at work we've been having some discussions about challenging our preconceptions about how we do things. Now consider the line from the movie, sometimes we do things a certain way because we know that it's the best way to do things and probably we're right. How do we know? Is it just some innate thing that everyone knows? Or is it because someone told us that this is the way things are?

Lets look at some things about software development that we know to be true.
  • TDD is good and makes more maintainable code.
  • Global variables lead to un-maintainable code.
  • The language that you don't like is bad.
  • The language that you do like is good.
Now when did you last time that you challenged these ideas? When was the last time that you were able to, knowing that you would probably fail?

This is where the idea of Coderetreat comes in. As the page says. 
Start with a simple programming problem: Conway's Game of Life
Work with different partners to discuss and solve the problem
Add restrictions to force you to consider different approaches
After each round, throw out your code and repeat!
Adding restrictions and working with different partners is a great way to force yourself to fail and to challenge your ideas. Throwing the code out after each round is a great way to remove the pain from failure. Doing it in a group is a great way to bond as a community and share the fun of learning through trying to fail.

Wednesday, 6 December 2017

React makes OCP so easy it's a joke

Composing components in React means that following the Open Closed Principle (the O in SOLID) is so easy that it's laughable.

By composing, or decomposing, React components together new functionality can be added and functionality can be removed without making any changes to the underlying components. Want to make sure that you dont show a profile page unless someone has been logged in? Wrap your profile page in a
component, that checks for the user and redirects to login if they have not yet logged in.

As a bonus when you split and compose your functionality like this you end up with smaller components, that do less. So by following the Open Closed Principle in this way you get the Single Responsibility Principle for free.

Clean Code keeps on delivering.

Monday, 4 December 2017

Why are you estimating?

In a previous job I had a quote stuck up behind my desk that I would point to when a manager asked me for an estimate.  I cant remember the exact wording but the gist of it was something like:
Before asking for an estimate first ask yourself what decisions the estimate will be informing. 
I loved this quote because it points at one of the biggest problems that I think the software development industry has with estimates, and one of the reasons that they are, so often, so wrong.

Too often we estimate work in a vacuum without adequate knowledge as to why the estimate is being asked for, or how it's going to be used. 

There are many different, and valid reasons to estimate work, and different situations call for different techniques. For some of these cases the trivariate estimate method that I suggested in a previous blog is a great answer that will provide low level detail about the estimate and allow good decisions to be made, for other cases it is a massive waste of time. Similar ideas can be drawn for the story points, t-shirt sizes or the no estimates movement.

Each type of estimate is suited to a situation, and you can never know what is needed unless you can understand why you're being asked for the estimate and what decisions that estimate is informing.

Monday, 13 November 2017

Better estimates: Trivariate Estimation.

Tell me if this story sounds familiar.
You sit in yet another meeting. Listen to business stakeholders talk about what they want. Then you're straight into another meeting where you sit down to come up with an estimate. Eventually you emerge and present it to the business stakeholders. They take this number as fact, as a concrete answer for how long this piece of work will take. Of course in the end the number is not representative of reality. Someone gets upset, because you’ve gone over budget, missed a deadline or simply because reality didn't match with the image in their head. Postmortems are done. The next project starts and the cycle repeats. Eventually people start padding estimates. The whole process breeds distrust, distrust kills teams. Familiar? I thought so.

What can we do about it? As an industry we’ve tried a few things. Solutions such as estimating in comparative complexity units like story points hasn't solved this problem, nor has only having experience team members do the estimation, or having the whole team estimate. The current buzz word in estimation is #noestimates, I feel that this is just hiding the estimate somewhere. Just like the cloud is someone else’s computer, no estimate means someone else is estimating your work, for you, without you. My answer to the estimation problem is the trivariate estimate method, rather than using no estimates, use more.

I was introduced to the trivariate estimate method reading The Clean Coder by Robert C.’Uncle Bob’ Martin. I have since used it in the real world and found that it has greatly helped with the quality and acceptance of the estimates I have provided.

The idea is simple, three estimates, the Best Case, the Worst Case and what you actually think it’s going to take:
  • Think about how long it’s going to take, write that down. This is the Normal Case.
  • Now imagine what could go wrong, everything, you’ve had a terrible night’s sleep, the coffee machine is broken, the work is only half specced, last minute changes come through, and people. Just. Keep. Bothering you. How long will that take? Write that down. This is the Worst Case estimate, if it looks too high then it’s probably in the right ball park.
  • Now think about what would happen on your best day, everything goes great, you’ve got all the details, you slept blissfully, the coffee machine is putting out better coffee than it has in years, and the work environment is perfect. How long will that take? Write that down. This is the Best Case estimate.

With these three estimates in hand there is enough data to compute some meaningful information. A quick warning if you give these estimates to business stakeholders directly they are almost certainly going to be misconstrued. Some people will look at the upper estimate and say “Whoa Nellie! That’s too high. Do it again”, others will look at the minimum and say “Yeehaw! Let’s pile some more work in.” either way the goal of providing a more realistic and trustworthy estimate is out the window.

The computation to turn these numbers into more useful information is (Best Case + Worst Case + 4 x Normal Case)/6 this gives the Final Estimate.

If you think about estimating something that isn’t software development, let’s say driving across town you’d never say that “I Estimate that it will take exactly 1 Hour 17 Minutes and 12 Seconds” You might say. “It’ll take an 1 hour and 15 minutes, give or take 10 minutes depending on the traffic.” This “give or take number” is the Error Margin. The Error Margin can be generated using a very simple function (Worst - Best)/6. The Normal Estimate plus/minus the Error Margin should account for the majority of the estimates if we presume a normal distribution.

By being able to give not only Final Estimate but also a indication of the confidence of the estimate, provided by the Error Margin, and being able to communicate the Worst and Best Cases allows business stakeholders to make decisions with a better understanding of the full picture. This improves communication between the teams and the business stakeholders. Allowing them to understand the estimate and it's stability.

Better communication and understanding, breeds trust. Trust grows healthy teams. Healthy teams make better software.


As with anything, this estimation tool won’t solve all estimation problems. You need to be pragmatic with the use of any tool. Trivariate Estimation is certainly not the correct way to estimate for a number of situations. However, if you need a way to improve your estimates so that the that provide more meaningful information to base decisions on then this tool may be what you’re looking for.

Important Calculations

Estimate Value = (Best + 4 * Normal + Worst)/6
Error Margin = (Best + Worst)/6