Virtual development is here and the timing is dead on, as more and more industries demand connected embedded systems.
We've all heard the buzz about the “Internet of Things.” We all know that although cloud computing may be in its infancy, this child is a prodigy. Social media has hit its stride. So what do these three things mean to us firmware types?
It's a trifecta, my friends.
As a firmware engineer running a consultancy, I work with clients and consultants who are local but also national and even international. Location of a client no longer limits the geographic range of our businesses because we can all work remotely. But what does the client lose as a result of your team being remote? I proposed this question to the firmware consultants group that I facilitate on LinkedIn.
Here are six issues that my colleagues on LinkedIn have with working remotely, followed by my six game-plan mitigations for working in a virtual work world. Tell me in the comments section below how you handle some of these situations.
Issue 1: An inability to get to know the team on the ground better.
Game plan: We all know that getting to know the team is hard do when you're all working remotely. One thing to help is this gadget called the phone. No, it's still not as good as sitting in the office, having a beer after work, and so on. But it can be very effective in establishing a trusted relationship. The other thing we can't rule out is having at least someone from your team local so that that they can have those after work beer(s) with your clients and get to know one another face-to-face.Issue 2: Ideas come by “sitting around the scope” (the engineer's equivalent to the water cooler). When you're all looking at “that trace” on the scope scratching your heads, not only do ideas arise, but actions can come from it that lead to solutions. Now you could mitigate this via teleconferences, screen sharing, and so forth. But the problem here is that this is spontaneous. You walk by Greg's cube, he looks up. You say to him, “Hey buddy how's it going.” The next thing you know you're finger-greasing up the screen on his scope, logic analyzer, frequency analyzer, who knows.
Game plan: OK, this is a tricky one. Hard to spontaneously walk by your colleague virtually. But! What about a chat tool? Skype for example. Perhaps it has to be a bit more deliberate then just the occasional “walk by.” You can still simulate the walk-by with a chat tool. “Hey Brett, how's it going ;),” you type. Got to add in your emotions!Issue 3: Those times when you're stumped and have no one in sight to bounce ideas off of.
Game plan: I'm stumped! It is a problem if the engineer is isolated. Here are a couple of thoughts. Screen sharing has become so easy now. Screen share and talk it through. If you're in consulting as I am, hopefully you have good reach into the consultant marketplace. Then you can contact a colleague in that engineers location to get some real-time, side-by-side help. Skype chat–we hold Skype chat meetings all the time. The dynamics of a Skype chat meeting are interesting. Everyone gets a word in! No more the loudest in the room gets his way! You would be surprised what you can accomplish in a Skype chat meeting. Someone mentioned to me that the fastest typist wins. Hmm, ok but we're all bit-heads, right? We're all pretty fast with the keys, unless you're a hardware guy trying to write firmware and peck your way. Advantage firmware guy! OK maybe we have to slow things down a bit to allow the hardware guys to catch up ;).
Issue 4: When dealing with critical issues or problems, the client or the team may not feel that you give it the sense of urgency it needs.
Game plan: Virtual meetings are now old hat. There are so many tools out there, it's ridiculous!
Issue 5: How the heck do you troubleshoot and debug remotely?
Game plan: Troubleshooting and remote debugging? No big thing! Gang, we're bit heads and I think we can figure this one out. Yes the bandwidth could be better but with screen sharing and a dedicated PC at the client site or even for the remote team, we can handle this. But what if we need to say make or break an electrical connection remotely? What if some physical action like plugging in something is necessary. All can be done simply from the dedicated PC either by remotely programming the MCU to toggle some control bits to turn on/off relays or by a pre-made control board with a USB connection that does the same thing. That and screen sharing to get you access to the IDE and the debugger, and you're done. Does this handle all cases? Can we be completely hands-free with ease? Not always but often.
Issue 6: What about things like defect tracking and revision control? Don't I need to be on site to tap into their tools?
Game plan: My favorite question: defect tracking and revision control. If the client or colleague is not using one of either, there are some awesome cloud-based tools that will setup your repository and allow you to use SVN or other tracking tools to make this a breeze. Usually they have integrated defect tracking to boot. If home base is using their own and if it's web based, you're done. If it's not, you may have to VPN into their system.
Channel your inner pack instinct
This prodigy called cloud computing is already revolutionizing the way we work, but no matter how remotely we work, we'll always need the human interactions. You can't take the human out of us. We are pack people. OK, maybe not all of us geekers (as my wife fondly calls us), but most of us are.
See you in the trenches!
Robert Scaccia is president of USA Firmware, LLC, which deploys teams to provide embedded consulting, firmware, software, hardware, product development, resourcing, and training needs. To learn more about Bob or his company, email him at or check out his website at .