It’s been a long while since we posted Mike Thompson’s guest blog, A Heretic Speaks (Why Hardware Doesn’t Fit the Agile Model), where he outlines his argument for why agile is a good idea that just can’t work for hardware. Since then, I’ve tried to think of the perfect response, the counter argument that would have everyone nodding their heads in agreement and screaming “Agile wins!”. Alas, I regret to inform you that Mike and the rest of the agile heretics out there have won. There is no perfect response because agile will never work in hardware. So instead of confronting Mike’s argument, I’m here to pile on. I hope I can help others who, like me, were deluded into thinking agile could work in hardware.
Carrying on where Mike left of, I’m going to get a little more personal by focusing on one specific approach to agile development. There are many different approaches out there, none of which could possibly work, so I think the only way to blow this thing up is to tear each apart individually. I’m going to start with XP.
For the unfamiliar, in XP there are a set of primary and corollary practices (I’ll list out the primary practices in a minute so you can see how ridiculous they are). Like Kent Beck explains in his book Extreme Programming Explained, teams must do all of the practices in order to qualify as being an XP team 1. If they don’t, they’re not an XP team and most importantly, they’re not agile. At all 2. They have to do everything, everyday. No exceptions 3. If somebody messes up, the agile police come by and rip your accreditation 4. That’s how strict this is 5. Scary stuff 6.
A final note before I carry on… while XP and it’s collection of practices looks broadly applicable and well thought out, don’t be fooled. I’ve finally realized that XP completely supports the very narrow view that a lot of hardware developers have of agile development (I often hear that referred to as a “pure agile” approach which involves taping out an ASIC every month regardless of cost).
So here’s the primary practices with detailed explanation for why they’re useless for hardware developers.
Sit Together: Nope. The idea of working in a shared space close to all your teammates is a little absurd, even if there are areas provided for working quietly on your own. Hardware developers need to be isolated. Ideally in cubicles, preferably in different buildings.
Whole Team: Nope. Cross-functional teams won’t work either. Hardware developers not only need physical separation, they also need to be separated by ideology. Designers with designers… verifiers with verifiers… implementation with implementation… etc.
Informative Workspace: Nope. Grey… that’s what we need. Everywhere. No whiteboards. No easily accessible or sharable information. Nothing. You need an office that’s faceless and without description. Extra marks for status reports that aren’t published.
Energized Work: Nope. Software developers may need to limit their hours in order to stay energized and come to work each day enthused and ready to go but not hardware developers. We thrive on long hours and stress.
Pair Programming: C’mon… seriously? Real-time code reviews and cooperative problem solving? Hardware developers need to be efficient and productive. That means we all need to be loaded to 100%. There’s no time to pair.
Stories: Absurd. You may be able to reduce software into a list of feature-like stories about what a product provides to it’s users but not hardware. All hardware is complicated – all of it – and reducing it to a collection of items that convey the value of individual “features” as it’s realized by users is… well… absurd. Don’t even get me started on how XP teams use stories to prioritize development.
Weekly Cycle: Now it’s getting ridiculous. In hardware there’s one cycle… it starts at the start and finishes at the finish. Coming to functional, meaningful checkpoints at the end of each week is counterproductive at best. And of course, you can’t tape out an ASIC every friday so really we shouldn’t need to go further with this idea of a cycle, XP or agile development. And because you can’t do it for ASICs, you also shouldn’t do it for FPGAs or IP. Weekly cycle… pfft. Nothing about a weekly cycle makes sense. RTL done… now that makes sense. That’s the kind of milestone we need to keep.
Quarterly Cycle: Go back and read the weekly cycle again, then just try and imagine coming to functional, meaningful checkpoints every three months. Even more ridiculous.
Slack: no again. I already talked about 100% efficiency. Slack is not efficient.
10-Minute Build: Ok. I get it. Software is super simple and it’s easy to build and test software in 10 minutes or less. It’s pretty much automatic. I can see that. But again, this is hardware. We can’t do anything in 10 minutes or less. Even if we could by… say… rethinking how we build, use or run tools… why would we want to? Overnight builds are fine. Regressions that run a week or more are better. No feedback means we have more time to build stuff.
Test-first Programming: terrible idea for two simple reasons. First, it takes too long to write code that’s functionally correct. Schedules don’t allow it. It’s much more efficient to write terrible code, dump it on someone else to find all the bugs and file bug reports, then have the designer read the bug reports, fix the code and pass it back to test it as part of a long and frustrating game of defect ping-pong. Second, everyone knows that the best device size and power estimates come from huge piles of dysfunctional code. Nevermind the fact that people should never, ever make sure that their code does what they intend it to do. That’s testing and someone else does that. Sure, trust them to design and write it. But test it? Dream on.
Incremental Design: Not a chance. We don’t do incremental design because we don’t need to do incremental design. We can foresee all hardware design issues with careful and methodical planning. How, you ask? Well, it’s a well established fact that moore’s law not only drives the size and complexity of what we’re able to put in silicon, it also applies to the IQ of all hardware engineers; as designs get larger and more complex, hardware engineers become proportionally more intelligent. We’re also clairvoyant which really helps. Delaying, revisiting and tuning design decisions as we go makes no sense.
Continuous Integration: This is a dangerous one. At first it looks like a good idea. A closer look, though, reveals that continuous integration is incremental development in disguise where you integrate and validate code as you go. If you’re considering continuous integration or, God forbid, actually using a CI system: STOP! Believe in your plan and save your integration to the end. I’m sure everything will come together. It always does, doesn’t it?
There you have it… my argument for why there’s no room for XP in hardware. On the surface, it’s a collection of practices meant to enhance many different facets of development from creativity, to communication, to teamwork, limitations of intellectual capacity and market predictability and so on. Dig a little deeper though and you’re left with.. ta da… “pure agile”.
You fooled me once, agile. Shame on you! Fool me twice? Not happening.
If I leave you with anything, please remember that it takes all of these practices plus the corollary practices to officially be an XP team (aka: agile team). Not being able to do even just one of these should be justification enough to brush aside the lot of them. To quote Kent Beck in the final line of Extreme Programming Explained: Putting together a software team that can do all the primary and corollary practices of XP – everyday, without issue – is super easy so if you find there are individual practices you have problems with, don’t bother with any of them. They couldn’t possibly help you 7.
XP in hardware… can’t be done. Agile in hardware? That can’t be done either.
- he doesn’t actually say that ↩
- also not in the book ↩
- there’s actually lots of exceptions ↩
- there is no agile police, or accreditation ↩
- it’s not strict ↩
- it’s not really that scary, either ↩
- OK, so that’s not a real quote but I’m pretty sure that’s what Kent meant when he says XP is hard work and suggests software teams can benefit by adopting any of these practices ↩