In today's world of software development, most large products use input components from a variety of sources. So, if you are building a new version of a video editing application, it tends to incorporate a large number of external components - some of these dealing with the ability of read views of different formats and codecs, then there will be the components dealing with burning what you created to a disc for which there are additional components, and so on. In all such cases, it always makes sense to use components that have a specialized function rather than try to build it yourself. In the current case, see how it difficult it would have been if you team was trying to write code to read the different video formats in existence today. You would have mostly given up trying to do such a thing. Even otherwise, there are other components that are used - if you are working for a company that has multiple applications, the company would ensure that common components are built at one place and included in the various application (this is the most efficient way of building such components); for example, you would be using a Help system, your application would be using Installers for installing the application onto the machine, you would have having a licensing system, you might be having a common system for generating the UI of the application, and so on.
Now, this sounds like the most efficient way of building such an application. However, for somebody who has been there and done that, there are many slips between getting a robust system in place that integrates all these components in your schedule. For example, one of the biggest problems that we used to run into was the quality level of these components. We had a contract with one of our component makers who would supply us a component (and they used to supply the same component to our rivals and other applications in the video space). From time to time, we would run into problems where these components would not be delivered in time, or where we would have to reject the quality level of the component, because we found a critical bug.
Why were all these problems happening ? I am talking about a situation which used to happen a few years back, and it was extremely frustrating. However, it turned out that we had been working with them for many years, and we had never really tried to set some kind of process for these deliveries of the component and hence all the problems. So, we started out by working the timelines for when we need these components, and then did more analysis while working with the development and testing teams about the level of testing that we expected from the vendor end. Now, all this was being done from our end, and we had only aired some level of frustration with the vendor, but never really got in a problem solving discussion.
We set up a series of meetings with the vendor, talking them through what the current system was, pointed out the problems it was causing for us (and for them as well, since when we rejected a version of the component, it would have meant more effort from their end as well). We talked them through some of the solutions that we were looking at, we got our development and testing teams to have discussions with their respective teams on a regular basis. Now, this was not a magic bullet; they did not do everything that we had asked for, and in some cases, it meant that we had to pay around 10% more because of the extra effort on their side. However, in the end, we had a more strict agreement for the delivery of the component along with a quality level, and this allowed up stability in a part of our schedule, which was well worth it.
Now, this sounds like the most efficient way of building such an application. However, for somebody who has been there and done that, there are many slips between getting a robust system in place that integrates all these components in your schedule. For example, one of the biggest problems that we used to run into was the quality level of these components. We had a contract with one of our component makers who would supply us a component (and they used to supply the same component to our rivals and other applications in the video space). From time to time, we would run into problems where these components would not be delivered in time, or where we would have to reject the quality level of the component, because we found a critical bug.
Why were all these problems happening ? I am talking about a situation which used to happen a few years back, and it was extremely frustrating. However, it turned out that we had been working with them for many years, and we had never really tried to set some kind of process for these deliveries of the component and hence all the problems. So, we started out by working the timelines for when we need these components, and then did more analysis while working with the development and testing teams about the level of testing that we expected from the vendor end. Now, all this was being done from our end, and we had only aired some level of frustration with the vendor, but never really got in a problem solving discussion.
We set up a series of meetings with the vendor, talking them through what the current system was, pointed out the problems it was causing for us (and for them as well, since when we rejected a version of the component, it would have meant more effort from their end as well). We talked them through some of the solutions that we were looking at, we got our development and testing teams to have discussions with their respective teams on a regular basis. Now, this was not a magic bullet; they did not do everything that we had asked for, and in some cases, it meant that we had to pay around 10% more because of the extra effort on their side. However, in the end, we had a more strict agreement for the delivery of the component along with a quality level, and this allowed up stability in a part of our schedule, which was well worth it.
No comments:
Post a Comment