The rise and rise of JavaScript

December 19, 2011

history, html5, javascript, nodejs, programming, web

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.

Looking back on 2011

November 20, 2011

agile, bdd, effectiveness-patterns, meta, people, programming, talks, thanks, uncertainty

3 Comments

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.

This is something of a catch-up post, bringing you up-to-date with some of the things I”ve been up to and some of the topics I intend to be blogging and writing about.
Read More

Whose domain is it anyway?

January 31, 2011

bdd, brittle, ddd, domain, language, modelling, tests, vocabulary

24 Comments

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.

On craftsmanship

January 15, 2011

agile, craft, craftsmanship, discovery, productivity, programming, software, trade, value

35 Comments

Well, I certainly didn’t expect that kind of interest in my last post. In the past I’ve tended to have a few hundred people reading my infrequent mumblings. In the last few days nearly 20,000 people have popped by according to my site statistics, leaving nearly 150 comments. Crikey!

The overriding message I got was that without providing evidence and concrete examples one way or the other, it was all a lot of noise about terminology. One of my intentions this year is to expand on some of the implications of Deliberate Discovery, which fit the bill nicely in illustrating programming-as-a-trade, so my next article is the start of a series of posts along that vein. I’ll let the evidence speak for itself and you can draw your own conclusions.

I’ve been very grateful for the feedback and comments, and the dialogue on Twitter. I didn’t spend as long as I might have editing and cleaning up the article, largely because I’d been tinkering with it since before Christmas, rewritten it twice, and decided it was better to publish early and respond iteratively to feedback. Typical – go out without your best underwear and you get run over by a bus.

The critical feedback generally fell into the following categories:

How dare you! You obviously know nothing of which you speak. (Well, you decide)
You obviously don’t / have never / no longer code / care about programming. (Not true)
You’re using a pretty crappy definition of “craft” to put forward a bogus argument. Here’s mine / Wikipedia’s / my dad’s / a selective entry from a dictionary’s. (That’s not the point)
You shouldn’t/can’t compare programming to building / plumbing / fine art / martial arts. (See “On metaphors” below)
I’m angry and important so I’m just going to poke you with a stick rather than do any actual thinking. (Meh)
Where’s your evidence? I say “craft,” you say “trade,” show me evidence it’s a trade. (My next few posts)

It seems this is a sensitive subject area so I’ll be editing more carefully from now on to try to pre-empt some of the more obvious critiques I left myself open to in the previous post.

Programming is not a craft

January 11, 2011

agile, craft, craftsmanship, discovery, productivity, programming, software, trade, value

243 Comments

TL;DR

Software Craftsmanship risks putting the software at the centre rather than the benefit the software is supposed to deliver, mostly because we are romantics with big egos. Programming is about automating work like crunching data, processing and presenting information, or controlling and automating machines.

Non-programmers don’t care about the aesthetics of software in the same way non-plumbers don’t care about the aesthetics of plumbing – they just want their information in the right place or their hot water to work. (Although it’s fair to say they appreciate decent boiler controls.)

Introducing Deliberate Discovery

August 30, 2010

agile, discovery, learning, planning, programming, software

62 Comments

Last year I wrote about how we are doing planning all wrong, or rather, how we seem to focus on the wrong things when we do planning. We obsess about stories and story points and estimation, because that’s what we’ve been taught to do. It reminds me of the story about a man who comes across a drunk standing under a street lamp at night time, staring at the floor. The drunk says he’s looking for his lost keys, and the man says: well they are obviously not here under the lamp or we would see them. No, replies the drunk, I dropped them over there, but it’s dark over there so I decided to search over here instead.

Our street lamp is the Planning Game, which involves writing Stories and Estimating, using Planning Poker or other Estimation Techniques (everything in caps appears in the Agile Literature, and so has been deemed Official).

I suggested we are failing to use the planning time effectively, and that we should be devoting the time to finding out as much useful stuff as we can while everyone was in the same room, and I called this Deliberate Discovery. Marc McNeill commented: “Deliberate discovery. As opposed to accidental discovery? Or any other sort of discovery? Why add the extra word ‘deliberate’?”

Time for a change

February 6, 2010

career

12 Comments

I’ve been in the IT industry for about 20 years now, and for nearly the last 8 years I’ve been a consultant with the rather excellent ThoughtWorks. Being anywhere for that long in our industry is quite uncommon, and to spend that long in a consulting role, with all the travel and disruption that implies, is even moreso. I’ve had a fantastic time with ThoughtWorks and I feel I’ve grown tremendously during the time I was there. Eventually something had to give though, so at the end of last year I decided it was time to try something else.

