Wednesday, July 31, 2013

This one caught me today... When loading a crashdump into Visual Studio, the IDE can get its knickers in a twist and cache all the symbol files in the same folder as devenv.exe.That'd be fine, but the symbol files are cached in folders with the same name as the DLL - so the IDE creates a FOLDER named System.dll (etc) in its own folder - and next time you try and start Visual Studio you get this...

Unpleasant, for sure. Fortunately, I found a Connect discussion that showed the problem, and it's easy enough to fix by deleting all the (obvious) cache folders from C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE.Just annoying, and I'm sure I've still got more clart to clear from the IDE directory. (sigh)

Wednesday, July 10, 2013

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.

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

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.