CIRCLE WITH A DOT

@gilesgoat @cloudhop That's a perfect use case, nice one

@gilesgoat @cloudhop I was frustrated by test-driven design purists who seemed to want to continually test whether the processor could add two numbers!

I tended not to write test programs - except where running the real program could corrupt real persistent data. Then I separated out all the "doing the work" code from the "writing the results" code, and made a parallel data-safe test version of the program.

Other than that, Debug builds of the code that added sanity checking on function parameters seemed to catch most errors.

@gilesgoat @cloudhop absolutely - especially when adapting or extending existing code. My process is very much the same as yours.

The scary part of that big project was that it was the frontend processor tightly bound to a hugely complex SAS interface hardware block - I tested what I could by simulation, but that was only about 10%!

@gilesgoat @cloudhop my cube was outside the VP of Engineering's office. For weeks I saw him quietly fuming as he walked past. Often I'd be sketching ideas on a whiteboard, or sitting back staring at it with my feet up on a filing cabinet. Four o'clock each afternoon I disappeared off to the war room to chat with the other three system architects.

Sometimes he saw me actually typing into a code editor. "How's it going?"

"Pretty good - I've got the data structures locked down, most of the function headers in place, just working on the state machine now."

"So no code yet?"

"Not yet."

The code worked the first time it was flashed into the fpga prototype, reading and writing data to a RAM disk. In three months from the start of the project, we were booting Windows from that prototype.

For comparison, the previous ground-up firmware project took 18 months to get to the same point. Code-first only *feels* faster.

@cloudhop seriously... I spent far longer planning and designing a complex embedded system than actually coding it. Typing in the code is the easy part.