Archive

Ravings

One of the things I’ve wanted to do since I was a teenager in the 80’s is to build a homebrew 8-bit microcomputer. If you scan through YouTube you’ll quickly find that I’m not the only one. In fact many people have done this and done it very well. The question I keep coming up against though is, if I’m creating something from scratch, what would I consider “from scratch” to actually mean?

Many of the implementations you see online for example, will put together a 6502 or Z80 chipset with either a serial interface or a simple video interface and keyboard and plug in a Microsoft BASIC ROM. For me though, I’ve always known that I want to try to write my own version of BASIC. In some instances I’ve found people who have built microprocessors (or parts of microprocessors) from logic gates. This makes the “from scratch’ question even harder to answer. For example, do you allow yourself to use RAM, multiplexer, ALU components etc and create you’re own CPU and memory? Will you only allow yourself to use gates? Good luck if you choose the latter!

Similarly there’s the question of what tools you allow yourself to use. If I want to create a BASIC ROM, is it ‘cheating’ for me to compile the code on my MacBook Pro and test it using an emulator? In the end it comes down to practicality as there’s only so much someone can do on their own or within a small group of hobbyists and makers.

It was while pondering some of these questions that I came across Jeri Ellsworth’s YouTube channel which adds a whole new dimension to the question of what “from scratch” actually means!

While these are not new videos, if you haven’t seen them already I recommend you grab a coffee and spend 20 minutes giving them a watch.

I’ve recently developed what some might consider to be an unhealthy interest in FPGAs and Verilog. The stuff you can can do with these things is just awesome. As a result of this I went onto YouTube to look for inspiration and information and I came across a series of video lectures by Cornell University Senior Lecturer Bruce Land. Just check out the stack machine and compiler lecture. I would seriously recommend these videos to anyone else out there who might be struggling with an FPGA obsession.

Bruce Land, honestly, you absolutely rock!

Rich and Jon

I mentioned in a post a while back that I was planning to leave my previous job to try to put something new together. Well a whole lot has happened since then and so I reckon it’s probably about time for a bit of an update.

I eventually left Siemens at the end of September 2013 after an eight month notice period (blame a lack of self-confidence!) and, along with fellow geek Richard Hackett, we formed Polyhedrus Electronics Ltd in order to grab an opportunity that came our way to work in the world of motor sport.

The opportunity seemed like a pretty straightforward one: to come up with a sensor that can make contactless linear measurements over a variety of lengths. We were pointed at a bunch of existing products in the marketplace that were close to what was required and off we went.

Within a few months Rich and I had a working prototype that came close to meeting the spec. It didn’t quite have the linear range we needed and the output, an analogue voltage signal, didn’t quite have the range we were after but when it was demonstrated at the Performance Racing Industry show in Indianapolis towards the end of 2013 it caused quite a stir and it wasn’t long before orders came in and we were suddenly faced with the prospect of turning our prototype into a full on production unit.

This is pretty much where we are now. The first few production units are out there and are being tested by an F1 team who are hoping to use them in the 2014 season. We’ve also produced a capacitive fuel level sensor PCB and have a few other exciting projects on the go which I’m sure we’ll be discussing over the coming months.

So the million dollar question then, was it worth it?

Well the answer at the moment would have to be, “Hell yeah!”

I wouldn’t say that we’ve got it completely nailed yet. Unlike Rich who has worked at home for many years, I’m still getting used to that aspect of the work (hardest thing is to stop!) There are still a few niggles with the boards that we’re working through and timescales in motor racing are crazy so we’ve had to make that adjustment too. Trying to get a production process and supply chain going at short notice is a huge challenge and we’re still debugging that. Our feet haven’t touched the ground in the last 6 months!

Despite all of this though I think it’s fair to say that this has been an exhilarating experience and we’re loving it. Rich and I decided very early on that the core value of our new business would be Freedom. Freedom to travel (we both enjoy that), freedom to work the way we want to work and freedom to explore new and interesting technology and ideas. The business has a bit of a hippy vibe to it that I love and we’ll need to work hard to make sure that the daily pressures of keeping our business going don’t detract from that.

For anyone out there who is thinking of doing something like this themselves I’d say go for it! Make sure you are doing something you love and seek out the work of people such as Seth Godin, Marianne Cantwell and others who can provide concrete help and advice.

Meanwhile if there’s anyone out there with a really cool idea and needs a couple of talented geeks to make it happen, feel free to drop me a line and we’d be more than happy to discuss it with you.

We’ve been too busy to get ourselves a website yet but we have just put together a small Facebook page if you fancy finding out more about what we’re up to. The link is https://www.facebook.com/polyhedruselectronics.

Nothing kills innovation quite like the words, “That’s all very well but let’s be realistic here!”
Nothing kills a project quite like unrealistic expectations and requirement creep.

