Initial Prototype

The kids were after a traffic light set up for an intersection on a Lego road. My first idea was to stick some LEDs into a suitable brick. The 4595 brick seemed a reasonable candidate – it looks a bit like a traffic light, even though it only has two holes on each face. I thought of building a basic red/green traffic light, but couldn’t figure how to could control the light effectively – there’s not much room at the bottom of the 4595 to fit four wires and keep the lot from shorting. Then there’s the issue of switching the current from one LED to another as the signal changes. Tricky.

Then I had a wee brain storm: only one LED needs to be on at a time – all I needed to do was to wire the LEDs together so the cathode of one was connected to the anode of the other and vice versa. Because LEDs only allow current to flow in one direction, when the current runs one way only one LED will light up. Reverse the current and the other LED lights up. So simple I felt dumb after working it out.

The basic components: a 4595 brick, a small red LED, a small green LED and some heat shrink to isolate the wires from each other.

Testing: Setting up the LEDs with the anodes around the right way. The wires are bent prior to pushing into the brick (and so I’ll remember which way around they go).

Red means stop: Current is applied to both LEDs, but only the red one can light up.

Green means go: Reverse the direction of the current and the green light comes on, the red light turns off.

The pictures didn’t turn out too well as I took these on a crappy old camera. Time to buy a new one – though cameras get dropped so often in this house they may as well be consumable items.

Getting the wires into place was a pain. The red LED went in OK but the green was awkward as the wires are quite stiff and it’s hard to bend and pull them through without threatening to fracture the LED.

I didn’t bother trying to make sure the anode/cathode pairs of each LED were connecting properly. The green LED was forced in over the top of the red so its two wires were pushed down on the red LED’s wires, ensuring contact.

There’s a small peg inside the 4595 that keeps the wires apart inside the brick. As they come through the hole in the bottom there a danger that the two sets of wires may touch each other so I pushed a small piece of heat shrink up through the hole over just one pair of the wires.

Next Steps

The prototype seems to work OK, so the next steps are to clean up the design. I didn’t really use the heat shrink properly, nor made sure everything was well connected, so I’d look towards improving that.

If I do this again I’d cut the wires right back and solder the LEDs together. I’d solder a flexible pair of coated wires to each side of the LEDs and pull them through the bottom of the brick. I’d probably use an RCX to control the direction of the current. You’d only need one set of wires to control a complete traffic intersection: if you hooked a set of four traffic signals – one for each direction at a cross road – all you’d need to do is run the current one way to turn one flow of traffic ‘green’, reverse the current the turn on the green lights for the other flow. Providing it can supply enough voltage, one RCX should be able to control up to three sets of intersections.

I can see how this could be used for other things. You could easily make a flashing railway crossing signal by wiring two red LEDs in the same way and swapping the direction of the current back and forth. More fun to be had.

Man, I’m devastated: J.G. Ballard dead at 78. I’ve been reading a collection of his short stories lately, and been struck by the originality of his voice – a deep, gut-wrenching deconstruction of modernity. Along with Woolfe and Conrad, one of my all-time favourite authors.

He’ll be missed by many, I am sure.

We had a bit of fun using Lego as an analysis tool a while back – I’ve only just now got round to posting the pics.

When we were trying to kick start the requirements gathering for a project we found it difficult to get everyone on the same page. If we talked about it ideas would fly thick and fast but nothing concrete came out of these sessions.

I decided to use Lego as a means to give the domain model ‘pointability’. Even better, using Lego gave the whole experience a tactile dimension.. you could manipulate the interactions between parts of the application model in a physical way. Plus it was great fun.

Bob (middle) the BA with two of our ‘customers’ – Sam and Davide

This was actually a really good session. Using Lego sort of broke down the walls and allowed people to play with the ideas that had previously been in their heads – or at best on a white board. We pretty well nutted out the entire user model in a few hours, and then had something we could keep a record of.

Roles in the application

The minifigs ended up being used to represent roles in the system, whereas the baseplates represented areas of function. You’ll see little ‘bridges’ between baseplates, indicating where we’d need to build ‘gateway’ interfaces.

This is one small part of the analysis – possibly a third of the baseplates we ended up with. I left the model around for a few days so other people in the office could see what we’d been up to and make their own mods if they wished. It was a very transparent way to do the requirements gathering.

I don’t do this any more, mainly because I became a bit of a selfish prick and took all my toys home. But using Lego to tease out the domain model like this was really handy. I wish we’d done more of it.

