Navigating Challenges in Implementing DPWS for MFPs

Image source: Briss

Backgroud

It may be surprising to learn that just 15 years ago, purchasing a printer/scanner required installing driver software from a CD/DVD. To enhance user experience, companies introduced various improvements like Plug-and-Play and Universal Plug and Play (UPnP). Around 2007, Microsoft began implementing Device Profile for Web Services (DPWS), which aims to streamline the user experience for multifunction peripherals by enabling devices to be dynamically discovered in network browsers.

DPWS is a Web Services profile that allows plug-and-play for networked devices. A PC or other device can detect DPWS-enabled devices on a network, then discover and invoke the Web service functionality each device provides. Its purpose is similar to UPnP, although it employs a Web Services model.

My Experience

Eight months into my first assignment as a bilingual engineer in Japan, I was the onsite technical lead responsible for implementing the DPWS Scan Service in MFPs (Multifunction Peripherals). Everything was going smoothly until integration testing began. After connecting a Windows Vista beta version PC to the MFP on the same network, Vista successfully detected and installed the MFP.

When I opened the scanner application, I was able to complete the first scan after a couple of tries. It was an awesome feeling. However, my joy was short-lived. Out of 25 high-priority test scenarios, 6-7 started failing. My customer was planning to visit the Microsoft Partner Conference in Redmond next week, and it was not a good situation to be in.

In three of the failing scenarios, it was our team’s bug, which we quickly fixed. However, in the remaining scenarios, it seemed that the issue was not due to our code. Thanks to Microsoft’s developer tools, we were able to investigate further.

My customer traveled to the US for Microsoft Partner Conference as planned, and for the first couple of days, there was no communication from him. Late on Thursday evening Japan time, I received an email addressed to me with both the customer company’s and my company’s senior management in CC. The content announced that he had seen a demo of a competitor’s MFP (Japanese), and all our failed test scenarios worked flawlessly. He asked me to explain.

I panicked and felt terrible, wondering what mistake I had made during debugging/testing and feeling that I had let my customer down. I felt like resigning and taking the next flight home. I could not sleep the whole night. The next day, I went straight to my onsite manager and told him about the issue.

I was expecting a reprimand, but he told me that he had read the email too and asked me one question: “Are you confident that these are not our defects, but OS issues?”

I told him yes. Even the night before, I had re-tested all the failed scenarios and confirmed that these were OS issues. He advised me to acknowledge the customer’s email, mention that based on our testing, we were confident it was due to an OS issue, and ask if any hotfix had been applied in the demo machines in Redmond.

Later, we learned that our competitor was a Microsoft platinum partner and had received a hotfix that resolved those failed scenarios.

Lesson Learnt

To this day, those were the toughest days of my IT career. They taught me the importance of thorough testing and documentation, and the value of standing up for team members, as exemplified by my onsite manager.