In particular I found I had moved away from the things I really enjoyed – writing software that matters and building high-performing software teams – more towards big organisational change, which, while it arguably has a bigger impact on an organisation, isn’t really where I wanted to be. So my criteria for what to do next came down to: writing business-critical software in a small, high-performing team, in an organisation that trusts its people and encourages them to excel. Having a great relationship with the consumers of that software and having them closely engaged with its delivery would be a huge plus.

Luckily for me such organisations do exist. One of them is a proprietary trading firm (basically a bunch of partners trading their own money) called DRW Trading, and it works a bit like this: The partners want to trade, so they have traders. In order to trade well the traders need to work with good financial models, so they have analysts who build those models. In order to trade effectively with these models they need good software, so they have programmers who build the software. That’s about it. The software development value stream is something like:

- I’ve had an idea for something that will make money. - Ok, here’s some software. - Thanks.

The procurement process seems equally onerous:

- I need a Thing. - You should get it then.

So there you have it. I’m taking a break from consulting, at least for a while, in order to rediscover good old-fashioned software delivery. I’m going to be doing a lot less on the conference circuit, although I don’t intend to vanish altogether, and hopefully I’ll be blogging and writing more now I’m doing less travelling and feeling less exhausted all the time.

Obviously I no longer have a ThoughtWorks email address, but you can contact me at dan@dannorth.net or I’m occasionally on Twitter as @tastapod. We now return you to your regular scheduled programme.

The lady in the taxi – a parable of metrics

November 12, 2009

agile, lean, metrics, stories, throughput

11 Comments

Once upon a time there was a lady in a taxi. It took such a long time for the lady to get to her destination in the taxi that she went to the town hall and told the man from the council. The man from the council wanted to figure out why the taxi journey was so slow, so he placed cameras at all the traffic lights in the town to measure how many cars went past, and how quickly. The traffic light cameras would click every time a car went past the lights.

He wanted to speed up the rate of cars, so he changed the layout of the town. He figured if he introduced a one-way system the traffic flow would be more efficient. This confused the taxi drivers and they started to get lost. The taxi driver would go past a light, click, discover he couldn’t go the way he wanted, try to find a way through and find himself going back past the same light, click, realise he had been this way before, turned around and drive back through the light, click, and would still not find his way to the lady’s destination. The new one-way system was good at moving cars around – it just wasn’t very easy to navigate. And just as the taxi drivers were learning the new layout, the man from the council would try a new layout just in case.

What a lot of clicking, thought the man from the council, and what a lot of cars must be driving through my town. How efficient this is! I shall invite more cars into this town because it is so efficient at moving cars around.

New translations

October 12, 2009

agile, bdd, programming, translations

1 Comment

I currently have a backlog of about 15 blog articles I am failing to finish. The most embarrassingly laggy one dates from around the end of 2007. Now I know I’m a slacker.

However, others have been far more industrious than me.

What’s in a Story in Japanese and Introducing BDD in Korean

The industrious Yukei Wachi has followed up his translation of my Introducing BDD article by producing a Japanese version of What’s in a Story.

Inspired by Yukei’s translation, a Korean developer HongJoo Lee has written a Korean translation of Introducing BDD. How cool is that?

Enormous thanks to you both for your hard work.

Update: HongJoo has also translated What’s in a Story? into Korean.

Introducing BDD in Japanese

August 24, 2009

agile, bdd, japanese, translations

1 Comment

I am delighted to announce the official Japanese translation of Introducing BDD.

It’s easy to forget how big the Internet is and how small the world can be. Last year I gave a BDD talk at QCon in San Francisco that made its way onto InfoQ.

A Japanese programmer called Yukei Wachi watched it and decided he wanted to know more about BDD. He read my Introducing BDD article and felt it was worth translating into Japanese. He then translated several thousand words in what seemed like no time at all.

Yukei asked me for a couple of sentences to introduce the Japanese translation, and then with typical Japanese modesty decided to drop the part where I thank him. So here is the introduction again with the first sentence intact.

I am thankful to Yukei Wachi for translating this article from English for you, and I am grateful to you for your interest in Behaviour-Driven Development. I hope you find this article useful, and that you enjoy your journey into BDD as much as I have.

Thanks Yukei.

—DanNorth.net

embracing uncertainty