Late Reflecting on re:develop 2015

Here are my ridiculously-late notes from an ever-improving re:develop 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
• Amend agile to suit you, not vice-versa!

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

• Startup accelerators everywhere, especially Chile
• Just have your graph pointing up!
• Bournemouth funding programme available
• Don't be a dick #DBAD
• Watch your timing, though
• Allow for pivot moments
• Podcasts: This Week in Startups

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...

Containerise everything

• Docker 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?

• Performance requirements should be deliberate
• WalMart: load times affect conversions
• The 98th percentile matters, too, but so does improving good performance matters
• 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] microsite
• Think of the price cost to the user when loading your site
• Yellow Lab Tools 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: 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
• "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 the some of the interludes:

ODL

• Look for the connection voucher scheme, paid for by government
• The Open Device Lab is biggest in the world, so take advantage of it!

codebar.io

• Contribute to tutorials and the app
• Or a chapter in Bournemouth