A nice analysis of the effect of detail choices on overall usability (of cat feeders in this case) from Jeff Atwood.
As some of you may know, I have a soft spot for games – tabletop games rather than computer games, mostly. One of my all time favourites is Car Wars from Steve Jackson Games. Originally from the 1980 it hit the sweet spot of being both a fun battle game with your friends and a geeky challenge trying to come up with the best vehicle designs between games. It’s not a card game, but it beat the “deck building” collectible card game trend by over a decade.
It’s hard to get a good game of Car Wars these days. The most recent version, from 2002, had a lot of problems and was never fully supported, which turned off a lot of players. Happily, there may be light at the end of the tunnel for Car Wars fams.
Following the astonishing success of Steve Jackson’s crowd-funding of the “big box” revival of his classic game OGRE, Steve is considering working on a new version of Car Wars. If you join the OGRE kickstarter program to the tune of $23 (USA) or $30 (rest of the world) you can help us send a clear message that we want a Car Wars revival and a decent new version. Plus, you get an exclusive T-shirt that says so.
Read more at:
But hurry, there’s only a few days left!
Full disclosure. I am part of an unpaid team of keen game playing volunteers (“The Men in Black”) who go to conventions, clubs and stores to play and teach Steve Jackson games, but I also play a lot of other stuff too.
Following a recommendation from Jon Woods, I just checked out Decisions, Decisions, a recorded QCon presentation. Well worth watching, and thinking about, and putting into practice.
I don’t want to spoil it, as he has a fun, interactive, style of presentation, but if you have any experience in software development you will get his point very quickly, and it might just change some of the opinions you didn’t even know you had.
I just ran into a fascinating presentation giving a whole new way of thinking about software development, and careers in general. It also includes some eye-opening software demos.
Watching this video felt a lot like one of the better TED talks. Although it is a bit longer than typical TED talks, it is well worth watching all the way though.
Continuous Integration is a great idea, and usually pretty simple to implement for simple projects. However, these simple projects don’t really exercise the “integration” aspect of the idea. As he build and test process for a project grows in complexity, it almost always grows in duration, too. Typical enterprise Java projects, for example, might fetch dependencies from maven repositories, compile several code modules, copy, move and transform various resources, run unit tests, assemble and deploy jar files, start servers and run integration tests, and so on. All of this can take quite a while, even on a fast build server.
(cartoon from the great xkcd)
One big problem with growing build times, is the effect it has on feedback. If a developer has to wait 10, 20, 30 minutes or more for a build cycle to complete before test results are available, it usually leads to one of three outcomes:
- Every small change requires a concentration-breaking delay to see if it works before moving on to the next change. Development slows to a crawl, management cracks the whip and tries to ban casual web surfing, private email and facebook.
- developers give up waiting for the CI results and press on with development anyway. The code base fills with bugs and issues. The CI process becomes largely irrelevant, as builds are almost always broken.
- Developers hold off from checking in small code changes for fear of having to sit and wait for CI to catch up. As check-in size increases, so does the frequency of code clashes and the difficulty of merging different strands of work. Team culture shifts from collective ownership to silos and hoarding.
What’s needed is a way to get fast feedback, even when a full build takes a long time. Almost every team I have worked with in recent years has tried to achieve this, usually using the open source “Jenkins” (or its fork-parent “Hudson“) build server. So far this has never quite worked.
The main problem seems to be the monolithic nature of a Jenkins build. A build runs to completion (or to a fatal failure), accumulating build data and test results. Data and results are only available at the end. A more useful approach might be if build data and test results were made available as soon as possible, even while further build activity continues. Better still would be a way of adapting the build process to emphasise early feedback, preferring build steps which give feedback to those which are merely useful for further processing. That way a trivial compilation error or test failure in a stand-alone part of the code might give almost immediate feedback. This is not only useful because of the speed of feedback, but because of the effect it has on development habits. Faster feedback would come from code with less coupling and fewer dependencies – any developer wishing to progress more quickly would be automatically encouraged to write (or refactor towards) small, loosely-coupled, independent, well unit-tested, re-usable code.
Although I’m tempted to think that this kind of really effective continuous integration would best be based on different build software, there are a lot of people working to improve things with Jenkins. A recent blog post from “Antagonistic Pleiotropy“: Implementing a real build pipeline with Jenkins. looks interesting, but shows just how tricky even a relatively straightforward build pipeline can be to configure.
Has anyone got any better suggestions on how to achieve effective feedback while building complex systems?
I can honestly say that I was astonished by this. A continual, unrelenting, stream of rhythm and rhyme for over two minutes which weaves in and out of a fantasy scenario of mockingbirds as recording devices while making references to a slew of TED talks from the same conference.
Of all the talks I have watched so far, this is the only one I want to watch again, straight away. I can’t offer higher praise than that.
Definitely back to the kind of talk which TED is famous for: Ric Elias: 3 things I learned while my plane crashed. Ric gives a razor-sharp view of his near-death experience, and the things he took from it. They are the same kinds of things that often occur to people facing their end, but it still feels as if we all need to be reminded. Savour every moment, don’t put things off, there’s no room for negativity, and be the best parent you can..
This was a bit of a surprise. Among all the worthy talks I didn’t realise that there are also comedy routines, songs and other stuff in the TED archive. I found Ze Frank’s stand-up routine pretty funny, although not really as “nerdcore” as it could be be – there is typically more nerd comedy in an episode of “Big Bang Theory”.
In this case reading the comment stream did not seem to add much. Many of the commenters don’t seem to like his humour, and unlike some of the other talks there’s not much development of the ideas in the presentation to be done. Fun, but not thought-provoking.
I’ll admit I am doing a bit of catching up here, having missed a day or two, but I’ll be back on track soon.
For day five I chose VS Ramachandran: The neurons that shaped civilization. This talk introduces the idea of “mirror neurons”, elements of the brain which trigger when observing other people’s behaviour, and goes on to imply that the existence and sophistication of this brain biology is what enabled the spread of human learning and the development of culture. As far as that goes I generally agree. Later in the talk he gets a bit metaphysical, deducing from some mirror neuron behaviour in cases of amputated or anaesthetised limbs that all people are linked.
Today’s talk was another short one, this one about 3.5 minutes. The idea was interesting – a relatively low cost cooling unit that “charges” itself in a cooking fire, then can be used to keep a big drum container cool for 24 hours.
Pitched at storing vaccines away from power, and also preventing food decay and disease it seems to address a need, but (as the comments point out) there are economic and financial issues as well as an apparent lack of progress in the intervening four years. This idea may not be a “go-er” after all. Shame.
Another pretty much random choice of a talk to watch, this one Charles Limb: Building the musical muscle) surprised me because it was not what I expected. From the title I expected something a bit more about the psychology of music or the brain’s perception of music, but what I got was a fairly detailed talk about cochlear implants as an approach to restoring hearing loss.
The main thrust of the talk was to demonstrate that while even the best current implants can greatly improve perception of speech, they fail miserably at all aspects of music – to the extent that many implant users find music co uncomfortable that they prefer not to listen to it.
Overall, I’m sure I learned something about the current state of hearing restoration surgery and its limitations, but this talk was not one which inspired me to think differently.
So, pretty much at random I chose another TED talk video to watch. This time it was John Bohannon: Dance vs. powerpoint, a modest proposal.
I found the talk interesting, thought-provoking, and decidedly tongue-in-cheek (the reference to Swift in the title gives that away). Although the apparent premise (use dancers instead of powerpoint) has many flaws, the underlying theme is fascinating. Hard science and dance are traditionally seen as so far apart as to be completely incompatible, yet here is a presentation which successfully conveys some quite complex physics with no diagrams or equations, just a few well chosen words and some moving bodies.
I am left with echoes of a discussion earlier today on the subject of whether software development can be art. The same sense of unexpected juxtaposition evokes interesting and thoughful perspectives which may lead to innovation. For me, that is the true value of this talk.
The end of November can be a bit of a let-down, though. One way or another the challenge is over.
While discussing this with a colleague recently, we hit on the idea of watching one of the TED talk videos each day in December, and blogging about it. This is a great idea both for learning and for getting back into the practice of reflective blogging.
I have decided to label this challenge “TEDcember”, and I will be using this tag in tweets and blog posts. Feel free to join in!
So, with all that in mind, Steve chose Matt Cutts: Try something new for 30 days as a first talk to watch, and then blogged about it. I was already running a little behind, so (on the premise that it is an appropriate starting point I watched the same one.
Guess what. This is my blog about it.
The talk was obviously motivating. After all I’m sitting here trying something new for 30 days, just as suggested. Two bits of the talk struck me particularly strongly, though. The first was the way that the speaker was happy to admit that his NaNoWriMo novel was rubbish, but that the process of producing it was valuable. This is something which I have found again and again during vlomo. The second stand-out point was the aggregate value of multiple such challenges. It’s so easy to concentrate on one challenge at a time and miss the big picture. The very act of continuing to take on month-long challenges, especially ones which are outside a normal “comfort zone” develops confidence and a sense of worth, even for the challenges which don’t work out.
And that’s the real reason why I felt compelled to roll off Vlomo and into TEDcember. To keep up the momentum of personal development. Let’s see how we get on…
The guys at ebay have released ql.io, which seems to be a way of using SQL-like queries to fetch and join data (typically in the form of JSON, it seems) from multiple web APIs to generate quick “mashups”.
I can’t help thinking that there are a lot of hidden issues around API compatibility and conflicts, as well as the complexity of specifying increasingly tricky business processes, though. All these issues have been encountered in the XML workflow and process modelling world.
This certainly looks an interesting way to get started quickly with quite a broad class of mashup applications, though.
Gojko Adzic is usually good value. Here’s his suggestions and tips for presenters.
Agile software development places a lot of emphasis on prioritisation of work and elimination or deferral of anything which is not needed right now. An obvious advantage of this is that important stuff gets done quickly, but a less obvious disadvantage is that deferred work can pile up like snow before a snowplough. For a long-running project, the effort to keep “pushing” these deferred activities can become a significant task in its own right.
Don’t Live with Broken Windows
Fix bad designs, wrong decisions, and poor code when you see them.
While this is fine as a principle, there will still be times when edge-cases, uncommon modes of operation, laborious work-rounds and generally less valuable aspects of a system should be deferred, even though there is a sense that they will need to be improved later. The question arises of how to best represent and remember these issues so that they are not accidentally lost.
Some development IDEs and other tools incorporate in-code annotations such as TODO or FIXME, and almost every programming language supports comments, where such notes may be paced for more manual processing. These can, however, be tricky to find if you don’t already know where to look, and an apparently obvious note can quickly lose context and usefulness as developers move to focus on other work.
Mark Needham recently wrote of his experiences with a ‘window fixing’ wall.
A project I worked on recently tried a section of a card wall for “issues”, but these languished in a fog of “somebody else’s problem”. We got rid of that and replaced it with a section to collect issues for the next retrospective, but even that has become less used as the project progresses.
Inspiration for a solution might come from another post from mark Needham: “Pain Driven Development.” Although this article emphasises other aspects of agile process, the essence of the idea seems to be that the things that actually get done are the things which cause the most “pain”. Perhaps if we can find a way to convert theoretical “broken windows” and other incomplete work to a sense of “pain”, they will naturally be addressed as part of the normal intuitive prioritisation process.
Has anyone managed this?
It’s a common pattern, an enterprise software solution has a body of code, managed by version control, verified by continuous integration and eventually delivered to some deployment system. If that were the whole picture things would be relatively straightforward. Tests pass? deploy it!
Unfortunately there is often also a database in the mix. This complicates things. Decisions about how many databases to use in the development process, how to ensure that development workspaces, test systems, and live deployments always use an appropriate database, and how to ensure that database changes and code changes don’t break each other occupy an increasing amount of time and energy.
Tom Czarniecki discusses one path through some of these issues. His suggestions do introduce some potential extra complexity in the code, though.
Zero-downtime deployments « No One Is Perfect.
An inspiring video/slide presentation all about how to do innovation. Lots of great ideas, well worth a watch/listen
A business needs to be really careful about extravagant claims, such as a service billed as “files forever” …
Sometimes I can’t resist the urge to grumble to colleagues when confronted with systems developed in a way I would not have chosen. Maybe I just need A change in attitude.
On the other hand, often the frustration comes from knowing that there is a better way, and I’m not sure that learning to love legacy code is that easy.