Whenever my television, telephone or computer needs a software upgrade, I call upon the only person in our household who I can be assured will accomplish the task - my son. It's not that I am incapable of performing such a job, but I know that in the time it would take me to do so, my son would have the system up and running a lot faster.
Now of course, I have absolute faith that my son will be able to deliver the goods at the end of the day. Unfortunately, like most people who take on such a responsibility, he often seems loathed to explain, after the fact - of course-exactly what he has done to achieve the necessary goals.
While such scenarios are commonplace in households around the world, they also occur in the offices of many smaller original equipment (OEMs) manufacturers. Especially those that develop vision inspection systems. In these organizations, engineering managers must also allocate the responsibilities of developing, designing and commissioning vision systems to their colleagues who have the necessary experience in electrical, mechanical, optics-and most importantly - software engineering.
However, when building up a smaller company to develop such systems, engineering management should be aware of the minefield of issues that they may face when dealing with software engineers. It might be fairly obvious what a hardware engineer does on a day-to-day basis, but with software engineers, there are more challenges that need to be addressed.
One particular software engineer, for example, might well write code to solve many specific vision challenges, but it might take him or her days to do so. While time might not be an issue with the software computer issues that I throw at my son, in an engineering environment, time is money. Unfortunately, many software engineers - especially new graduates from college - appear to have no concept of this idea.
But there are worse issues. When creating software for a specific vision system application, a software developer may be completely unaware that developing adequate code-rather than the very best code-to solve the problem is perfectly acceptable. In such cases, software engineers have been known to wrestle for several days - completely unnecessarily-to meet their own ambitions of optimizing the code to their own personal goals, rather than one that meets the specific needs of the company.
Worse yet, many software engineers appear to be loathed to explain the rationale behind their coding philosophy. Could it be that they are hiding behind a cloak of black magic, rather than being called upon to actually document the rationale behind the coding approaches and the code that they have written to solve a specific problem? I know more than one engineering manager who believes this.
[email protected]
