Scotch on the Rocks 2011 (Day 1 AM)
The Scotch on the Rocks 2011 ColdFusion conference was held at the Apex International Hotel in Edinburgh on the 3rd and 4th March, and this year I was able to attend the whole event (having gone for just the first day in 2010). Some notes from the sessions I attended follow below, and will continue in future posts. The notes are not exhaustive, but hopefully cover the main points of the sessions, and anything else I considered interesting.
Session1: Adobe Keynote
(Terry Ryan and Adam Lehman, Adobe)
Terry started the keynote with a look back to five years ago and the launch of ColdFusion MX 7 and talked about how web development has changed since then (“What’s a mobile version?”). He highlighted how more effort must now be expended on UI development compared the backend to meet the needs of multiple platforms, and told us that Adobe would like to make this easier for us.
He then moved on to the changes in management at ColdFusion; the CF engineering team have been based in India for a while now, but product management will now also be based there. If you follow the developments in the CF community, you will have seen some of the discussion that followed after Adam Lehman announced this change on his blog a few weeks ago. As you would expect, the message from Adobe is that this is a positive change, and Terry pointed out that the director of products in the new business unit is the highest ranking staff member at Adobe ever to have responsibility for CF.
Next, Terry highlighted a couple of community-related developments – localized community blogs, an upcoming version of the coldfusionbox AIR app for Android and an application catalogue.
Moving onto ColdFusion Builder 2 (codenamed “Storm”), Terry described and demonstrated a few of the new features, including code folding, keyboard shortcuts, user-configurable code formatter (put the curly brackets where you want them) and code assist. ColdFusion Builder 2 is available in public beta as of this Keynote.
Accompanying the beta release of Builder 2, a new public bug tracker has been introduced at bugbase.adobe.com. This currently covers CF Builder and Bugbase itself but will be extended to include all Adobe products.
Adam Lehman next gave us a brief history of ColdFusion from the “Golden Age” of CF4 and 5, through the Silver age (the migration to Java and versions 6, 7 and 8) to the Modern age (CF9 and beyond). Adobe apparently have a roadmap for 3 versions ahead from CF9.
Adam shared some detail about ColdFusion X (Codenamed “Link”, and pronounced as “Ex” not “Ten”). Highlights include:
- Designed as a modern platform, removing baggage (Flash forms were mentioned here)
- Verity removed in favour of Solr
- JRun removed in favour of Tomcat – Expect speed and scalability improvements
- Apache Axis 2 for web services. Axis 1 likely to be dropped in CF 11 (or is that XI?)
- Exchange 2010 support
- Scheduled Task improvements (more granular controls, chaining, conditional execution)
- Jobs (basically one-off scheduled tasks defined programmatically and executed from a queue)
- Dynamic Java class loading (Java → CFC)
- Dynamic Java Proxies (CFC → Java)
- CFML closures
Session 2: Requirements and Estimating
Starting with a comment that something like 70% of the average application is never used, Peter gave a fairly fast-paced run through of the intent-driven design process he recommends for requirements gathering. The following aspects should be considered:
- business intent – what is the benefit of the application to the organisation
- audiences – who is going to use the app? Best defined by role.
- objectives – why will the audience be using the app?
- tasks – what specific tasks do they need to accomplish to achieve their objectives?
For each user story we’re looking to identify “As WHO, I want WHAT so that WHY”. User Stories need to meet the INVEST principles:
- Independent – Easier to split for resource allocation/juggling
- Negotiable – User stories are not set in stone, they start a conversation
- Valuable
- Estimatable – Small and discreet enough to estimate.
- Small – Longer than a week, estimates gets much less accurate. Break it down.
- Testable – What are the acceptance criteria?
Moving on to estimation, Peter noted that while there are good reasons for estimating (eg to give a go/no go decision based on cost), there are also reasons not to bother (eg if the task has to be done anyway, it might be better to just get on with it than to waste time working out how long it will take). When estimating, we need to consider whether we are estimating time, price or both and the level of accuracy required. We also need to factor in the difference between ideal days (no distractions) and the real world using a “load factor”
Having broken requirements down into user stories, Peter outlined a couple of techniques for turning these into estimates, namely Planning Poker and Magic (or Affinity) Estimation.
He also highlighted four classes of feature that might be required, each introducing uncertainty on a sliding scale to the estimating process:
- Rocket Science (no-one has ever done it before)
- Lab Experiment
- New to you
- with a twist (you did a similar one last week)
In order to manage expectations, it’s important to be clear that you are going to deliver something that meets the specification rather than something that will make the customer happy. If they are not happy with that, why not? What is missing from the spec?
Summing up, Peter stressed that it’s important to be clear that an estimate is just that, not a commitment to deliver. In order to reconcile the two, it’s important to build in flexibility. How this can be achieved will depend on whether the project is of fixed duration, or fixed price. Buffers can include optional features, team size and scheduling flexibility. Remember the Iron Triangle: scope, cost, time. Something has to give.
Session 3: Trust, Communication, Honesty: Pick Two
The least technical presentation that I attended this year focussed on the human side of workflow and team interaction, emphasizing that workflow should be more about the flow than the work. Since there’s no book or methodology that can teach you how to deal with relationships, Chris provided pointers drawn from his own personal experience in managing teams.
He described how we often fail to see issues affecting others that can influence their behaviour, concentrating instead on our own problems, and how we usually see the problems in a relationship as the other party’s fault. He then posed a few thought-provoking questions (How well do you really know the people on your team? When was the last time you spent time with them outside of work? Do you really want to hear anything other than “fine” when you ask how they are?), and offered a few tips on making teams work including:
- Read about different workflow methodologies, but don’t follow them slavishly
- Trust your team to do their best and they will
- Enable self-organisation, but know when to intervene
- Make an effort to actually know the people on your team and spend time together outside the office
- Don’t hire assholes (my personal favourite!)
- Recognize good work, and finally
- Show love
Great write-up.
I’m gutted to have missed Chris Pelsors session, it clashed with a couple of other good ones and I think I ended up watching Matt Gifford (also awesome session)
I appreciate kind people such as yourself taking the time to make notes, I’m far too lazy to do it myself haha.
Robert
Thanks Robert, I’ll be writing up your session in my next batch :)