So does this represent an impossible dichotomy that acts to prevent us from building the innovative new applications that all engineering businesses need to stay on top of their game? Well, a lot of the time yes it does. It can seem as though the choices are either to take a risk, bite off more than you can chew and deal with escalating costs, requirement creep and late delivery in order to get ahead of the market or, like a tortoise peeking out and sensing impending danger, tuck your head back under the shell of your technical comfort zone and hope you can hold out for a little longer in a rapidly changing ecosystem.

Of the two options I can understand why the second may seem more attractive but the reality is that the longer that carries on, the further and further behind the rest of the world you get and the more risk you’ll need to take in order to re-establish yourself later on. But hey, no-one wants that kind of risk on their watch right? Leave it to the next person.

I’ve recently adopted a different view though. I think you can have both and that key to the whole thing is the ability to clearly differentiate between ideas and commitments when talking to customers about their needs.

Over the last few weeks I have been involved in a series of customer workshops in a sort of combined role of business analyst and system architect. It’s clear from the brief we’ve been given that the customer is very keen to see innovation in any solution they will end up buying but at the same time, delivery timescales are very short. At one point during the discussion I was talking to some of the users about some of the cutting edge things the solution we were proposing could deliver when I heard the fateful words, “That’s all very well but let’s be realistic here!”

Talk about throwing a bucket of cold water over proceedings!

The comment actually really irritated me. The reason for this was that we had clearly been talking about possibilities, exploring ideas to see if there was any mileage in them. I was trying to figure out what excited them, what was important to them and how new features might impact on the way they currently work. In that moment I realised that while most of the room knew and understood what was going on, it was clear that many didn’t. Worse than that, the ones that didn’t seemed to believe I was committing to features in the end solution. A situation ripe for confusion later on!

Later on as I sat back down after the discussion I started to mull over what had happened in that moment. Why had some of them not realised that we had been in ‘exploration’ mode? After all, the whole point of the workshop was to poke at the limits of the requirements and find out where they were. One thing was for sure, no-one was going to dare to suggest new ideas now. Suddenly the project had nothing exciting in it anymore.

It occurred to me that while I had been speaking, my mind had been jumping between several different modes and I couldn’t even remember at what points I had switched from one to another. No surprise then that I hadn’t brought everyone in the room along with me. If they had snoozed even for a moment (the view from the top floor meeting room was quite impressive too) or they didn’t understand some of the deeper techie stuff we’d been discussing, they could quite easily have been left behind.

As a long time geeky kind of a chap, I began to think about these different modes as a set of states in a finite state machine. I thought about how the conversation had traversed these various states and what those states might be. I came up with three and popped them into a note on my iPhone.

Stages of Requirement Capture

Stages of Requirement Capture

What’s possible?
What’s important?
What’s feasible?

When thinking about what’s possible you’re thinking innovatively.

“Technology is now at this point here and our systems currently look like this but imagine if…”

This is the ‘opening up’ part of the discussion whereas the others are the ‘nailing down’ parts. When thinking about what’s important we take the ideas and concepts discussed in the ‘what’s possible’ phase and start to focus in on the ones that make the most difference to the customer. Having figured out what’s important we then need to look at our constraints and build a project around what’s feasible. This is where we finally nail down the project scope.

It seems to me that if you want to create something great then a discussion like this must include all of these things. By dwelling on what’s feasible you close yourself off to innovation or what the users might really need. By dwelling on what’s possible you can lose track of what’s important and by dwelling on what’s important you can become too bogged down in the status quo and shut yourself off from new ideas that could offer real benefits to the customer.

The trick then has to be in finding a way to let other participants know where the discussion is at any particular moment in time. The next challenge for me is to find a way in which to do that. Perhaps some kind of discussion board divided into three areas could be used and ideas written on sticky notes placed on it. Perhaps a simple diagram showing the three states and a sticky movable arrow that can be pointed at the one describing where the conversation currently is. Something to explore I think. Please feel free to let me know if you have any ideas!

So how does this help with keeping your technology business alive and on the cutting edge? Well I believe that this creates a framework that allows us to engage in new thinking without the fear that it will get out of control because everybody involved knows whether the discussion is about something exploratory or not and that it doesn’t matter if the ideas may seem a little trivial at the time because the subsequent phases of the discussion will filter these into what is important and finally what is feasible. Good innovation will make it through all of these filters and what you hopefully end up with something that combines the best of the established with the best of the new.

Ban the button logo
A couple of months ago I was visiting my grandmother with my father and son and we thought it would be great to get a family photo with all four generations together. My dad passed his Android phone to my aunt and she lined up a shot.

Click…burrrrr

Something struck me as I heard the camera’s tinny rendition of a camera shutter complete with winding film. I turned to my dad, “Why on earth do they insist on using a camera shutter noise on these things? I bet no-one over the age of 25 even knows what a camera shutter sounds like!”

“What’s a camera shutter?”, my son asked as if on cue.

Imagine if we’d had the same conversation about cut and paste. Even I don’t remember a time when people editing documents had to actually do it with scissors and glue. The metaphor has now become the reality as generations of computer users grow up whose only experience of cutting and pasting has been when editing documents on a computer.

