A recent FCC report blames Google’s software development process for its WiFi privacy breach. How stable is the process for semiconductor IP creation?
The findings were shocking! An FCC report concluded that a lone engineer was to blame for Google’s most controversial breach of online privacy. The report highlighted “apparently serious shortcomings in Google’s software development process.”
“These include claims from Google engineers that they were free to add code to a project without supervision if they thought they “could improve it”, a failure to follow through on a recommendation to have the privacy matter screened by one of the company’s in-house lawyers, and the pre-approval by a senior manager of a document before it was even written.” – Financial Times
This is simply shocking! How could these horrendous missteps have happened? Perhaps to meet deadlines, improve product performances or the morale of the developers?
Certainly these shortcomings never happen at other software development companies! After all, what manager would approve changing the code to improve performance? (Answer: Almost any.) Or what engineer or manager wouldn’t enjoy meeting with legal beagles to explain any technical issue? (Answer: Almost all.) And what manager hasn’t pre-approved some paperwork to get a project going or back on track? (Answer: The great majority.) In case of documentation, the FCC report doesn’t indicate if the document was a software specification, user guide or product brochure.
My somewhat sarcastic point is that all of these shortcomings in Google’s software development process are common practices – sometimes even best practices. Anyone who has led a team of software developers in the real world – as I have – can attest to the occasional transgression to meet deadlines, stay on budget, improve the product or just get the job done.
Even the most serious allegation in the FCC report seems inconclusive. The search company originally blamed the privacy breach on a lone engineer who intended to write software to collect WiFi network data, not personal information. The validity of that claim should be easy enough to discern by looking at the code. A peer review of the software would quickly confirm the developer’s guilt or innocence.
Blaming the software development process is a tried-and-true way to divert responsibility from management. Neither the FCC report nor Google’s responses provide much insight. One is tempted to ask how Google measures the maturity of their internal software process. Do they use a standard Capability Maturity Model Integration (CMMI) approach or something similar? Searching Google for the answer is frustrating at best. Try it.
Some readers may wonder what all of this has to do with semiconductor IP development. Software development challenges are headaches faced by all engineers, programmers and managers – from applications and middleware down through firmware and even – gasp! – chip specific RTL. Have you ever wonder if a method exists to evaluate the software development process of semiconductor IP? Not the verification of IP functionality, but the validation of the development process itself?