Word of warning – and this goes for all analysis models. What we ended up building was very similar to the model laid out in the Lego, formalized of course in more traditional requirements documents. I wished we’d built something simpler.. as I’m fond of saying: if the complexity of your solution is the same order of magnitude as the problem you may as well as well done nothing. If I had my time over again I’d play the same sort of Lego games with the design team (devs + BA), seeing how we could have translated this model into a simpler implementation.

Hey Reader,

The last few posts have been a bit self-serious. “Ruby, Lego™ and other things I dig”? Scrum? Process? Yeah.. I care about those things.. but dig? Maybe.

I want to talk about a much more important issue – one that will affect the grandchildren. I’m talking about the gradual disappearance of old-school Lego Mindstorms resources on the intramaweb.

I don’t have an NXT.. I’d love to have one but as she-who-controls-the-finances says “They are too expensive.. and you’re a grown up!”. Yeah right.. let’s see you say that the next time I buy you some Batman Lego m’lady.. “Oh you shouldn’t have.. take it back to the shop.” I don’t think so.

Anyway, I make do.. and enjoy making do.. with old Lego Mindstorm RCXs, Spybotics and the like. To me it’s what embedded programming is all about: the fun of working with limited resources and still getting stuff done. And there’s always stuff to learn. Lately it’s been getting the Spybotics and Microscout talking via the VLL protocol. I didn’t even now this existed until the kids started badgering me about getting all the programmable bricks talking to each other.

Over the years I’ve built up a list of online resources for the RCX and but am now seeing things start to die away – links no longer work, or pages haven’t been updated for a while. Even old NQC hasn’t had much love lately, all the energy going over the ‘NXC’ port to the Mindstorms NXT. It’s all fair and reasonable – there’s not much action in Commodore-64 land either as technologies that come and go.. well.. come and go. But I love my little RCX and I want to keep on loving it.. even if I am a ‘grown up’.

If anyone out there has old Mindstorms resources they don’t want to host any more – or know of stuff that needs to be preserved – let me know. I’m keen to keep as much of this stuff alive as I can. And if anyone has an old Cybermaster they’re looking to move on.. you know where to find me :)

It looks like NQC hasn’t been built for Mac OS X for a while – the current OS X binary is a couple of revisions past the most recent source. Probably just a GCC 4.0 issue I’m guessing.. well, there’s a weekend project if I ever saw one. When it’s working I’ll post the .dmg up here.

Cheers folks

Dear Reader

I’ve been thinking about where to go with Scrum for a while now. As you may have picked up from my previous post, I’m not entirely happy with how we are using Scrum where I work – though instrumenting the process with elements of CoCoMo is probably a bit too much of the old ‘pendulum swinging the other way’.

I’ve been watching Robert ‘Uncle Bob’ Martin’s presentation at the Chicago ALT.NET group: XP: After 10 years, why are we still talking about it?. It’s long – just shy of an hour if you don’t count the Q&A session – but worth the watch if you have the time. If you don’t I’ll try to catch the salient points for you:

1. for many practitioners ‘agile’ means ‘Scrum’
2. Scrum is a nearly perfect subset of XP
3. Scrum has been successful in helping agile penetrate businesses
4. Scrum made itself palatable to business by removing all the ‘nerdy’ technical stuff from XP
5. the nerdy stuff is actually important and many scrum teams eventually run aground

The ‘nerdy stuff’ is the set of XP practices that Scrum removes in order to become more of a ‘template’ process. Bob’s contention is that by focussing on just delivery of features – and forgetting about the essential craftsmanship of coding – a team slowly builds up architectural crud that ultimately slows them down and makes the team less productive over time.

It’s not hard to prove the efficacy of both Scrum and XP. Google and you’ll find plenty of case studies to proving that either work, at least in the transition from waterfall or ad hoc development. I can’t find anything though on the long-term productivity of teams practicing agile methodologies though, so I’ll have to say – and you can take this as anecdotal evidence – that Bob Green’s presentation resonates.

One of the things I’ve tried to add to our process is the notion of a Technical Backlog – an alternative ‘bucket’ of issues that is meant to be considered at the start of each sprint along with the contents of the Feature Backlog for inclusion in the upcoming iteration. This was intended as a means of dealing with the technical debt that accumulated from focussing too long on just features, but practically speaking never happens because the Feature Backlog gets more weighting than anything else.

The consequence of this is that we have a crufty architecture that becomes increasingly hard to add new features to. Again, Bob’s right on the money here. My inclination is to dig my heels in and refuse to add any more features to the application without addressing technical issues first. Likewise, I feel like treating any bug as an architectural problem and work towards fixing the underlying structure of the application so the same sort of problem can’t surface again.

