Building software frontend for hardware that does not yet exist

Question

Our task is to build a software frontend to control a hardware device that does not yet exist. We should start development about half a year before the first prototype is available, the project is timeboxed to one year. It is yet unclear what the hardware and the embedded software will be capable of. There're no specified interfaces yet. This will have an impact on the design of the client software.

There're only few things we really can build as long as the interfaces aren't specified in detail.

Sure, you'll probably just say: Write a mock. But this isn't an easy task and a whole mock could turn out to be a whole project by itself.

I'm thinking of writing an adapter layer in which I can plug in any device later on, as long as it has the promised capabilities.

But I'd like to hear advice from you, on how to tackle such projects and avoid possible pitfalls. To what things should we pay special attention? How should we advance on such a project?

Additional information: We're creating the software project SCRUM-like, but not traditional. We'll make a good deal of upfront design to establish a clear vision, in order to hit the desired targets and minimize the number of iterations.

Also, we have a clear vision on what the hardware/embedded software is supposed to deliver, we just don't know how they're gonna go about it yet and if they can implement the functional requirements at all. We've started a document to collect the interfaces we'd like to have for the client software (because whoever specifies first, wins, g). We also have a rather clear vision of how the client should look like to deliver the best business value, but it is yet unclear if the hardware can support our concepts and it will probably take some time into the project before we know for sure. Yet, we should start development asap.

Answer 1

You don't give a hint as to what the hardware will do, so I will assume it is none of the devices that require you to conform to a specification (such as a network adapter).

In the most general case, I'd start with a fully specified API for accessing the envisioned hardware as per the functional specifications. Once you have your API approved, you can move on to implementing the mock hardware as a software only library. This will give you great advantage even after the hardware is done, because you can debug quite a bit of your clients without ever needing the hardware - a lot simpler that messing with a hardware device. This will give you two products to maintain: the real library, and an emulation library; but the effort will be worth it.

Once the hardware is ready, you can start removing a lot of code from your library, and offload the processing to your hardware. Your library will then change into an adapter layer: converting the hardware implementation into the API you've implemented in software. If your API matches the hardware perfectly, the library will be an extremely thin shim - perhaps something that serializes the parameters, sends them off to the hardware, and reads the results. Or it can turn out to be nothing like what the actual hardware will be, so there will be quite a bit of code in your library, maintaining non-trivial client side state that is used to drive the hardware.

Answer 2

This sounds like a perfect opportunity to me. I would love a project where it's not only feasible but desirable to the customer to go through many stages of prototype before actually developing.

Everyone at the initial design meeting will have a slightly different vision of the software. You can each help everyone else visualise the product very easily with a paper prototype.

You can discuss the differences, show them to your bosses, your customers, somebody you just dragged in off the street and get a very good idea of what works and what doesn't, until you all come down to a single vision.

Then you can create a physical prototype, in HTML, or whatever other front-end design language you're using. It shouldn't do anything. It should just be a front end, that people can click on, and type in, and move around their three screens. Whatever. Just let people play, and watch them, and learn what works and what doesn't, where the inconsistencies are in your design, where people feel a need to click, etc.

Then and only then will you really know what the simplest possible interface to your hardware should look like. And then you can write your adapter, leaving only the complications of the real interface, when it arrives, to code against.

Answer 3

Scrum is a great choice in a project with such level of uncertainties.

You must work with business & hardware team closely and iterate till you meet the goal.

This means that as new information and precision arrive, your product owner will reorder and put more details in its user stories.

Let's say you planned for v0.1 but as the hardware team work, new specifications are defined. You define a new estimated target.

New requirements & specifications arrive again. New target is defined. You pivot to the new direction, but you don't have to rewrite everything completely.

Requirements & specifications can change very often, but as we advance in the project both business & hardware have clearer view of what they need to do. So do you.

Of course, this project will cost a lot more than if you had more clear requirements at the beginning, but between you and me... it's a pretty rare situation.

Information should come from business because they have the big picture. And information from hardware team is crucial for the technical implementation and interfaces.

Clearly, a great Scrum Product Owner is the key is such unclear and risky project.

Illustrations comes from a really great article called Rockets, Cars & Gardens: Visualizing waterfall, agile and stage gate.

Answer 4

Sure, you'll probably just say: Write a mock. But this isn't an easy task and a whole mock could turn out to be a whole project by itself.

You should do it either - develop some kind of software simulator which replaces the real hardware. You don't have to build this upfront - in each iteration, develop your simulator just to the degree you need it to test the functions you have in your frontend so far. Heck, I can't think of an effective way of iterative development, prototyping / showing functions to the user if you don't have some kind of "backend" behind it - your users have to see / work with your software if you want to get feedback, and if you don't have the hardware and no simulator too, how should they?

A simulator will also be a useful tool for testing you frontend even when you have the hardware available, because you can provide special testing functionality in it your real hardware does not provide. I don't know you hardware, but when it is just beeing constructed now, I suspect it is not so cheap that every of your team member gets an individual piece of it? Then a simulator will also pay for itself.

Answer 5

Write the software first, then drive the hardware guys to design around what you have delivered. This is how Google changed the smartphone market 180 degrees. They delivered an OS and forced the hardware vendors to design to it. Instead of the way they were doing it before; creating lots of hardware that caused lots of different incompatible one off software to have to be written.

Answer 6

I would start two different projects: a mockup of the UI, and a hardware simulator.

The UI-oriented people will work on the mockup, working with customers to determine how the the final product needs to work (just about like if you were developing for already-existing hardware).

The more hardware-oriented people will work on the simulator. At first it'll be relatively simple because you apparently don't know all that much about the final hardware (yet). As you learn more about the planned hardware, you can incorporate what you learn. Likewise, as you learn more from the UI people, you can incorporate what they're learning.

Over time, you "grow" the two closer together -- i.e., the first few mockups probably won't even attempt to fit the intended hardware beyond the general ideas of roughly the intended format factor, intended provision for user input, etc. As you learn more about the real hardware, you tailor your mockup to fit what it's actually going to provide.

One point of this is to learn as much as you can before the first prototype is delivered. Another is to provide feedback to your hardware people, so if what they're designing is going to completely incapable of supporting crucial features for the users, they'll have a chance to re-design more appropriately. In some cases, fixing a major problem can be pretty easy, as long as they know about it soon enough. Much as with software, they sooner they know about a hardware problem, the less expensive it's likely to be to fix it.

Although none of us likes to think in that direction, it also means that if the hardware you get can't possibly do the job, it may well be extremely helpful to your future to have a paper trail where you told them about the problem months ahead of time.