This is it… and it’s real. It’s the prize your friends and colleagues can only dream of. Your team… your entire company… even your family will wish they had one.
It’s a limited edition AgileSoC.com t-shirt!
Here’s how you win: respond with a short comment on why you think agile development works for hardware. Maybe it’s Scrum… or TDD… maybe incremental development… pair programming… retrospectives… whatever… just scroll down to the comments and tell us why it works. To be fair, even if you don’t believe agile has any application whatsoever in hardware, tell us why. A comment either way gets you into the draw.
At precisely 10:13am, Tuesday July 1, my 3 year old daughter will draw a winning name from the list of comments… and that person’s dream comes true.
To repeat, a comment telling people why agile does or doesn’t work for hardware gets you into a draw for a limited edition AgileSoC.com t-shirt. This shirt will change your life. It’s changed mine. I haven’t taken my AgileSoC.com shirt off since the day I got it.
…and when I say a limited edition, I mean limited edition. Only 2 people on the planet have one. One lucky comment could turn you into #3.
6 thoughts on “Win A Limited Edition AgileSoC.com T-Shirt”
Nice. Well, for one thing, a good deal of the HW development process is actually SW (HDLs, tools, etc) so no debate for those stages I would like to think. Yes, Scrum, Pair-X, RTL CI, TDD they would clearly all apply.
The problem comes with the truly HW part. You get your board, you wait on your chip for the power-on, time frames become huge and dependencies or need for expertise increase. So people can complain that things like Scrum will not be adequate, and I can agree to that.
But being Agile is not about a particular methodology. If you can’t do Scrum, you can still retrospect, pair-X, and if you did TDD right, you actually would have thought on how you would test when HW was back. Maybe you’ll choose Kanban, up to each team.
In the end, it is about the manifesto. You know the manifesto. It is about that.
With any hardware development, (regardless of development methodology) during design (very simply stated here) you can expect the BIG FOUR:
• The hardware doesn’t work.
• The board-level software doesn’t work.
• The hardware and the board level software don’t talk to one another.
• The application level software doesn’t work.
I find that the HW folks “GET IT” when we introduce adaptive development as they’re used to successive prototyping. The focus of Sprints changes slightly to “what is the design question we want to answer, and how are we going to prototype to test that we’ve answered that question.” It’s all about the manifesto, and I’ll take a medium, girlie style t-shirt please. (Just kidding!)
As Armando said, a large portion of HW development is SW development. But sadly in my experience I have still seen debate for those SWish portions. Most HW developers I’ve met don’t know SW development, and have never heard of Agile, Scrum, Extreme programming, etc. So getting a tops-down buy-in from HW project management can be interesting.
Educating and convincing the uninitiated is a difficult prospect since the problems that most teams are focused on are the technical problems of design/verification. Part of the issue is that of perception. The first impression of things like Scrum, pair-programming or TDD make developers feel like they are giving up autonomy with a dubious benefit. In fact, process overhead and micro-management were some of the most common complaints that I heard from management and HW engineers.
In addition to that, some challenges which I think are specific to the HW domain (though I’m probably wrong since I have limited exposure to the SW domain) are iteration times due to slow compilation (hours) and slow simulation (Hz), constraint checks (design rules, static timing, equivalence, etc.) and artifacts like simulating with an imperfect model for design requiring further checks and iterations (i.e. gate-level simulations, emulation). Waiting for results tends to encourage multi-tasking. Multi-tasking defocuses priorities and opens the door to work-in-progress at the end of every sprint.
On the flip side, I have seen some bright spots and even some success. Interns and recent college grads are more easily indoctrinated into the Agile-way. A couple of small teams doing Scrum delivered high-quality design and testbenches on a predictable schedule. The biggest thing was the grassroots effort to give Agile HW development an honest try. Once you’re doing it, then you incrementally whittle away at those (HW domain) problems.
I can’t say much about agile in hardware development in general, but I can share a bit of my initial experiences with SVUnit and TDD of verification code.
I’m a verification engineer. Like most other people in my field, I’m not a trained software engineer. I don’t have a computer science background. I am at most a hobby programmer. When I started with SystemVerilog in 2009, I just knew how to write code that did the job, but was nothing fancy. After touching a bit on software development (for some tools in our company’s methodology group), I decided that I want to improve my code writing skills. There were many dimensions in which to improve: flexibility, performance, readability, etc.
I decided that the first one I wanted to improve is the one that is most often overlooked: correctness. I was stuck in a continuous loop of write, see it fail later, fix it, see if fail later (maybe somewhere else), and so on… You could have the cleanest, most extensible code, but it’s equal to 0 if it doesn’t work as it should. But to make sure it’s working as it should, you have to test it.
Test driven development (TDD) states that the best time to test code is when you write it because that’s when you’re in the zone. This is possible in SystemVerilog thanks to SVUnit. Late last year I got a break between projects and I was assigned to do some work to support my colleagues using SystemVerilog. We were developing some new VIPs from basically scratch.
I downloaded SVUnit, fired it up and a few minutes later I had myself a unit test. I started out slowly without much discipline. Sometimes I wrote the code first and then tested it. Other times I gave TDD a try and wrote the tests first, watched them fail and then wrote the code. Because everything was (I don’t want to say thoroughly) tested we had a much smoother ramp-up of our new VIPs after putting them to use in real projects. New feature requests came, we found performance problems with some pieces of code and also some bugs, but having the unit tests made refactoring much easier and they gave us more confidence in the code.
If you do SystemVerilog development, I urge you to give unit testing and SVUnit a try. Make your code work first and make it fancy second!
(Shameless) Plug: you can read the whole story on my blog: A Quick Look at SVUnit
Software learned components from hardware industry. Software could fail fast without considerable damage to the production line, that’s why software went a head and got matured with the concepts like Agile feedback and faster failure.
Now hardware roll-outs can get faster feedback with the help of Virtualization and Cloud, so it is natural to extend some Agile concepts there.
Agile development can work for hardware. Because we don’t know in advance how much hardware will required to make hardware application. So we can create hardware application using agile process as following way.
First add hardware to system then check whether it fulfills the client requirements or not. If not then add new hardware and check again whether it fulfills the requirements or not in this way you can use agile development process for hardware…