Bob Martin uses a Boy Scouts saying to model the attitude we should be having to our coding: “Leave the campsite cleaner than how you found it”. I dig this – it makes me think about the craft, about how to treat the coders who will come in after us. It also makes me think about the issue of respect: for ourselves, our code and ultimately our customers.

I find I’m thinking about XP again.. after many years of not thinking about it – having “outgrown it”. It’s quite refreshing – expect more blogs along this line.

In the Software Industrialization blog entry Software Development Gone Insane, Mitch Barnett puts forward the case for CoCoMo, the software COnstructive COst MOdel developed by Barry_Boehm in the 80s.

Mitch’s initial target is ‘Scrumban’, an apparent portmanteau of Scrum and Kanban. Like Mitch I haven’t read Corey Ladas’ book, but I’d have to concur with Mitch that the author’s various articles and blog do smack more than a little of MBA newspeak – though I have more of an issue with Corey’s use of the redundant “Personally, I”. In defense of Corey though, I think he’s try to articulate an important point: that there are existing solutions from other disciplines – in this case manufacturing – that current software processes can benefit from.

Mitch’s other chief contention is that our industry is driven by fashion – and I find it difficult to disagree with him here. I’m still waiting for aspect-oriented programming to take over as I was told it would almost a decade ago – and if someone hits me with another xDD new paradigm I’m likely to stab them in the eye with a fork (for the record, I fully appreciate both TDD and BDD.. though both have had other names in the past). We have to be open to new ideas – and there are many new ideas to contend with – but we also have to be wary of old ideas just being repackaged as new ones.

Sometimes we forget that we stand on the shoulders of giants. If we look at the history of Scrum you can see a lineage tracing back to CoCoMo, via another of Barry Boehm’s significant contributions to software development: namely the Spiral Model, a direct ancestor of the iterative approach to development used in agile methodologies. To dismiss CoCoMo – or indeed any other “old school” model – out of hand is to fail to recognize the fundamental basis that our modern ideas are built on.

Scrum claims to be an empirical methodology, though it should be stressed that ‘empirical’ here is as understood as controlling development ‘through frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs‘. It’s a slightly more ambiguous meaning than ‘empirical’ in the scientific-method sense of the word, but the two notions aren’t that distinct. Essentially we are talking about progress being measured by observable phenomena and not against just a theoretical plan. Scrum also owes a debt to the venerable Plan-Do-Act-Check model of the Deming Cycle, where the results of one cycle and feed into the next as a mechanism driving constant improvement within a project. A ‘sprint’ is an example of the Deming Cycle model applied within Scrum.

Cases where I’ve seen Scrum fail badly is where the process is perceived as a panacea, with no heed is given to the history or foundational ideas underpinning Scrum.

A project I worked on a number of years ago used Scrum as the backbone methodology, with a sort of ad hoc statistical analysis thrown in for good measure. One of the interesting things to come out of the process was the observation that within each iteration something between 25% and 30% of all work that appeared in the Sprint Backlog by the end of the sprint was unscheduled at the start – that is, almost a third of all work executed in the sprint was ‘discovered’ in the course of an iteration. Management were convinced that this previously undiscovered work was an aberration and we would “do better next time”. Such wishful thinking flew in the face of the data we were collecting and denial that there was something inherently wrong with our scheduling. And yet the same thing happened, month after month.

Obviously the team wasn’t following strict Scrum rules, as we were allowing new work to be added during an iteration. Some of this was things the team hadn’t thought of at the start of the sprint, some was stuff that management now deemed suddenly important and worth disrupting the sprint for. The statistical ‘evidence’ we were gathering pointed to a 25-30% cost overrun in each sprint, yet it was being blithely ignored by the business. Instead each subsequent sprint was overloaded like the last, everyone ran around like crazy trying to complete an impossible task, developers burnt out – and no-one spent any time considering why we were consistently running over budget.

An alternative – and one that I tried to get past management – was to budget for 30% ‘undiscovered’ work each sprint. They wouldn’t have a bar of it of course – which I understand. The managers were part-time developers too, susceptible to the same optimistic estimations that many coders are guilty of. Yet here was a clear “empirical truth” that was being denied. We were guilty of treating Scrum as a silver bullet, and not applying the scientific rigour the situation required. In this we did a disservice to both the Scrum process and to our own project. It’s possible that if we’d used something like the CoCoMoII we could have instrumented our implementation of Scrum with tools to manage the project effectively, given us the factors to explore our estimates and progress using statistical analysis.

