Skip to content
Darren Hickling

Late Reflecting on re:develop 2015

Published on 4 min read

Written 10 years ago, so some details may have moved on.

Authors

Here are my ridiculously-late notes from an ever-improving re:develop (opens in a new tab) conference. In short: it was excellent. It was interesting to see software mimicking real life, such as pipelines and containers. It was even better to see more women presenting and in attendance, too.

Reviewing my notes below has meant that I have taken the time to research them, and think of how they are applied to current and future projects. They are still very relevant, so I hope you find some of them useful, too. Maybe I should always post notes this late...

Presentation Notes

User Stories Refactoring

  • Impossible to manage too many user stories
  • Who will notice if we delete them? But the fear...
  • Don't create a backlog, they become outdated anyway
  • Write a sentence instead of the user story template if it doesn't make sense
  • Must be able to validate the story output!
  • Pin features on love versus ROI chart
  • Add performance indicators on features; will this improve or worsen performance?
  • Hard to include users in the feedback loop of the releases when cycles are too long
  • Look up innovation game, such as the feature tree (opens in a new tab)
  • Amend agile to suit you, not vice-versa!

9 out of 10 start-ups fail, good because this is number 10

Pipeline Architectures

  • Manufacturers are experts at pipelines
  • 1 car in 70 minutes to 4 in 40
  • Consistent textual data formats are key
  • Account for buffering in a pipeline model
  • Can use sequence numbers in pub/sub to account for missing messages
  • No idea what is the last message, though!
  • Use unique jobs to stop single consumers from hogging resources
  • If you use a non-standard transport protocol, ensure every environment can use it!
  • Error-handling: put it back in the queue n times, then add to error queue
  • N services => n deployments
  • Impacts network latency
  • Serialisation overhead, but text inputs let you play with the program!
  • Conway's Law (opens in a new tab)...

Containerise everything

  • Docker (opens in a new tab) uses checksums to better cache resources
  • Official containers are provided, such as Elasticsearch
  • Fire up a small container for a quick task

Speed Matters - So Why is Your Website So Slow?

re:develop 2015 performance budget
  • Performance requirements should be deliberate
  • WalMart (opens in a new tab): load times affect conversions
  • The 98th percentile matters, too, but so does improving good performance
  • User can be suspicious if the site is too fast, though!
  • Developers tend to forget network latency, has a huge impact

Performance Budgeting For A Seamless User Experience

  • For web pages, bandwidth over 5MBPS doesn't improve performance greatly
  • Set a performance budget: performance should be a requirement!
  • State of the Internet: Akamai (opens in a new tab) microsite
  • Think of the price cost to the user when loading your site
  • Yellow Lab Tools (opens in a new tab) is OSS for page performance

This is for everyone: accessibility and you.

  • This question must always be answered: what does the user need?
  • Equality Act (opens in a new tab): make reasonable adjustments for disabled users
  • Disabled users are just trying to give you their money, too!
  • £100m project, 2 years in the making, yet an iOS screen reader crash goes unnoticed...
  • Web Accessibility in Mind (opens in a new tab)
  • "Angular is the poster-child of writing shitty HTML"!
  • Web design is 95% typography
  • "We stopped sounding like the government"
  • Try just one change to make your product more accessible

When arduino meets application server: love at second sight

  • BOUNCE! BOUNCE! BOUNCE!
  • "Most of us have 3 Raspberry Pis in our drawers"

And Finally...

Here are some quick notes from some of the interludes:

ODL

codebar.io