Author: paulthecyclist

MY NDC London Highlights

A couple of weeks ago, I was delighted to be able to attend NDC London, and be part of the crew.

Below is a brief commentary on some of the talks I attended. The NDC crew are uploading videos all the time, I’ll try and update this page with links to the videos when they become available. You can watch the videos here

Scott Hanselman delivered a typically polished and amusing keynote, the gist being that we’re finally starting to deliver web applications instead of delivering applications inside web pages. Scott’s keynote can be found here.


tbl_hanselman

“…none of us can ever have a title higher than web developer”

Good point, if Tim’s just a web developer, are you really a senior web developer? More to come from Scott Hanselman, Principal Program Manager at Microsoft.

The theme of delivering content, without fighting the Web carried on.

20160114_162912

Dylan Beatie

Dylan Beattie built on this, with his, the rest of REST talk. Take away for me was, you should be using Hypertext in your RESTful APIs. Dylan introduced us to Hypertext Application Language (HAL).

20160115_102200

Ali Kheyrollahi

Interestingly, Ali Kheyrollahi, in his talk 5 Anti-Patterns in designing APIs, also touched on Hypertext; His solution was a little different, preferring to use HATEOAS.

David Neal presented a lovely introduction to Node.js. Certainly presented a case that you can build really good apps with this. Cited nice example of how the new Visual Studio Code editor is built on top of Github’s Electron, which is, you guessed it, based on Node.js.

20160113_181227

Peter Meyers

Peter Meyers delivered a great talk, building a demo from scratch, showcasing how you can use Azure’s Machine Learning, to use a basic neural network to predict data. A very hands on demo, a lot of complex content covered and explained beautifully. Brought back happy memories of my student days studying AI.

20160113_102159

Kevlin Henney

My favourite talk, was delivered by Kevlin Henney, SOLID deconstruction. A measured and thoughtful look at the SOLID principles, where they come from and what they really mean. I liked it, as it encouraged you to think. Enough that I already have a couple of blog posts in mind on the back of it.

20160113_151357

Doc Norton

Doc Norton gave a good talk too, the building blocks of knowledge culture. To me it seemed like a look into the future of how great (software) companies will be. Takeaway for me was, the idea of having fluid teams, let people choose the team they want to work in. It works.

20160115_122656

Dan North

Dan North also gave a thought provoking talk, with a new take on how to structure your agile department. Not sure it’s what he wanted the audience to take away but he talked about what an hypothesis is (a falsifiable statement, he concisely stated). It’s also something to be built upon, as you learn more. Agile methods should and need to be improved all the time, his talk introduced us to some new ideas that worked for him when it comes to scaling agile (you can’t scale agile!).

20160115_140843

Scott Hanselman

I saw that Hanselman fellow again on Friday, tooting the wonders of Azure.

Microsoft wants your for loops.

He happily chimed. On a personal note it also wants you to set the service level for your app services incorrectly too, in it’s ever confusing portal (cost me over £50 for that mistake). He is a very accomplished speaker too, pleasure to be entertained by him.

Talking of entertainers, king for me was Troy Hunt. So entertaining! Nice guy too, as his crew, I had a nice chat and handshake before the show, Making Hacking Child’s Play. Best bit – the HarlemShake, works on far too many sites and it’s soooo fun!

And finally I saw John Skeet, live, 3 times. No words can convey how deep and impressive his C# and OO knowledge is.

Advertisement

1+3 != 4

Please stop adding story points

“I’m not sure if I was the inventor of story points, but if I am, I’m sorry” – Ron Jeffries

What is a story point

At their heart story points are an estimate of how much effort/complexity a piece of functionality is to deliver. This estimate is often represented as a number.

That’s fine, but please stop adding estimates!

Let’s say you use Fibonacci numbers to define your story points;

  • A 1 point story could be a trivial change, like fixing a typo
  • A 3 point story could well be something more involved, say adding a couple of textboxes to a website page, and persisting the data entered in them.

How much work is that?

If you have 2 stories, one estimated at 3 points and one at 1 point, how many story points is that? A total of 4 points is something I have heard.

Now, what if I have 10 stories, all sized at 1 point. By this logic we have a total of 10 story points. Nothing wrong with this, assuming the only goal for adding the story points is to re-affirm en elementary grasp of numbers. It gets funny if… you want to know how long the project will take to complete, based on this.

Week 1, we complete only 3 point stories, and complete 5 of these in 5 days.

Week 2, we complete only 1 point stories, and complete 100 of these in 5 days.

I have seen this interpreted as, in 10 days, 105 story points delivered, averaging a velocity of 52.5 story point per week. The sized backlog, stands at 150sp, so all should be complete in approx 3 weeks.

Spread the points

mathsHopefully you can see the problem here.  We can deliver small stories really fast and bigger stories, slow.

In the above example, the longest 3 point story took 2 days to deliver. The longest 1 point story took 3 hours.

The shortest 3 point story took 3 hours and the shortest, 1 point story, took 0.5 hours.

The backlog, has 99 one point stories and 17 three point stories (150 story points, mentioned earlier), so the longest time to complete could be:
99*3hrs (297) + 17*12 (204) = 501hrs = 83 days.

Optimistic time is:
 0.5*99 (50) + 17*3 (51) = 101hrs  = 25 days

At this stage I wonder if I’m writing a maths blog… Lots of numbers here, all based on, an estimate! Some people make the mistake of aiming to deliver n story points per sprint, and when stories are not delivered post mortems happen, to see what went wrong.

“I smell something fishy and I’m not talking about the contents of Baldrick’s apple crumble.” – Blackadder

Nonsense, the lot of it. The only way you can deliver a consistent number of story points per iteration, is if all those stories are the same size and your team’s ability to estimate (and create stories) that are the same size is amazing.

Keep it simple

If every story is enhancing your product (as they should), at the end of your iteration some stories will be ‘done’ and you will have enhanced your product. Story points can be used for getting a feel for the size (complexity/amount of work) a story is. This is useful to the product owner to see how much effort a requested feature is, to help with their prioritisation. It’s also useful if you want to ensure you only take stories of a certain size into your iteration (i.e. a max of 3, say), encouraging story splitting. Story points have other benefits too, but for ‘big’ releases and tracking story point burn up/down/velocity… please stop.

In football the only statistic that matter is the score line; in software, it’s what’s delivered.

Image Credit: Pranav Yaddanapudi