Having cut out sections of documents with virtual scissors and pasted them into place with virtual glue we usually need to ‘save’ them as virtual files in virtual folders. We ‘open’ virtual documents on a virtual desktop and throw things away in a virtual bin. Call me a curmudgeonly old git but it all just seems a bit… boring. I’m sure that many office jobs in the 1950’s and 60’s were that mandrolic but in an age when our computing platforms are so powerful that we could have pretty much any form of user interface we can dream up, why do we continue to insist on bringing that kind of tedium into the 21st century?

Now it would be unfair of me to try to imply that there has been no progress at all. There have been some notable examples of new technology designed to try and promote the use of new ideas for human computer interaction, most of which appear to come from the manufacturers of game consoles. I’m thinking of things like the Kinect or Wiimote but while these make for interesting toys I don’t see much of a take up in the boringly sensible corporate world. At the office we still want desktops and our old fashioned WIMP environments.

One of the trends that is becoming apparent now is the way that information is managed and consumed. We seem to prefer to deal with information as a series of narratives, not expressed in one huge document but rather as a thread of smaller pieces linked together, stored and consumed across many systems and devices potentially between several different applications. If we follow that idea through, I reckon we’ll see the documents of the future becoming more like a living web of facts and dimensions brought together within some kind of context. This would make it a lot easier to assemble and keep them up to date, they would effectively do it themselves.

I do wonder if this is a place where the next set of metaphors for human computer interaction can emanate from. I mean what exactly is a document in that context? Certainly not something you could photocopy and stick in a drawer. It would seem to me to be more of a mind map or a tagged snapshot of our thoughts or knowledge at one instant in time. Where is it stored? In a folder in a filing system? Well, no, it’s everywhere I need it.

So how do we encourage innovative thought in this area then? Well one way to get people to be inventive is, ironically, to give them constraints. Innovation comes from the need to adapt and overcome problems. I was involved in a project for a mobile app a while back where we sat down and specified the UI in a document for use by an external company we sometimes outsource to. Everything was all signed up and agreed and they went off and started developing it for us. As the project was nearing completion they provided me with a couple of screenshots that I could include in a weekly report. There was something about them though that didn’t sit right with me. Then it struck me. I didn’t want to include them in the report because they looked… well… boring. Now this was no fault of the team who built the app, we had provided the spec and it was far too late to change anything. It did get me thinking about how it could be done differently though.

One idea I came up with was to ban certain types of control from the UI. For example, I think many developers use far too many buttons. Buttons certainly have their place but they can be misused in my view. Buttons are a way of capturing the user’s intent but I’m convinced that there are often much more subtle and powerful ways of doing that than simply presenting the user with a shed load of things to click on. Anyway, I thought, what would happen if we banned them from the UI? Entirely. Would that force the developers to come up with something new? I’m sure the rest of engineering thought I had completely lost the plot when I offered that as an idea but I really do think it’d work because it would force them to think laterally and creatively to solve the problem. I think I’m tempted to run with this one and start a campaign to Ban the Button!

Ok so back to the photograph: having some kind of a noise come out of your mobile device when you’re taking a photo is actually pretty useful. What would be a good replacement noise for a mechanical shutter then? A beep, a loud voice saying, “Smile and say cheese”, a few bars of Def Leppard’s rock ballad Photograph perhaps? I don’t know, that’s a tough one. Let me know if you have any ideas!

Source: wikimedia commons

A poem written by spookily accurate futurist John Godfrey Saxe in 1872 about Scrum and Agile software development. Thanks to the awesome cvdanes for putting me onto it.

The Blind Men and the Elephant

It was six men of Indostan To learning much inclined,
Who went to see the Elephant (Though all of them were blind),
That each by observation Might satisfy his mind.

The First approached the Elephant, And happening to fall
Against his broad and sturdy side, At once began to bawl:
“God bless me!—but the Elephant Is very like a wall!”

The Second, feeling of the tusk, Cried: “Ho!—what have we here
so very round and smooth and sharp? To me ‘t is mighty clear
This wonder of an Elephant Is very like a spear!”

The Third approached the animal, And happening to take
The squirming trunk within his hands, Thus boldly up and spake:
“I see,” quoth he, “the Elephant Is very like a snake!”

The Fourth reached out his eager hand, And felt about the knee.
“What most this wondrous beast is like Is mighty plain,” quoth he;
“‘T is clear enough the Elephant Is very like a tree!”

The Fifth, who chanced to touch the ear, Said: “E’en the blindest man
Can tell what this resembles most; Deny the fact who can,
This marvel of an Elephant Is very like a fan!”

The Sixth no sooner had begun About the beast to grope,
Than, seizing on the swinging tail That fell within his scope,
“I see,” quoth he, “the Elephant Is very like a rope!”

And so these men of Indostan Disputed loud and long,
Each in his own opinion Exceeding stiff and strong,
Though each was partly in the right, And all were in the wrong!

moral

So, oft in theologic wars The disputants, I ween,
Rail on in utter ignorance Of what each other mean,
And prate about an Elephant Not one of them has seen!

Just to clarify, I consider myself amongst the disputants!