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
RedirectToLoginIfUnauthorised
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 your self 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.

Postscript:

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

Friday, 21 July 2017

My first conference talk

I gave my first conference talk over the weekend at DDD Sydney. I co-presented with my colleague Anjali Wadhwa one of the QAs at nib. It was a great experience, made all the better by the fact that the talk was well attended and received, based on post talk questions and twitter reactions.

Moving from giving talks at the Newcastle Coders Group to even a small conference forced me to change the way I think about and practice a talk. At the suggestion of Anjali we broke the talk down into small chunks that could be timed and practised independently. This made practising the talk much easier and allowed us to have time based running notes for the talk. Which meant that we could adjust the talk dynamically if we spoke too fast or got held up on a section.

The fact that breaking a talk up into smaller atomic chunks sounds very much like what we do with code was not lost on me. The software craftsmanship principle of keeping everything small and focused on doing one thing well keeps creeping its way into other aspects of life. 


Standing room only in the presentation. 
I'm proud to have my first conference speaker shirt.

Friday, 24 March 2017

Can't resolve DNS Aws

I recently registered a domain for a joke website saladsimulator.com.  I figured I could whip up the page in a couple of minutes and throw it up on AWS using S3 static site hosting.  All done in an hour or so. What I thought would take an hour ended up in a multi-day ordeal while I tried to get the DNS to resolve.  I went through what seem to be the typical problems.
  • The bucket wasn't configured to be accessible as a website.
  • My bucket wasn't named the same as the website; the bucket needed to be saladsimulator.com to match the domain saladsimulator.com.
I got these fixed up and found that it still wasn't working.
 I added extra routes in to see if I could Alias or CNAME to a known working site, but they didn't work either. So it seemed it was a problem with something to do with the DNS configuration.

After searching around I found a mention in a thread that the name server records in the hosted zone needed to match those in the domain name registration.  In attempting to get the hosted zone to recognise the bucket I had deleted the one created by default when I registered the domain.  The new hosted zone did not have matching name servers to the domain name.  I updated the domain's name servers to match that of the hosted zone, and BAM! name resolution.

So in the end I needed to make sure that the domain name servers:
Route 53 > Registered domains > saladsimulator.com

matched those in the hosted zone:
Route 53 > Hosted zones > saladsimulator.com

Sunday, 5 March 2017

Solving `Empty reply from server` in DotNet Core

tldr;

If you’re getting curl: (52) Empty reply from server check that you’ve configured Kestrel correctly.

Long version

I’ve started playing with Dotnet Core and Docker and have had a few issues getting started. I’ve had a little bit of experience with Docker, though only a little. I’ve worked with DotNet previously but never with Core.

Environment

The setup I’m using is a Windows laptop running Vagrant. Via Vagrant I’m running an Ubuntu Virtual Machine with the Docker run time installed. Feels a litle like inception.

Key Problem

The key problem that I’ve had getting started was having my Docker container not responding correctly to my curl commands. I get this:
curl: (56) Recv failure: Connection reset by peer
curl: (52) Empty reply from server
Given that I’m not all that familliar with Docker or Dotnet Core I decided to remove one of the variables and set up a simple Express app in a different docker container. This validated that the commmand I was using to run the container (docker run -v /vagrant/dotnetcoretest/src:/src -p 5000: 5000 -d dnctest dotnet run) was binding the ports correctly.
This left a problem with the Dotnet Core web api app. I was surprised that this would be the problem given that I had created the app with the dotnet new webapigenerator.
Searching around I found that the problem was that by default Kestrel listens on localhost:5000. To fix this add .UseUrls("http://*:5000") to the WebHostBuilder in Program.cs. It should now look like
public class Program
{
    public static void Main(string[] args)
    {
        var host = new WebHostBuilder()
            .UseKestrel()
            .UseContentRoot(Directory.GetCurrentDirectory())
            .UseUrls("http://*:5000")
            .UseIISIntegration()
            .UseStartup<Startup>()
            .Build();

        host.Run();
    }
}
Rebuild the app and run curl localhost:5000/api/values and you should get ["value1","value2"].

Wednesday, 4 January 2017

Right hand side

Would you work somewhere that advertised. "Working on a well documented code base,  a well thought out product strategy for long term stable well specified contracts all the while using the latest tools and processes to deliver great software?"

If you answered yes then you've answered yes to somewhere that may well not follow the agile manifesto. All these things are on the right hand side of the manifesto.

Individuals and interactions over processes and tools
Working software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan

So why point this out? it's because too often I find people forgetting that the agile manifesto and agile software development is about the whole thing, "while there is value in the items on the right, we value the items on the left more."

In the end agile is about delivering working products that meet the clients needs and that means remembering to value the right hand side of the manifesto as well as the left.