Jack Ganssle on managing embedded projects at ESC Boston

9/21/2010 2:00 PM EDT

I am not a firmware engineer and I am not a manager (I'm actually an analog engineer). However, I am a fan of Jack Ganssle and his past writings. So when I saw he was doing a day-long session at ESC in Boston, I figured it would be worthwhile. I was not disappointed.

Jack put together a full-day presentation on the management of embedded software projects. Boring for an engineer, right? I thought it might be but wanted to learn more about the big picture of firmware development and thought I might get it there. If I am to take on projects for myself (professional, hobby or otherwise), I need to know how to manage my number one employee – me. In the end, project management is not an easy subject but one that Jack specializes in on a daily basis. The topic matter spanned broad topics, such as project requirements, to very targeted ones such as helping managerial reports advance their own careers. From an engineer's perspective, it was encouraging to see 30 managers at various levels of their careers, all looking to improve the working conditions of their employees; and if you don't think delivering a project on time is a boon to a happy work environment, perhaps you should sit in on a Jack Ganssle lecture sometime in the near future.

The material was hardly limited to management tidbits. If anything it was more about project management and the actual firmware development than people management; this included breaking up coding for efficiency, breaking up processing power for efficiency, use of an RTOS (or other commercial off-the-shelf software) for efficiency and really anything relating to a high level view of decision making and getting a worthwhile product out the door. His point was that it is the role of management to not necessarily make all these decisions, but that it's critical to keep an eye on these technical subjects and at least make sure they are addressed. Jack even delved into the use of consultants/outsourcing and the many pitfalls that are often not realized.

The focus of the entire session, while not outright stated, seemed to be "realism". A sampling of these unknowns could be generalized to:

• You will never know the exact date that a project that will be done.
• You will never develop a project without any bugs or hitches during the process.
• You will never deliver every feature that everyone wants without any impact to schedules.
• Adding developers will not accelerate the project schedule linearly.
• If you're upper level management you will not like a realistic and relatively accurate estimate of project deliverable date. And even if you don't like the date, moving it closer will only stress out your team and deliver a substandard product.
• No one cares more or should do more to preserve the backups of the source code than the manager of the project. A stark reality and something not often discussed. Sure, everyone on the team should be doing their routine backups and checking the integrity of said backups; but if the buck has to stop somewhere, the reality is that management needs to take control of backups and make absolutely sure the code is preserved in times good and bad.

Many of these statements may be obvious to managers of past projects but they often are not outright addressed. And why not? Isn't honesty the best policy when analyzing these situations so that the managing of an unwieldy software project can move out of the realm of art and into the realm of science? Shouldn't projects be delivered within a window of time with a known confidence level? What would that be worth to your organization?

Another undertone of realism, yet one that deserves its own space, is the cost of software. This is often the concern of managers that extends up the chain to the upper level executives. And it is often completely disregarded other than the mantra of "yes, there is some cost" and "no, we don't have time to take preventive steps that have been proven to lower these costs." Jack focused many different parts of his presentation to techniques (in management or as an engineer) that would save time and cost. Bug rates, code inspection, coding standards, daily testing, wideband delphi estimation and many others; all of these may seem to be technical concepts, but it often falls to the managers to monitor outputs and keep project teams on track with following these proven methodologies.

For those engineers out there that think of management as "the other side", Jack offered many interesting anecdotes of "boss management." As an engineer, hearing the perspective of project managers that also have their own boss to report to is something I don't often think about; I also found Jack's advice funny about how to effectively "manage" their boss! One example that comes to mind revolves around project requirements (one of Jack's favorite topics). The correct answer is not a simple "yes" or "no" when asked if a new feature can be implemented; it is instead, "let me look at the cost and time impact and get back to you." Another might be in regards to the above paragraph about long term focus on projects. Managers need to fight for the success of their project and insist that proper coding methods are used, even in times of stress. When faced with deadlines and those above you shouting for a finish date, this can be a difficult thing to do! Again, from an engineering perspective it was a different viewpoint on the daily battles that managers need to fight on behalf of their team.

One of the most refreshing things about this session was the participatory nature of the day. Jack welcomed many of the audience's comments and often there were great back-and-forths between the members of the crowd. These additional real world examples for a non-manager such as myself really gave credence to much of what Jack was saying. The level of experience already in the room was quite apparent and the fact they were looking to advance their knowledge even further was quite impressive.

So, would I jump into management tomorrow? No, not quite yet. I have a few more years of technical work in me. However, listening to Jack Ganssle and the many participants of this session talk over wrangling a software project to the finish line – on time and bug free, of course – brought a sense of perspective I had never quite felt. I'm glad I had a chance to listen to it and pull some own techniques for my daily work. While going to ESC Boston (or any ESC) on the session-only first day may be a hard sell to your boss, attending sessions such as this make it all worth it.

Chris Gammell is an analog engineer and writer from Cleveland, Ohio. His latest project is The Amp Hour, a radio show devoted to electronics.