With no
DDD South West this year, the first
DDD event of 2013 was the inaugural
DDD East Anglia. Held in
The Hauser Forum on Cambridge University's
West Cambridge site, the location was excellent for me as I have family living close by. So on a bright Saturday morning, I skirted around William Gates to park up behind Roger Needham (the buildings, that is), before joining a trickle of other early risers heading for the event.
Sign in was painless -
Phil Pursglove & the team had used
EventBrite to manage the ticketing, and had pre-ticketed the speakers - and then it was into the Speaker's room to drop off my bag before finding that essential first cup of coffee and a couple of very nice Danishes to start my day. Catching up with old DDD friends
Chris Alcock and
Michaela Murray meant I missed the speaker briefing (sorry Phil!), and had to sneak into the back of the "Welcome & Housekeeping" introduction.
Session 1
First up on the agenda was a choice of "
SignalR: Ready for Real-time"
with Dave Sussman, "
Async C# 5.0 - Patterns for Real-World Use" with
Liam Westley or
Pragmatic Dependency Injection with Ian Russell. I'd already seen Chris Alcock's SignalR talk at
DDDSW4, and
Liam's Async Patterns at
DDDNorth2, and have lost count of the number of times I've given a DI talk at work myself, so took the opportunity of treble-checking my own presentation deck and samples in the Speaker room, and to check out the contents of the goodie-bag.
For the first 10 minutes or so, it was a place of quiet work and contemplation - until
Mark Rendle arrived (following a hair-raising left-rear Pirelli blow-out on the motorway the night before), and re-kindled what was clearly an on-going wind-up session with
Rob Ashton that at one point had me practically in tears with laughter.
Session 2
With my presentation ready (and that one last-minute important mega-slide added to the deck), I headed into the first of the three seminar rooms to hear
Chris O'Dell talk about how they have embraced continuous delivery and
Kanban at
7Digital.
Chris described their development process, and how they've moved from what was once a painful waterfall process to a highly agile, fast-sprint, multi-track development process where live releases happen almost all-day, every day (except after 4pm and on a Friday)
The key take-aways were:
- To ensure that Tech Debt is highly visible.
- To visualise tasks as soon as they are identified
- To move Product Owners PHYSICALLY nearer to (or even better embedded within) the development team
- To foster a no-blame culture
- To hold twice-weekly cross-team show-n-tell sessions to enable cross-pollination.
- To promote retrospectives, particularly for management
- To radiate metrics and visualise them - the more the better - displaying them on monitors all around the office, and continually updated to the minute.
- To analyse cycle time for changes per feature and the number of features completed per sprint or per month as the prime KPIs.
Chris described how adopting this process doesn't happen overnight, in fact it took many months to bed in at 7 Digital. Pair programming and TDD with LOTS of unit tests and plenty of acceptance tests accelerated the process - and advocated inverting the "Testing Triangle", so that your process relies more on unit tests and automated integration tests than end-to-end tests.
At 7 Digital, the teams are cross-functional, but focused on a fairly small cross-section of the overall component set (7 Digital use small-API service based components), but there's a fair amount of movement between teams - allowing staff to dip into any component they find interesting or to get a broader view of the whole.
Their deployment process is entirely automated - a small fix can go from analysis to deployed in a couple of hours, and Chris emphasised that the ability to do a scripted "roll-back" is essential (although like many companies, roll-back is actually a roll-forward of a previous release at 7 Digital).
They have a blue/green flip-flop deployment process - similar to the Azure Production / Staging system, and use feature switches (where features are enabled in the code-base via configuration) rather than having code-branches in source control. A vital part of the process is running smoke-tests on the deployed code to verify basic functionality immediately rather than waiting for a user to be impacted by a fault.
Their acceptance tests are all Cucumber and browser based, and are the fundamental quality gate - breaking an acceptance test for a new or existing feature is guaranteed to raise red-flags.
I really liked Chris' presentation - it provided an insightful from-the-trenches view of how Kanban and continuous deployment can be made to work well, enabling a continuous flow of feartures being released..
Session 3
Session 3 was
Rob Ashton's "Testing MVC" presentation - fast-paced to the point of almost being manic, funny, thoroughly enjoyable, and containing a good number of ponies to boot, Rob was effectively a proponent of exactly the opposite of Chris's methods, arguing against inverting the testing pyramid, and of doing "barely enough" to ship a workable product. All the same, Rob still gave a plethora of hints and tips, including:
- Always write a statement of intent (feature / scenario) first.
- The most important thing about testing MVC are speed + feedback
- PhantomJS is (currently) cool, but DO use WebDriver to run it. Selenium (currently) sucks.
- Next month may be different
- Avoid duplications in UI tests at ALL COSTS.
- Coypu is the Capybara equivalent for .Net
- For writing UI automation and abstracting away the client UI
- There is no excuse for UI tests to be slow
- Don't bother trying to abstract RavenDB
- Actions on your model are good
- Sometimes simple is absolutely good enough.
- If there's logic in the controller, try pushing it into the model, or a service
- With simple, facade controllers, you don't need controller tests!
- Controller actions should never have more than ONE "if" statement
- All your logic should be abstracted from the MVC framework for testability.
I'd not actually been to one of Rob's talks before, but he's so entertaining, and presents with such enthusiasm that I can see why he's such a popular speaker.
Grok Talks
After Rob, was lunch - the standard fare of a sandwich bag, but a very nice sandwich bag all the same - and Grok Talks.
I missed the first couple, as I was too busy eating and catching up with
Liam Westley, but caught an excellent short talk by
Richard Dutton on how they write the pit-wall and back office software in the
Infiniti Red Bull Racing Formula One team.
I'm hoping he'll submit a full talk for a DDD event, as in the 10 minutes he hinted at a development pace few companies can aspire to, with data sets and data rates that would make most devs blanch, even without 6 hour feature deadlines when races are back to back.
Session 4
My final session (as an attendee as opposed to a speaker) was
Ben Hall's "Startups and Minimal Viable Products". This was a no-code, all slide discussion of taking the lean startup mentality as far as it can go.
Ben is "Hacker-in-Residence" at a startup incubator, and brought a "lot of experience of failing" to his presentation. As such, it was very much about "Quicker, faster, leaner" and getting your idea off the ground... and about knowing when to can the idea without remorse.
He described the mantra of "lean startups" - namely that of going from Idea to Build to Release as quickly as possible. Until the product has been built (or at least convincingly faked), then there's no way to measure its impact and acceptance. And without measuring the success (or failure) of the product, you can't learn or make decisions about it.
With that process in place, then it becomes good to fail - but you need to fail FAST. It's no good hanging onto a failing concept just because YOU like it if its' never going to succeed.
Success, however is not about WHAT you do, but WHY you do it. Ben drew a comparison between Apple who design beautiful products (including beautiful laptops) as opposed to Dell who "just make laptops". The difference is the belief in the vision, not in the implementation.
Part of the success (or immediate failure) of a startup concept can be driven from a "Business Assumption Exercise", which provides a framework for deciding on the basic "Go/No-Go" decision. Ben talked about developing 4 or 5 initial concepts to the wireframe stage before lunch, canning 4 immediately and then developing the last concept in the aftenoon to decide whether it had legs or not.
This kind of velocity is frankly mind-boggling, but I can see how it gets results - the wheat is separated from the chaff at a VERY early stage, and little effort is expended unless there's a very good chance of return on the investment.
After Ben's brain-baking session is was on to the last session of the day... mine.
Session 5
My session - "An Introduction to
Octopus Deploy" - was designed as a very light look at an interesting new product that makes deployment of (particularly, but not only) web apps to server clusters easy.
I've uploaded the
slide deck here, but hope that the main take-away for the attendees was that
- Controlled deployment is essential
- Rollback matters
- Octopus Deploy is a pretty good turnkey solution for deployment
- Packaging your software for deployment is pretty easy with NuGet, especially with
- OctoPack - for web sites
- NuGet.PackageNPublish - for Azure (see how I got that in too!)
Closing
After my talk, there was a few minutes of re-organisation of the 3 seminar rooms into one before the closing swag-out. Phil used the DDDSW method of picking feedback sheets - though not as quickly as
Guy Smith-Ferrier has done in the past, so there was less of a scrum around the swag table.
Redgate again gave away some great software bundles, but the mega-swag of a pair of iPad minis was definitely the icing on the cake in terms of swag.
DDD East Anglia was a great success in my opinion - good location, great talks, fabulous organisation - Phil and the team should be justifiably proud of their achievement.
Do roll on DDDEA 2!
