I had a neat opportunity to do a lunch-n-learn with a large group of engineers a few weeks ago. It was organized by the IEEE Computer Society as part of a program they use to pair engineering teams with various speakers and topics. They found me through a referral from an agile software friend of mine. I pitched a topic that sounded interesting enough so it was all systems go. I flew in for a day the third week of november. We had 250 people tune in. Good realtime feedback and a great experience for me.
I’ve done webinars like this in the past but I’ve never felt like I left people with a solid feel for how they get started with agile hardware. I wanted this time to be different; I wanted to boil the mess of information that floats around in my head down to concrete possibilities; I wanted those listening to go back to their desks feeling like they had the gumption to get something started.
The 2-headed theme I went with involved incremental development and test-driven development. Both these techniques are very important to me. I feel like incremental development and TDD are in a tie for first place when it comes to useful skills I’ve learned since becoming an engineer. After having worked with them for that past few years, I’m at the point where I can’t imagine myself working without them. In terms of focus and quality of work, their combined impact on the average engineer (i.e. engineers like me) can be pretty stunning.
Anyway… hard to tell for sure if I did any better than usual, but I at least felt better than usual so I’m going to assume the webinar went ok.
A fews days after, I got feeling like I could do something similar here on the blog by pointing people to past posts that I think offer the best chance of getting something started. Admittedly, I tend to barf… errr… blog ideas as they come to me without much rhyme or reason; the good stuff can get lost in the clutter. To help you cut through the clutter, here’s a couple old references that I hope get people going in the right direction.
The first is a May 2011 post that describes an exercise called The Steel Thread Challenge. A steel thread is…
…some minimal thread of functionality through a product. I think about it as being able to <do something simple> to <some input> so that <something basic> happens on <some output>. As a hardware guy, a steel thread seems synonymous with a sane design. It’s small relative to what remains but significant in that you know the design is doing something right.
Your steel thread is a baseline, a first successful step on the way to many more successful steps. If you’re a hardware engineer wanting to get started with incremental development, try The Steel Thread Challenge.
For getting started with TDD, I think TDD And A New Paradigm For Hardware Verification from Novemeber 2011 is the best I’ve done. This was a big picture post to explain how I see TDD (and incremental development) providing a much needed facelift to our existing – and outdated – block level/top level development paradigm. With TDD, what we do ends up looking a little like this…
That’s it! Two ways to cut through the clutter. Hope it helps!