At work we support a suite of applications. We bundle two of the main applications into one install program. Historically this install program has been about 17 Megabytes in size. There are a lot of business rules implemented by these applications. So some of our DLLs are pretty large even in release mode. But all of this bloat is not due to our custom code. We ship the install of the Microsoft Data Access Controls (MDAC) with each of our installs. That alone adds over 5 Meg to the install size. So far the customer has lived with this software install size. I know they must be having some pain because they push the install out to a lot of workstations.
This year we are moving to a new version of Visual Studio and the Oracle client. The move alone should not require a larger install program size. However we gained a Visual Basic Dot Net developer on out team. He has been struggling with learning the Visual C++/MFC programming that is required by our applications. It is also a chore to learn the business rules of the software. So when given the opportunity, he wrote a new piece of the software for our system in Visual Basic dot NET. I don't blame the guy for this. He was finally happy once he got back to doing what he knows best.
We gave the new developer the task of upgrading the install package for our software. Having added a Visual Basic dot NET component, he needed to ensure the right version of the dot NET framework was installed on the target platform. So he added the dot NET framework to our install program. All of a sudden, the 17 Meg install program has blown up to a 44 Meg monster. We have only pushed the new install out to our internal test team. But I expect there to be an outcry once the user community gets wind of this.
I know in this day and age, memory and disk space and bandwidth are plentiful. However users still expect installs to happen quickly. And they do not want complicated install packages. User has never liked install programs that are not fully stable. We might be heading into darker waters by ramping up our install to include the dot NET framework. The jury is still out on this. The real heart breaker is that we really did not have a solid need to do this. It was just due to one developer that was having trouble with our current software language and platform. I guess this is just life.
