betasam's Journal: Delivery and Deliverance

I have been creating software components (mostly system software), and managing teams doing the same. Whenever I was delivering a complete platform (Kernel+Drivers+Utils) with a product, I found that the process was much easier. The end product was easily taken in although I can't comment about the commercial success. However, whenever the delivery was a source code component that had to be plugged into someone's product I have found delivery very difficult with either complaints or a long time for integrating it usually impacting schedules and future work.

Sometime back I had the experience of delivering a full image that required a lot of comfort with linux systems to a team that had much less comfort. This too took much longer than I anticipated despite READMEs and explicit instructions. The impact of the delay was highlighted by the fact that I was working alone for the platform. Software delivery (in binary form) has in itself been a tough job, with support teams standing by to take debug reports and fix bugs. Delivering source code to those graduating to linux or switching platforms has always delayed. I believe that the best way of delivering any software component (outsourced or remotely worked on) is to have a partner at the receiving end, a shadow of the creator or be present at the delivery site. I have been in touch with a few friends on teams that make delivery, and I see the trend of on-site delivery of software. This seems to be a common trend in the software industry where most off-shoring requires an on-site presence. I would definitely like Deliverance from the issues created at Delivery to come from a different quarter. More Software Engineering research to work out a much better way to send and integrate so that Remote working (be it offshoring, or working from home) becomes much more easier than it is right now.