Twins v. Tigers - great group, great night!
Bridgestone Blast from the Past
Another early 90's throwbacks - Bridgestone bicycles. I made a trip to One on One Bicycle Shop and Studio, and was expecting the basement bike junkyard to be the mecca experience. It was, but when I spotted this near-pristine MB-1 from 1992 for sale, well I found religion all over again. Not that I had lost it. I still ride my 1993 MB-3, accurately quoted in the '93 catalog as perhaps all the mountain bike anyone would ever need.
I have the purple, now beat up. Kath rides the silver. 1993, the last good year of Bridgestones before they pulled the plug on North American sales. In the new age of click shifters, suspension forks, neon and gimmicks, their retro-grouch principles caught up with them. Too bad, because I've found the Bridgestones to have the best geometry I've ever ridden. Not stretched out like a Trek, never twitchy like a Specialized... I passed on a pristine fire engine red MB-2 frame for $400 after grad school in 1997 - no money. So I never thought I'd see another high-end MB not completely beat up. Not so with the MB-1. You can't see it in the picture, but its an amazing pearl-white. Very little wear and a lot of original equipment. The partial MB-1 (missing the seat) is a 1993. Its not yet for sale, as the owner is tuning up to make for a better overall bike and sale. But I think it could be the better deal. The 1993 has a hand-made custom fork. Same pearl-white. There are a lot of great bike shops in the twin cities, but nothing like One on One.
Walt Mink still commands a star
If you were an early 90's mac student, or catching the local music scene then, no explanation is necessary. It was nice to see Walt Mink command a star 15 years after. So many good shows in the entry including the best show ever.
Fight Club Fishbowl Format
Driving discussion in a downright engaging and participatory way - that's the magic of DevJam's 'Fight Club Fishbowl Format'. Have you ever been to a user group only to find the conversation dominated by one or two blowhards? Fight Club Fishbowl solves this with a simple formula, and is a large group discussion technique worth considering for your workshop, unconference, presentation, or user group.
Following a presentation, participants take a short break and submit questions on an index card. Five seats are set at the front of the room (the fishbowl), the presenter takes a seat, and the audience is asked to fill out the remaining seats, leaving one empty. Only those seated in the fishbowl can talk.
The first question is read, the fishbowl responds, and anyone from the audience can come up to take the empty seat, bumping one of the fishbowlers. After five minutes of riffing on the question, the audience uses a voting system to indicate whether they should continue with this topic, or move on to the next question.
Fight club refers to the joke that if its your first night at DevJam, you have to 'fight' in the fishbowl. Not really actually, but its a good joke to tune people into participating, instead of just consuming in the audience. I wish I had used this for at least a portion of my Android App Dev panel at mobile TC, as its clear then (and was at DevJam) that the audience often has something valuable to contribute.
On a side note - I must say I had thought Refactr had the lock on cool space for User Groups, a good thing since they so graciously host so many. But nothing holds a candle to the tripped out, funky furniture and lighting effects of the DevJam party room. Actually it's Java Jack's party room, but it feels all Hussman. Comfortably held a large crowd and clearly said - this is not your father's user group (or in the words of one host - keep out lame assholes).
Fitnesse Friday
You know the drill. Your software needs better automated test coverage. Your testers need an easy way to create that coverage. You need a lever over your verification rate, but closing the gap is always out of reach of the individual team member.
Until Fitnesse Friday. Four developers closing the gap in one concerted effort. In a room together... all day friday.
Consider the classic problem Fitnesse excels at - a significant amount of complex business logic that lends itself to tabulated scenarios: Given a set of system state and inputs, a set of responses should be returned. In our case it's a scheduling service offering appointments. The operating hours, existing appointments, rules, scheduling and appointment scoring strategies, and asset configuration all combine to determine what appointments are offered when a user requests an appointment.
Verifying the correct behavior requires a large amount of test cases, and each test case (when done manually) is expensive with its non-trivial and at times obscure set-up. With Fitnesse, we leverage the fact that system state can be automatically set from the values in a test scenario wiki. And of course any scenario can be run automatically, over and over again.
Fitnesse Friday makes the whole of the effort greater than the sum of its parts - collaborating and sharing the work creates the synergy needed to close the gap. A few things that made it successful:
Incorporate Your Testers.
If you are lucky, they're collocated with developers and this is natural. If not - make sure to understand how they perceive the volume of work they are expected to test, and where Fitnesse fits in managing that workload. They are the customer, even if Fitnesse is largely going to be used by developers.
Prep a Backlog
Prep a backlog. Developers and testers met before the friday to prepare a backlog of features they wanted supported in the test scenarios. This ensured we were doing the most important things in the testers eyes and had a set of tasks for friday. And it lives beyond the friday - have some time to implement the next most useful thing? see the backlog.
Prep a Skeleton
Coming in cold on Friday would have required significant time just to get the basics plumbing stood-up, and that wasn't the backlog. One developer with previous Fitnesse experience spent a few hours wiring up the most basic scenario, then leading the developers in a quick intro. We also prepared a standalone Fitnesse environment on a spare PC to ensure we could provide an always-available Fitnesse installation.
Team Room
Get your team all in one room - non-negotiable.
Make it Fun
Franklin equipment makes sports bands with an F on them! Surely each team member needs one. We kept it light with team cheers and the Franklin Fitnesse Friday sweat band of solidarity. See the gallery below... Sports water and protein snacks kept the fitness theme going.
Our Fitnesse lessons learned...
Test Data Layout
We ended up deciding that each scenario should have its own page, rather than tabulate all scenarios in one long complex table. We use Fitnesse's 'SetUp' pages for repeated set-up tasks, and also the page inclusion to reference reusable system state elements.
Ex. !include -c SetupStandardOperatingHours
A given page will have several tables of set-up, a tabulation of inputs, and a tabulation of expected results. We build the system state up in a singleton as each table is processed by Fitnesse/Slim. The expected results fixture uses the built-up state.
Use Domain Terms/Natural Language
We started with a somewhat obscure approach for indicating system state elements based on pre-existing unit tests. We converted that to simple tables with the domain terms our testers expect. In some cases it was valuable to write a simple interpreter - for example - to understand the days of the week names as inputs 'monday', 'tuesday'. This makes the test definition easy to read and understand.
Prove value - then Assess Priority
We have a lot of open questions - how will we automate the update of the Fitnesse environment with the latest code? How to version/save/share test scenarios? First - do the simplest thing to provide value. We expect a payback in a single release, and lessons that will guide our next steps to improve this tool use.
Our Cup Runneth Over (But Not in a Good Way)
In the software release process we're continually looking for ways to improve our ability to deliver. From process to craftsman techniques there are a large number of levers to apply to this problem. These levers need to shift the Volume to verify and/or the Rate at which verification occurs. If they don't, they aren't contributing to the solution.
The QA Verification process is governed by the laws of physics, and as such, it can be described mathematically. Each release contains a volume of functionality (V). The developer and tester's ability to verify occurs at some rate (r) - for the purpose of discussion think of it as 'how much software can be verified in a day'. A given release has a capacity (C) – the volume we can support – which is simply the rate times the number of days in a release cycle (D):
C = r * D
As such, a release volume can be verified if it is equal to or less than our capacity:V <= r * DIf the volume of software released is greater than the capacity to verify it, quality and ability to deliver new features is at risk. Now if all this math stuff is too much, consider this visual metaphor:
This is a common experience in our industry. This unverified software pouring over the funnel is the risk of regressions and new defects making their way to production. While the quality implication is clear – consider also that critical late-found defects also have the ability to delay or cancel a release, and that even if we tolerate some quality issues (which we shouldn’t) the funnel is only so large.
Volume can be misleading at first – I’m not advocating slower release of new features. I’m advocating better focus on regression exposure and improving our ability to reason about what has changed.
Large monolithic codebases make it extremely difficult to reason about what has changed (and therefore what needs to be regression tested) in a given release. If one line of code in this monolith has changed, the whole thing has changed and must be built, deployed and verified.
A large portion of the volume isn't exposed to regression, but reasoning about what part(s) changed is impossible. We need the apparent volume we introduce in the release cycle to be closer to the actual volume we need to verify.
Rate
Rate in our industry has largely been a function of manual testing and headcount. Manual testing does not impact efficiency, and we’ve outstripped the ability of manual testing to keep up. Rate improvements must focus on improving the efficiency of the Dev-Release - QA process. Things like automation and practices that promote early detection of defects (CI, unit tests, automated functional tests, etc).
In as much as a practice, tool, investment, or automation reduces Volume to actual Volume or improves Rate efficiency, it improves delivery efficiency. Options that don’t impact Volume or Rate in this way don’t help us and are a waste of time. We need to be asking ourselves how our efforts improve our collective ability to reason about change (Volume) and make verification more efficient (Rate) and focus our investment on these things.
Free Energy at 7th St. Entry March 3rd - Are You With Me or Against Me?
Free Energy this wednesday - man they are so good. And the entry is a classic music hole. My favorite for sentimental reasons. I'm going if I have to walk there naked. Interested in meeting up? You can wear clothes.
Writers on writing
http://www.guardian.co.uk/books/2010/feb/20/ten-rules-for-writing-fiction-part-one
Good writers write well - especially in this short form about writing.
Don't miss Geoff Dyer's tips - writing as lavatorial activity...
Why Tumblr is kicking Posterous’s ass « PEG on Tech
Overblown (NY = Design, Silicon Valley = Engineering - that's why?) - but an interesting point on simplicity of design - and streamlining usage to the essentials. Tumblr on the surface looks a little easier in this regard. Very happy using Posterous, but maybe I'll cross-post to tumbler for awhile to compare...