Sometimes the cost of scientific rigour is difficult to justify in a “it builds, ship it now – they need it urgently” environment. But it’s important to know what you are trading off. Sometimes it’s just a matter of business priorities, sometimes it’s a way to satisfy an innate desire to run wild.

CoCoMo is arguably a scientific approach that could have a place in a lean model of software development. Agile could probably benefit as well, as a means for providing the important feedback loop that methodologies like XP value so highly. For agile methodologies to work they have to have the right mix of practices and processes for the job at hand. My chief concern with CoCoMo is that it assumes the Big Design Up Front model that’s just not appropriate in many projects, where the scope or risks aren’t clearly defined and have to be discovered through an iterative process. That shouldn’t be taken to meaning that CoCoMo can’t be adapted to different projects or processes, nor indeed new uses found for this older technology.

It’s interesting to note that Ohloh ostensibly uses CoCoMo to derive its metrics on open source projects. The estimates on Ohloh often seem way too high – sometimes by an order of magnitude – but as a software developer I’d have to acknowledge the tendency to underestimate how long a project will take anyway. As an investigative tool, CoCoMo may have some merit in examining how much a project should have cost – as a post-implementation tool to uncover inefficiencies in a Scrum project, and as means of benchmarking across projects.

I think that what Mitch is ultimately driving at is that young software developers would do well to look at lessons learned from the past and build upon them. I’m not convinced about the utility of CoCoMo in many of the projects that young programmers will face – the landscape has changed and project management has moved away from the large-scale up-front specifications that made Waterfall the dominant model of development. But maybe one of these young up-and-coming developers will find new ways to use old tools. Perhaps we’ll hear of “Agile CoCoMo” becoming all the rage. And perhaps the old timers we would have become won’t be so jaded as to dismiss it out of hand.

Oh, I’m not one for blogging about blogging, but this made me laugh:

10-reasons-why-php-is-still-better-than-ruby

Ten top reasons why PHP will never darken my door again.

I’ve recently bought myself a wonderful book called Dansk Design, by Thomas Dickson. It covers a lot of the history of Danish design, and not only the immediately recognizable furniture, lighting and other overtly bauhaus-inspired domestic artefacts. It also explores how Viking-era art also informs the Danish aesthetic, building on principles of simplicity, utility and a deep-seated sense of playfulness. The book draws in examples from all over the place, including the Danish landscape, early boat-building, office equipment – even the cover art for late-nineties group Aqua) – to explore Denmark’s place at the forefront of innovative design.

I got suckered in by the references to Lego of course, which made me consider what it is about the design of Lego that appeals. As I’ve said before, I’m not a big fan of much of the “modular” Lego – it seems more to do with movie tie-ins and a constructed approach to play. The kind of play that appeals to me comes from taking a bucket full of bricks and letting your own imagination take hold. I’m quite proud of my kids who – when presented with a new box of Lego (a common occurrence in our house) – will prefer to just muck about with all the new shapes and colours available to them first before getting into what the boxed instructions have to say. Taken to Toy Corner and given the choice of anything from India Jones to Star Wars sets, my youngest opted for a Creator set in order to build “monster robots”. Yay! Kids know how to play – it’s in their nature. I’m not sure why we feel compelled to give them pre-packaged imaginary worlds to play in.

The parallels with Ruby on Rails are readily apparent. RoR gives you a set of patterns, conventions and classes – building bricks if you like – to create web applications with. Using Rails you are constrained in certain ways, but those constraints free you up to focus your energies in other areas. According to the book Fifty Years of the Lego Brick, six 6 by 2 stud Lego bricks can be combined in 915,103,765 ways. Similarly the various component parts of Rails can be put together and extended in a wide range of creative ways that are – to all practical concerns – limitless. Paradoxically, the imposition of certain overarching constraints only restricts you to the bounds of your imagination.

You can see some of this in the simple but effective designs of web sites built using Rails. Basecamp, Lighthouse, and Shopify all carry forward this aesthetic, as do many of the sites listed in software.com’s ‘Best Ruby on Rails’. There is joy in their simplicity. They each take a problem and respond to it in an imaginative way that isn’t bogged down with artifice or preconceived complexity. It’s not that you couldn’t do something similar in Java, .NET or PHP. It’s more that you wouldn’t because the culture of surrounding each of these languages is very different to that of Ruby on Rails.

I didn’t realise this before, but David Heinemeier Hansson – the originator of Ruby on Rails – is Danish, thereby bringing my musings full circle. What a weird world. I can’t find a reference to Ruby on Rails in “Dansk Design”. Maybe a revised edition will see it included – at least on a par with Aqua.

