Hacker News Reader

Comment by jgable | Hacker News Reader

Question for author and others on HN:

How feasible is it to have remote employees when most of your work is on embedded systems?

I recently started a software consulting group with a couple of partners, and we are starting to hire. I'd like to offer remote positions, but since most of our work is on embedded systems (e.g. medical devices), I don't think this is really feasible. For any given system, there's so much pain in wiring, setting up and debugging a test and development environment, etc. that it doesn't seem worth it. However, maybe I'm overestimating the difficulty and underestimating the benefit. Anyone else have success with remote work that is not primarily on web systems?

View on HN

I suppose that depends on how remote you want to be and what their availability is for occasional on site work. I've worked several places where I've done work remotely that was integrated on one specific, specialized system. I did most of the work remotely and then every once in awhile we booked a hotel close to the final site and did a week of testing.

It requires a lot more up front planning. It doesn't work as well for an "agile" environment. Although from what I have seen it is difficult to make "agile" work in a specialized hardware environment anyway.

Essentially my entire software career has been on embedded systems and this problem is something I've given a lot of thought to, in terms of how much work we can without needing to be in the office.

The machines we build are big. As in $100,000 build cost and almost half a ton of aluminum and plastic big. Obviously not something each employee can take home to work with remotely.

Since our control system hardware is pretty high level (Pentium-processor SBC scale), we have a lot of leeway in terms of footprint. So we simulate as much of the I/O as we can. This lets us do a lot of development without each developer needing the actual hardware for most testing. By abstracting the hardware away in this manner, the development becomes similar to server-type software dev that can be done on a desktop.

It doesn't solve all the problems, but we can do probably 80% of our development work on our laptops and only need to do some critical testing on the actual machine itself.

Where the need to be in the office really hits is the interactions with electrical and mechanical engineers. While they have drawing and specs in electronic format, the discussions usually rely on everyone being colocated. I've found it is very difficult to explain designs even over good video conference systems.

Is it cost-prohibitive to ship test devices to each of your engineers?

I have worked on an embedded systems team where some of the employees were remote. The biggest challenges were with sharing details for reproducing specific issues, but emailing videos and lots of conference calls made it a functional environment.

No, for most of our projects, the test systems are small enough so that it's not cost-prohibitive to ship. I just know that every time we bring up a new system or board, there can be days of debugging stupid problems, and that's with everyone and all our electronics gear in the same building.

You say the environment was "functional". For you, did the advantages of having the larger applicant market outweigh the disadvantages?

For me, it's hard to say because a lot of other issues led to problems. The project had poor management overall, and we were also dealing with language barriers and vastly different timezones. I think in our case it wasn't worth it because were located in San Jose and there was plenty of talent we could have hired locally.

So, if you're based somewhere crawling with tech talent and the nature of your product already attracts it, then it very well might be a net-negative to operate your team remotely.

Otherwise, I think you'll find it's worth navigating some of these setup issues to be able to hire the best from wherever you're based.

Fair enough. We are in Orange County (CA) so there is enough tech talent here to justify keeping our candidate search local. Thanks.

I'm in the Bay Area and would love to work remotely on hardware/firmware. Let me know if you'd like to give it a try - email in my profile.

I have all the usual stuff you'd need to develop / debug hardware and would be open to fly on-site every now and then too.

What about having your test hardware hooked up to a development machine, that folks can VPN into? Is that even feasible?

For some projects, maybe, but not the majority. It's not a bad idea. If we invested in such a setup, it would help with unit testing and such.

Reply on news.ycombinator.com