Showing results for 
Search instead for 
Did you mean: 

Software on Silicon Blog


Eat Your Own Dogfood

How I Supported the CEO and Lived to Tell the Tale

Every now and then something a bit unusual comes up. I’m based in Austin, Texas and Hassane El-Khoury, our CEO prior to the Infineon acquisition, was here too. One day, before the current pandemic stay-at-home orders, I received a request to handle an urgent situation. Not realizing what the issue was, I immediately asked for the details. What I heard was definitely not what I was expecting. “Hassane is having trouble with GitHub. You’re in Austin. Fix it.” As luck would have it, I also manage the company’s GitHub presence. So right guy, right place, and began my adventure in providing direct support to our CEO.

It turns out, a subtle mistake when setting up his remote repo on GitHub caused a litany of issues. He reverted a change which corrupted his Eclipse workspace metadata, and of course everything broke. However, that wasn’t the root cause of his problems. As we dug into this particular issue, we discovered something more serious. Our tools did not do a good job supporting his use case. You could get it done, but it wasn’t easy and needed significant workarounds.

ModusToolbox software is designed to be flexible and adaptable to your workflow. It is based on the idea that you’re going to start with something from us and consume it. That works very well.

Hassane’s use case was the next step down the road. “OK, I did that. I’ve changed it and made it mine. Now I want to share it. I’ve got a couple of collaborators on my project and I want to put it on GitHub.” A completely reasonable and normal next step in many projects. Problem is, it didn’t work.

Keith, one of our senior engineers, was assigned to help so that the development team could see what I was seeing. I literally looked over Hassane’s shoulder. We found a few things that, if changed, would significantly improve the usability and experience for our customer, even if our customer is our own CEO.

Once Keith and I got him up and running with the workarounds, the engineering team fixed what we found. That part is normal. Part of my job is to handle escalations from the support team, especially around tools. Sure, this time the escalation was our very own CEO, but the process is still the same.

Among the things we discovered was a lack of help. He couldn’t solve this on his own. So, here you go: How to Share a ModusToolbox Project via GitHub - KBA230107.

The other fixes are included in ModusToolbox 2.1. I swear Hassane was one of the first people on the planet to download it after it was released! He called that same day to get working on it. Hassane, Keith and I jumped on Zoom to put it into action. Keith and I mostly just watched over his virtual shoulder as he went through what he needed to do to set up a remote repo and incorporate his code. When it was done, he says “Cool, that was straightforward. I’m good to go, I’ll let you know if I run into problems.”

I haven’t heard from him since.

We should have caught all this in the first place, but who among us is perfect, right? The real trick is getting better. So how did we catch this? This is the best part of the whole story.

We eat our own dogfood. Right up to the CEO who uses the tools I help build. That is both rare and awesome! Having the CEO find your problem is, shall we say, not ideal. Having a CEO who can find problems - that is as good as it gets. I'd love to hear your stories of eating your own dog food! This was the most fun I've had this year.




HI James

Glad to hear that your CTO dive deep and understand that without software it is hard to sell chip, just from the spec on the datasheet. And that software is not just what we uses to do - not just a GUI that show how awesome you power down mode will do.

You have to develop frameworks that has the flexibility to work with all your chips - your backlog and the those on the roadmap.

That is not an easy task. And if you think you just need the best IT guy from you IC design team you are way off.

But we are lucky - the last 20 years of software development has been done in a very open environment thanks to Linux and Google, it has lowered the entry level and is the key driver for the exponential development environment that we are in.

With very limited effort I can grab the Android Bluetooth stack and port it to my favorite microprocessor to do a audio streaming application - do the frequency equalization using high level signal processing abstraction direct on the microprocessor is stead of embedding DSP or FPGA to my system. - And build a web based UI to control and tune the system - real time.

All i need are solid framework like Modustoolbox and ESP-IDF and cutting edge commodity microprocessors.

And we will always be moving target - continues integrating - developing and releasing on system that has been release so that CTO can find the bugs and we can get it fixed.

Regards Jørgen Jakobsen, Denmark         


Hi Joergen! Thanks for your insight, I agree 100%. "You have to develop frameworks that has the flexibility to work with all your chips - your backlog and the those on the roadmap."

I think it's the "moving target" that's the real challenge. I have a couple of articles planned to talk about that. The way we're handling this on GitHub I think is a big help. If we have to do break backward compatibility for the "roadmap" (when a new chip shows up), we can rev things and still keep the older rev available for the legacy chips.

I'd just like it to not be the big boss who finds the problems

Cheers from Austin TX. I hope you are safe in these challenging times.

About the Author
Been there, done that. Mostly. For software tools and developer support.