A bit of a rant entry here – written in a rush – but stuff that keeps going around my head:

With the all the current buzz going on about Twitter and RoR I may as well throw my own opinion in so you dear readers (all three of you) can.. well.. make up your own mind I hope.

Is it just me, or is there some weird deja vu thing going on? We’ve heard this before with the story of CD Baby switching back to PHP after 2 years of Rails development. Derek Sivers made it clear that he was trying to get Rails to do things it wasn’t meant to do and went back to PHP wiser for having been exposed to Rails. Similarly the Twitter guys seem happy with using Rails for web-facing user interfaces, though you have to infer from their interview at the Artima Developer site that they ran into trouble trying to get Rails to do things it wasn’t intended to do. I’m going by Alex Payne fessing up to calling kind_of? all over the place – hint: if it looks like a strongly-typed application, and it smells like a strongly-typed application… what the heck are you using Ruby for?

Whether the Scala experiment will work for Twitter remains to be seen. I suspect – and hope – that everything will work out well for them, as a JVM-based language just seems a better fit for the high volume of transactions they have to deal with. “Twitter chooses appropriate technology for its architecture” is probably the real story behind the story.. but no-one’s going to get frothing at the mouth and spout off ill-informed blog commentary if that was the generally accepted view. Indeed, where’s the fun if you can’t have the odd holy war.

Having worked with Rails for a few years now though I’m still constantly baffled by people’s insistence on trying to get Rails to do things it’s not meant to do. It’s not the first time I’ve encountered this sort of attitude – back in my Delphi days I remember a co-worker extolling Delphi’s capacity for building web applications. This was at the point that PHP was pretty well the dominant language for quickly developing web apps, so I was a bit surprised at how miffy the guy got over my “when you have a hammer, everything looks like a nail” response. Delphi was a great language for building Win32 clients – much better in my opinion what Microsoft was offering at the time. But using it to write web applications just seemed to be perverting its core purpose. I stand by this of course – how many web apps ever ran on Delphi? – and funnily enough the guy is now a convert to Rails. But anyway… there’s a definite pattern here.

It’s not just inappropriate use of Rails in general that bugs me. It’s all the minor deviations developers take because they want to do things differently. Rails is, as they say, opinionated software. If you don’t like way Rails does things you’re better off not using Rails at all as it’s going to get you in the end. I got burnt – and inadvertently burnt other developers – trying to get Rails to do oddball things in the early days of using it. It was mostly stuff that I brought over from other languages, plus my own personal preferences – along with trying to fix stuff I believed Rails just got wrong. Using idiosyncratic style or “optimising” the way Rails works by creating libraries to automate stuff that Rails already does in a long-hand fashion: (i) it assumes your way is right (hint: just like me, you probably aren’t) and (ii) it drives a wedge between you and other developers. At worst, you make a whole heap of work for yourself doing things one way only to backtrack and do them the “Rails way” later – or alternatively keep writing code around your deviations and constantly complain about how hard it is to get Rails to do what you want it to do.

I’m not suggesting drinking the Ruby on Rails cool-aid. There’s plenty of room for improvement and many things that have come to be included in the Rails core because someone got shitty with the original implementation (old v. new migrations being an example). But it’s one thing to offer improvements to the way Rails does things and another to slyly (or inadvertently) subvert the core conventions of Rails because you either don’t agree with or don’t understand what Rails is trying to do.

The things I love about Rails – and even more so about Ruby – is the clarity of the language. Getting back to my idea about Rails-as-CMS, the RoR framework seems – to me at least – to be well suited to tackle the current problems around web-development. It allows rapid prototyping. It supports communication within teams by laying out a set of common concepts and conventions – a “language” if you like that make sense and everyone involved can use in describing an application’s architecture. DSLs can be used to make business-readable fragments of logic that even non-techy managers should be able to grok. Designers can use Rails to weave functionality into their designs. OK, it’s not the most high-performing framework out there, but if issues of scalability are your problem then RoR isn’t for you. If getting everyone on the same page and getting a working application built with few arguments then Rails may be the solution.

Fighting Rails is a fruitless exercise. If you are up for a fight then go pick a bigger framework like Java or .NET where you have plenty of variety in which “true way” (or “ways”) you want to chose. If you want to enjoy building web applications using Rails then learn the framework, understand the conventions (and the rationale behind them), and allow yourself to question why you did things differently before. Even if it’s not for you, worst case is you’ll go back to your favourite language better for the experience.