Monthly Archives: August 2011

Programming

I need feedback not features

“How about LDAP? Or a configurable workflow?” opines the new salesman. “I think it would really help the product if it had help videos” chirrups the new intern.

All interesting ideas I’m sure and some of them might be relevant in the future, but to be honest I didn’t really need a lover here I just needed a friend.

A lot of people seem to confuse feedback with the opportunity to point out the depressingly long list of things that an application doesn’t have, doesn’t have completely or just doesn’t do. As a developer it often feels that there is a never-ending queue of people ready to point out that the kettle washes clothes really badly.

Offering new features is actually a substitute for genuine feedback, which for me is discussing what the application does do on its own merits. In particular one thing that people never seem to be good at is to point out how existing features can be leveraged in multiple contexts or in different ways to maximise their benefit. Charles Vasey, a boardgame designer is amazing at doing this kind of refinement and a big inspiration here. Instead I seem to be left to sweat the codebase on my own while people boot more and more stuff into the backlog (blithely ignoring their own self-defeating behaviour).

A natural instinct (and one I’ve been succumbing to recently) is just to ignore everything everyone says unless it is a bug report. One particularly strong point in favour of doing this is that since I have a backlist that goes into October why not wait until that is clear and then gather feedback? I too already have a massive list of features I wish I could add but have discounted on their lack of value, surely I would be better off implementing them first instead of soliciting feedback on something that is incomplete.

However realistically, retreating into the Ivory Tower is rarely the best option. But how can we move from features to feedback? I think perhaps the first step is to call out the behaviour and just park each new feature onto a Post-It and then re-iterate the need for feedback. The other idea is make people explicitly say what they like and then why they like it. Forcing to people to focus on the positive and make them express their response in terms of what they want to see more of rather than what they would like to see.

Standard
Java

Delta versus Chain

There are already two styles of persistence code in my daily work codebase. The first is based on the concept of generating the delta of the change you want to make. The second is the construction of the new data map by chaining functions together.

Let’s take some examples:

delta = { 'when' : now(), 'comment' : 'Hulk smash!', 'tags' : tags.append(new_tags) }
comment.update(delta)
store.save(comment)

store.save(update_timestamp(comment(update_tags(new_tags), 'Hulk smash!)))

Hopefully you can already see some of the pros and cons about both approaches. The chaining (or trainwreck style) ends up being very short and powerful. However when you need to pass in a few parameters at different points in the chain it can get very complicated to read.

The delta pattern allows you to accumulate changes into the delta neatly and to combine several changes (data, timestamps, audit entries) into one atomic write that is, in my view, easier to read than the chained example. However the boilerplate doesn’t go away and starts to get irritating after a while.

These are Python examples because in Clojure the threading macros and argument lists take away my comprehension concerns.

At the moment I’m continuing to experiment with both strategies and looking for a way to incorporate the best elements of both the comprehension of the delta and the conciseness of chaining.

Standard