Experienced delivery folks can have surprisingly good instincts for macro-level estimation, as long as we are careful to manage blind spots and cognitive biases. This can be an important tool in early project investment discussions, and can remove roadblocks where people are uncomfortable or unwilling to provide estimates.
The goal of software delivery is to minimize the lead time to business impact. Everything else is detail.
At the end of 2009 I left the world of agile delivery and consulting to join a small team in a trading firm. I was member number three. The team grew to five in the next few weeks. This team was the most insanely effective delivery machine I’ve ever been a part of. A handful of programmers sitting in amongst a handful of traders, producing state-of-the-art trading systems—with all the integration pain (back office, risk management, connecting to electronic exchanges) that involves—in weeks. Not months, weeks. This is, of course, impossible.
I am delighted to announce my new independent consulting company, Dan North & Associates, which has the handy abbreviation of DNA. Take a look around the new website - I’d love to hear your feedback and suggestions, especially in terms of the direction I’m taking. Going independent has been on the cards for a while now, and the timing feels right after successfully carrying out a Lean transformation programme with my current employer, DRW Trading.
I’ve just come back from the excellent NDC 2012 event in Oslo, where they published my article about opportunity cost in The Developer magazine ahead of the conference.
Watch the magician. Watch how he drops a coin into his hand, closes his hand, shows you the closed hand, opens it with a flourish, and the coin is gone! He smiles. You look to his other hand. He turns it over and opens it with the same flourish. Not there either! Then he takes your hand, closes it into a fist, opens it and there is the coin!
I’ve noticed a number of people recently declaring that BDD really is just TDD, such as Robert Martin on Twitter and Ron Jeffries on the XP list. I can understand where this mindset comes from and I’d like to offer my perspective.
I’ve been using JavaScript for a while now, but only really programming in anger with it during the last year. I’ve found it in turns frustrating and enlightening, ridiculous and brilliant. I have never felt so empowered by a language and its ecosystem, so I thought I’d take some time to write about why that is. I’m starting with a ramble through the history of JavaScript, or rather my undoubtedly inaccurate understanding of it, to provide some context for where and how I’ve been using it.
It’s November, and it seems I haven’t posted anything here since January. Partly that’s because I have a Proper Job™ these days, which means I spend a lot less time writing and blogging. Partly I’ve rediscovered the joy of actually programming, which means I get to spend most of my time hacking on code.
The brittleness of tests or specs is a recurring topic in BDD (or acceptance test-driven development, specification-by-example, or whatever you choose to call the thing where you write acceptance criteria, automate them and then make the application match). This is a tricky area, and there are probably as many styles of defining and grouping acceptance criteria as there are teams automating them.
The aspect I want to focus on in this article is domain language, because there’s a failure mode I encounter surprisingly often, which seems to have a common root cause.