I’ve been a software developer for quite a while. When you spend long enough inside a particular world, it’s easy to wind up with an ever-narrowing perspective. You start seeing everything from a software point of view. As the saying goes, when your only tool is a hammer, you tend to treat every problem as NP-Complete. Or something. I forget how that goes.
Anyway, the point is, it’s always good to broaden one’s horizons, and solve as many different kinds of problems as possible. To that end, I started to get into hobby electronics recently. The journey has been very enlightening in a number of ways.
First of all, I learned that hardware is really not so different from software. The same principles of engineering design and debugging apply. When designing a complex hardware system, you use the same basic approach as a large software system. You break it down into increasingly smaller components until all the pieces are small enough to be implemented and verified in isolation. Then you start implementing the pieces, connecting them, and debugging issues that occur as a result of those interactions. Gradually you wind up with a complex entity that functions, but is too large to understand all at once.
Second, I learned that hardware people have cooler tools (like, with blinking lights and stuff). Some of them make noises. Some of them are hot or sharp.
Hardware arguably has more of what are thought of as “hard bugs” in production software engineering. These are bugs that are difficult to reproduce, or behaviours that are non-deterministic. These types of problems are common in very large systems, realtime systems, and multithreaded systems. An experienced software developer has encountered and solved many of these, often spending days or weeks on a single bug. Luckily, that knowledge maps very well to hardware debugging. This is not to say hardware development is more difficult than software development. I think they are about equal in this regard, but the challenges tend to lie in different areas.
Good software engineering is largely about minimizing the hard bugs. A well designed system will experience fewer memory leaks, fewer deadlocks, fewer race conditions, and so forth. Hardware is a world of AC noise, electromagnetic interference, static electricity, parasitic capacitance, and all kinds of other random phenomenon that can make debugging difficult. Similarly to software, much of good hardware design is down to minimizing these sorts of influences.
In the end, I’m learning that hardware can be immensely satisfying, because you end up with something you can hold in your hand when you’re done. Don’t get me wrong, I love writing software. However, it does suffer from the problem that everything you make is fleeting. I think back to all the hundreds of hours I spent on projects in grade school, for example. Those games and demos are all gone now, probably forever. The floppies are theoretically still in my mom’s basement, but they are most likely unreadable by now. Modern code still has the same problem, in a different form. Sure, with the internet and constant migration, the code itself can live forever. However, all the layers of languages, SDKs, libraries, and drivers that it depends on become obsolete if not constantly maintained. Backward compatibility has a window, which the code will slide out of if not kept up. At that moment, it ceases to function. Software is, and always will be, fleeting.
Perhaps the acceptance of the idea of hard work going into something fleeting is the difference between hardware and software people. Software people are used to thinking “virtually”, and long ago came to terms with the idea that when a project is done, it is pushed aside, perhaps forgotten, and all focus is put on the Next Thing.
This is a great time to explore both sides of the hardware/software divide. Microcontrollers and friendly development boards are blurring the lines between the ‘wares. The barrier to entry to the other side is getting lower all the time. So, if you’re a software person, try getting your hands dirty and sling a little flux. If you’re a hardware person, try your hand at a genetic algorithm, a pathfinder, or a quicksort. You might be surprised at how awesomely the other half lives.
* * *
About the author:[Quinn Dunki] has been making games for 32 years, the last 17 of which have been professional. She was recently AI Architect at Pandemic Studios, on the dynamic open-world title “The Saboteur”. She now pursues consulting, independent development, mixed-media engineering projects, and writing. She has a mobile software company and consultancy called One Girl, One Laptop Productions, which makes games and other applications for iOS, Android, Mac, and PC. In her spare time she takes pictures, races cars, hacks electronics, fabricates computers, and berates her friends with sarcasm.
http://www.quinndunki.com
http://www.quinndunki.com/blondihacks
Filed under: Featured, rants
