How do hardware and software engineers talk to each other?
This is the extract from a recent conversation on LinkedIn between power electronics engineers of all different flavors. It sums up beautifully the issues between hardware and software engineers in digital power electronics control developments. (Names shortened to protect the innocent.)
D. H.
‘Y. & A., I have no idea what half of the acronyms are which you (software) guys are using but, I get the feeling from A. that optimized C (whatever that is) is slower for a multiplication than assembly. Y. seems to be saying that a particular version of C he likes creates a faster multiplication.
So, I’m just left confused. Which is it?
I’m from the 80’s. This is when a multiply was a simple, understandable add-shift, add-shift,….repeat 8 times and you’re done. Many modern processors have one command – MUL AxB. Nowadays, digital guys are telling me that this method is so complicated. Why? Why is a simple multiply so complicated now when 30 yrs ago it was routine and easy to understand?’
Hamish from ELMG Digital Power
‘D. H. – there is a really big disconnect between the software able guys like Y. and the non software able guys ( I am guessing you – sorry if I am wrong). It is often that sort of cultural mis-alignment that causes lots of issues in the development. We fix the cultural alignment for companies sometimes. And its a process and there isn’t really an easy road and, I hate to say it, some teams go under doing it. We created our digital training course as the result of a customer R and D manager asking us when we were in the middle of a fix up “How could we have avoided this?” ‘
D. H.
‘Hamish, You’re right about the cultural mismatch. (Yes, I’m not a software guy). My post a few days back concerned a software guy who had trouble communicating to me why his code was lengthy and complex, and I had trouble communicating with him as to why my view of a simple look-up table isn’t valid anymore. Maybe D. E. was correct, a “good” programmer should know how to deal with math.
Are these type of issues going to be addressed in your course?’
Hamish
‘D. H. – In short yes. The slightly longer answer is. In the course we cover this culture issue both explicitly and implicitly. Team culture structure and organisation for digital power controllers are really important to success. And even more critical to sustained success when the “fix up” consultant has left the building. How we address this group culture issue in the course is by showing the attendees how to setup the conversation and documents so that the different types of people all can understand and contribute. Understanding and empathizing with the software engineers ethos, and what he values, is key to the power electronics converter engineer being able to do her job. And likewise. Engineers are technical people – which often speaks for itself in team dynamics. In the course we cover how matching the system partition to the team partition and to the system documents gives you a really good shot at success.’
Y.
‘D. H. , It is a known problem where software get hard time from hardware and vice versa ,many project fell because of this issue
I solved this problem long time ago when I decided to learn software (computer science ) after a good career as a hardware designer and since then all the hardware and software issue solve internally :-)’
Hamish from ELMG Digital Power
‘Y. is right that you can just learn it all; hardware, software and control. The problem comes when you leave the job and the team have to do it without you. Super engineers are great until they leave the team. And not every company can employ one and most companies prefer a team to manage this risk.’
Come to the course in Camarillo, California, August 22 through 24 and we’ll show you a good approach to dealing with this cultural mismatch.