We’ve been using Jasmine BDD’s framework for unit testing our javascript layer. Its been pretty decent for our needs. The documentation is pretty good, but this cheat sheet helped us much more. Just a short blog to ensure I keep a reference to it.
Page 23 of 53
A couple of weeks ago 700 geeky Swedes (and a handful of other Scandinavian people) descended on Gotheburg to attend Scandanvian Deveopers Conference. It was the first year that I went along and enjoyed the experience of this conference.
The two days had plenty of options – with eleven (yes eleven!) parallel tracks including language specific ones (java, .net), mobile, upcoming things, agile methods, web, SOA, etc. Something for everyone for the most part. This invariably brought a whole collection of interesting speakers from plenty of different walks of life. I met plenty of new people and reconnected with many others.
My key takeaways
Just like many of my colleagues, I’m interested in the “what could” be for functional programming. I have my own thoughts on its applicability, relevance and maintainability to my day to day work, however I made myself attend several sessions to see what it was. Neal Ford (great presenter as usual) did a great introductory session to the mindset behind functional programming. I’m glad to see that my studies in this at university meant a lot of it I already understood (first class functions, recursion, etc). I understood, though can’t extrapolate the strength of closures (at least the way that Neal was describing them), and the real world application of currying.
I enjoyed listening to Douglas Crockford talk about the new changes in the upcoming update to the Javascript language. I found him honestly refreshing – talking about which features to avoid (and why) and which things have been added to make users’ lives much easier and still maintain backward compatability. I can’t say that I learned a lot that I could immediately apply but had to laugh at pictures like this:
I also really enjoyed Matthew McCullough’s talk on git that was both insightful and entertaining on the internals, practicals and plenty of live demonstrations using the tool. As a fairly new user to the tool, I learned quite a bit and know more about what I don’t know and can work to fill that gap.
I have to admit the keynotes didn’t really get me thinking any differently, but I think that’s more of a function of having followed Alistair Cockburn’s thoughts for some time and having worked with and understanding change (the topic that Henrik Kniberg talked about).
Here are the links to the two presentations I gave at Scandinavian Developers Conference in Göteborg a couple of weeks ago:
- But what about performance? – A talk about better integrating performance testing into agile software development projects
- Making management work with agile – A talk about the transformation management roles undergo when working in agile environments
Up in the Air represents a great example of what it’s like to be a consultant. It’s a little stark and depressing at times, yet extremely accurate in many places. Optimising workflow matters to quality of life when travelling. There’s nothing worse that being stuck in an airport when there are many other things that you can do. I can highly relate to its main character, describing what it’s like:
“That’s exactly what it is, it’s luggage. You know how much time you lose by checking in? … 35 minutes a flight. I travel 270 days a year. That’s 157 hours. That makes seven days. You willing to throw away an entire week on that?”
There are many other aspects to optimise when you’re looking at travelling like this. One of the things made difficult is digesting large amounts of content, things I would normally need to be connected online for. Here’s how I’ve optimised my workflow.
The iPad Difference
Winning the iPad in a competition we had last year made a huge difference to enabling this. It’s been the biggest enabler to reading content while being disconnected from the Internet. It’s instant on. Instant off. This means I have the opportunity to digest content on the plane while waiting for the plane to taxi, the attendants to complete their safety briefing and turn it off when instructed to do so at the flick of a switch.
ReadItLater (Speedy Digesting)
Last year I tried a couple of applications that downloaded online content for offline digesting. I signed up for the ReadItLater service and been extremely happy with it. As an application it has two modes – one for seeing the original HTML content, and the other that attempts to “smart parse” the core text of a web page, making it easier to digest. Not perfect, but I’m completely satisfied with it.
WIth this application, I send ReadItLater links (I’ll expand on this further) and then sync the application before I leave the house, for it to download all the content for later reading. It has tagging (though I don’t tend to use it as much as I did originally), its fast at rendering content and has some great features for looking at photos for those image-heavy webpages.
The clunkier and definitely less efficient alternative would be to “Save Web Page As” or “Print/Save to PDF”, transferring them to the many available PDF or content readers.
Note: I tried the other popular offline content reader, Instapaper, but ReadItLater has served me well.
Speedy Indexing via Bookmarking & Application Integration
One of the great aspects to ReadItLater is its popular integration with many applications. Initially, I used the browser bookmarking feature in firefox, chrome and safari. This means, when I find interesting links on my laptop that I don’t’ want to read immediately I simply bookmark it for reading it later. I know I’ll digest it pretty quickly on my next trip.
Book marking works okay for the odd article or two, but is a bit clunky when dealing with links from twitter. Clicking through on twitter, opening the browser and then bookmarking is a bit clunky. Particularly on things like mobile devices. Fortunately ReadItLater also have great integration at this level. Holding down on a link in both Echofon (for iPhone) and the native Twitter application on the iPad gives options to send links to ReadItLater. Works great with photo links, web links, etc.
Extreme Speedy Indexing via Application Integration with Shortcut Keys
For about two months, I used this method to read most of my content. Something that was still clunky was sending long, or particularly interesting content from my RSS Reader (Google) for offline reading. Chrome had a couple of plugins as did firefox as well as a couple of Google Reader Lab options to send an article to ReadItLater. Unfortunately most of these options weren’t as simply as a checkbox instead needing to do things like “Click Send To”, “Hover over options”, “Select ReadItLater”. Not particularly smooth.
I recently stumbled across a great RSS Reader for the Mac called Gruml. Best of all, it feels like it’s been designed for keyboard-shortcut obsessed people like myself. It syncs with Google Reader, and then, using the keyboard, I can quickly send articles to ReadItLater, as simple as hitting SHIFT-L. This makes a huge difference when I’m quickly scanning through my reader, using the arrow keys to move up and down different feed groups, articles and then choosing which ones to send. Each keystroke doesn’t block either, letting me move on to the next article to quickly send articles.
Almost five and a half years ago, one my first project in the UK, I built a constrained email tempting engine to be used by marketing folk with a small team of three other developers. I think we worked for about six to eight weeks to develop the entire application, including retrofitting its integrate its output with another system.
A year or two ago, we had some consultants return to the client who talked to one of the original developers who still worked for the same client. They spoke fondly of the good times he had on our team, and spoke proudly about the application we wrote. In the four years or so of constant use (they would revisit their emails at least once a month), the users apparently only ever reported one bug. He mentioned that bug (a special character in the email subject line) was also deprioritised from the original work we did. It was an enough fix and with test around it, was not a problem updating the system.
I certainly appreciated the feedback, particularly since you don’t always get to return to see the long term results of the work you do as a consultant, or even just as a developer.
Some of the great things I learned from that project.
Acceptance Test Driven Development is entirely possible
We worked hard to test drive this Swing based application from the start. It really changed the way that we designed the application and all of us learned a whole heap about understanding testable presentation patterns. It formed the basis of several talks and the knowledge, particularly the separation of concerns is entirely applicable to all sorts of other tools and interfaces such as javascript, or command line interfaces.
On a different note, coverage combining end to end acceptance test and unit tests meant we had 100% code coverage. It was never the goal, but interesting to see on this application it was entirely possible.
Never discourage people from trying new things
The organisation was rife with contractors. Not all of them entirely passionate. I love building great teams and the fact that everyone was learning, and saw things being delivered reignited people’s passions to do various things. I distinctly remember two events made possible by encouraging people to explore their passions and strengths.
One of the developers, interested in the User Experience side asked if he could do some user testing with the application. I can’t remember exactly what I said, but certainly encouraged him to do that. He did, what some people call Guerilla Usability Testing – grabbing someone who didn’t know anything about our application, and giving them a task list to complete as he watched them over the shoulder. Based on this study, we found out, to no surprise, the way we laid out the application didn’t make some of the tasks as easy as they could have been. We channeled this feedback into our interface and helped make life easier for its users.
The other event, a contractor, seemed to find his passion for developing usable software reignited. Everyone will know that swing applications aren’t the nicest things to look at. I remember coming in one morning to find that whole interface reskinned and redeveloped. It looked a whole load better than what you’d get with swing out of the box.
I found out much later that he had, by his own volition, worked a couple of extra hours one night to reskin our interface using JGoodies because he wanted make the interface attractive to users. Awesome stuff that would never have happened without encouragement to do “the right thing”.
Involving real users
As a systems thinker, I know that the purpose of the project should have been an intermediate step towards a bigger change. The real problem was that the organisation was a missing feedback loop from IT back into marketing. I knew that then, and I know that know, however being pragmatic and realistic, you can only do good things within your own sphere of influence. Trying to change how the entire marketing and IT department silos worked (or failed to work together) would take much more than the two or three months I was going to be there.
Fortunately, we had one person on our project who had worked for their company for a while and had a couple of good contacts in marketing. Whilst we couldn’t change the way projects spun up, we managed to get someone who was going to use our software down, early, and show them what we were building for them. More than that, they asked for somethings (that we could almost immediately turn around for them) and they were blown away that their feedback actually mattered and made a difference.
Conclusion
I appreciate good projects, and where possible, create those environments for others to thrive in. There are many good things to carry forward in these things and can only hope others benefit from it as well.
Last year, I worked on an inception trying to work out how big a three way product merge and rebuild would take. The business wanted to know what they could have by the start of summer this year.
During this intense four week inception we identified a huge number of stories – way more than I had ever identified in previous inceptions. Almost 500 storie by the end. I can’t recommend anyone going through this experience though we had drivers which meant we couldn’t avoid it this time.
My previous experience and gut feel tells me 100-ish stories (when I’m working with people to break it down) is probably enough work for a small dev team (3 dev pairs) for about 3 months. This was definitely a whopping year long programme of work (if done right).
We also had a lot of pressure to estimate them all. Up front. Obviously, attempting to estimate a year’s worth of work accurately is going to be pretty inaccurate. The longer the piece of work, the more assumptions will change, the more estimates made on those assumptions will be wrong. I know. However people still wanted numbers to understand how large this programme of work would be.
Some statistics
We ran incremental estimation sessions using relative story sizing, following fibonacci planning poker and estimating in points. Our maximum point size was 8 points. 5 was generally the highest though we tended to have 1 in 30 cards about this size.
We even iterated over a few estimates at random intervals to see if our relative sizing of stories changed significantly.
Interestingly enough, we stored some spreadsheets for various time during out estimation and I’ve pulled out some statistics from them, laid out in the table below:
| Spreadsheet Version | # Stories Identified | # Stories Estimated | Total Estimates in Points | Average Point / story |
|---|---|---|---|---|
| 0.22 | 135 | 129 | 340 | 2.63 |
| 0.26 | 529 | 395 | 1037 | 2.62 |
| 0.30 | 494 | 488 | 1346 | 2.75 |
What can we learn this from?
Firstly, one can see that the average story size isn’t significantly different over this large spread of stories. One could argue that given the dataset, it could be enough to extrapolate further estimates.
The next thing to consider is why do the numbers tend to average out? One could argue the story breakdown process for this project, leads to stories of the same size. It would be dangerous to assume all projects have similar story breakdown process.
Alternatively one could argue that the estimation process helped us breakdown stories to be approximately the same size. Nevertheless, an interesting observation and one I’ll continue to explore.
I’ve been in the fortunate position of building up a small team since the start of the year. It’s the first “official” tech lead role I’ve had for a couple of years and I’m proud to say that we have a pretty rockin’ team. Blending and appreciating lean ideas into how we work mean that we’re in a pretty good position all around.
Building what matters
The project work for this client meant tight deadlines. For once, it’s not just because the detached marketing arm committed to some random date without asking about how likely it would be. This one was based on pure legal compliance by a certain date. Although arguably arbitrary, it certainly has some merit (e.g. if we don’t do this, we simply cannot operate business in this country). All my UX buddies will be proud, championing the end user and what is it that need to be able to meet compliance. This neatly fits in with the systems thinking point of view – rather than building what we think we need, talking to people who actually did similar jobs and finding out what their problems and way of thinking was. We drilled out some personas, worked out some user stories, attempting as best to map them out.
Building strong teams
Teams are forged around a common purpose. Not because they simply sit in the same room. Calling a group of people a team does nothing to change they are, in fact, just a group of people. Although it took a while for the entire team to settle into shape (we had one join in here or there), we tried building a Team Charter to help understand what it is we valued in each other, and what our expectations were of each other. We took time to make clear roles, responsibilities, and who most people expected to fulfill those responsibilities, remembering that roles do not map 1:1 to people.
I think it’s helped that everyone comes from such diverse backgrounds. We have two British people, one German, one Polish, one Indian, one Pakistani and myself, the Australian. It’s useful to find common interests and cultural interchange as another team building exercise.
Preventing impediments and swarming around those that appear
Risk mitigation and issue management isn’t about simply identifying them in some spreadsheet and leaving them away. Instead, it’s about the rigourous act of trying to prevent them from happening as early as possible and dealing with them. We knew pretty early that the development time to meet this criteria would be tight, so we focused on ensuring as smooth a flow of work through the cycle. I won’t admit that we used kanban without explicit work-in-progress limits, however this doesn’t mean that we didn’t apply the Theory of Constraints. We choose development (coding) as our bottleneck, creating tools to optimise testing, and ensuring minimal rework by being thorough in putting work ready to be picked up. Me (as tech lead), our QA, and BA would sit down to tackle features from different angles and building consensus with our Product Manager. As a result, I can’t think of many stories where we discovered information too late, or ended up with large amount of rework. I hope that everyone else has appreciated the flow.
Two weeks away and things still ran fine
It’s a strong test that I always ask people in leadership positions. How would you feel if you couldn’t talk to your team/organisation for a day? For a week? For two weeks? With a properly built team/organisation people should be capable of working out problems without you. I would worry about not just the signal, but what it says about your leadership style, if teams could not last without you. Fortunately one week of skiing and another week for a conference and I came back to a team happily churning along (although there was one event early on that seemed to knock the team’s confidence).
Retrospecting on the Retrospectives
Strangely enough, we’ve only run about two or three proper retrospectives. The first time, our QA remarked on how this had been their first session where the Went Well’s far out numbered the Less Well’s. For the other one, the only things that came up in the Less Well’s were organisational things we knew about, and had either actions pending for or were things we realistically weren’t going to be able to change.
Experimenting
I strongly believe most organisations waste human talent, passion and energy when you can’t create a good environment for them. I feel like we’ve done a pretty good job. We finished development complete of our critical legal requirements two weeks early with one developer less than originally planned and nearly through the next “nice-to-have” tranche of work.
I believe most teams would benefit the most by removing impediments, and creating flow. Unfortunately I don’t think most teams get there. However, once you are there, I believe the next best thing you can do is to experiment and trial new things. I’m trying to encourage our PM to let go of estimation and working out how to encourage just the right level of experimentation.
Last week I finished another talk, “The Beginner’s Mind” for QCon London in the Software Craftsmanship track hosted by Kevlin Henney. The track focused on the craftsmanship aspect, not what the term “Software Craftsmanship” was or whether or not people should do it.
I hung around the track all day, and enjoyed the well researched talk given by Glenn Vanderburg, the entertaining video and talks by Jon Jagger and the good advice Roy Osherove had on team leads. My talk focused on understanding the paradox that comes from developing expertise as you learn and how to go about avoiding the situation where you end up reducing the amount you learn.
I had some great feedback from some of the participants, many nodding heads and I hope that people go away more aware of what is happenning as they learn and specific examples on how to keep the state of The Beginner’s Mind open. Slides from the session are available here.
Although clipart has a bit of a bad reputation with the Office suite of products, I used to use them a lot and decompose them into reusable shapes. Keynote doesn’t have as much of these prepared, and you’re often forced to resort to lossy formats such as GIF or JPG. Fortunately I found that a cool tool called svg2Key that converts SVGs as made available by OpenClipart to a format that is Keynote friendly.
Updated: 10 September 2012
It looks like the svg2key tool doesn’t work on Mac lion. The alternative I found was another tool made available called svg2keynote
Working for a client in Berlin, I find the plane time where I normally catch up on some reading. Services like Read It Later make bookmarking online pages for offline reading a pleasure. This morning’s trip, I finished reading a book Michael Feathers tweeted about that. Titled, “Object-oriented software metrics”, and published 15 years ago I found this book most easily from a online second hand book store, and have to say I enjoyed many aspects to this book.
Wondering how much interest a metrics book could be, the author did well to keep the short book punchy and brief. I enjoyed the conversational style of the writing, and the pragmatic nature of his recommendations, such as “I put the threshold at zero so that we explicitly consider any violations.” He starts the book describing metrics and that they should be used for a real purpose, not just randomly corrected, and something I’m pleased resonates very well with a chapter I’m contributing to a book. It’s obvious he comes from applying metrics with real purpose in the real world, talking about examples where various metrics might be used to drive various design choices, or further investigation.
The author divides the metrics into two sections, the first focusing on metrics related to estimating and sizing, or project planning. The second set focuses on design metrics related to code. The metrics that emphasise estimation piqued my interest as a reflection on how estimation methods used to be run, or maybe in some places still are run such as Developer Days per Line of Code, or his suggestion on Developer Days per Public Responsibility. I think the second set proved more relevant to me.
The author shares some of his preferred metrics thresholds and, they too, resonate strongly with my own views of size of methods, number of instance variables in classes, etc. In fact, I’d almost say they were definitely much more extreme such as 6 message sends per method, with my preferred number between 5-10 depending on the team I’m working with. Part of this, something that the author emphasises, is also heavily influenced by the programming language of choice.
Few of the metrics talked about were new to me, having made use of tools like Checkstyle and PMD, although I found he used several I’ve not really tracked such as number of classes thrown away, number of times a class is reused and the number of times a class is touched, something I’d like to ponder on a lot more. One metric I’ve also never considered collecting or tracking is number of problems or errors reported by class/module though I suspect the overhead in tracking this may outweigh the benefit it brings because it’s much harder to automate this.
His emphasis on the influencing factors on code metrics also got me reflecting on my own experiences, once again strongly resonating with my own experiences. His mentioning of key classes resonate with the domain model described in Eric Evans’ Domain Driven Design. I would also anecdotally agree that the type of UI heavily influences the number of supporting classes with technical interfaces (i.e. APIs) requiring less classes than rich GUIs. I like a lot of the distribution graphs he uses and will definitely consider using these in the future.
I’d highly recommend this book if you’ve never really sat down and thought about using code metrics on your projects. It’s got me thinking about a number of other interesting side projects about visualisation and further feedback loops on projects.
Recent Comments