What do vendors really sell?

The biggest argument against homegrown software, and by extension, open-source software, is that it isn't professional. To my mind, these fears are perfectly justifiable, but I suspect my concerns differ from the average administrator's. Typically, people think that in-house developed software must have poorer programming and infrastructure than the software developed by "business professionals." I have certainly never found this to be the case. Beyond a general sense I have (but cannot really prove) that business code tends to be sloppy, inefficient, and poorly documented, I can say this much against vendor software:

• Vendor packages means server-side bloat. Vendors do not know your environment and as a rule they will not adapt to it. Rather than try to understand how you have set up your environment, they simply state: "This package must live on its own server with its own database. If you don't accept this, we will still sell you the product, but we won't support it." The result, of course, is that you have incredible redundency in your server set ups--whole systems set up to run a single application in a void. This is expensive, hard to maintain, and only gets worse as time goes on.
• Applications don't communicate. Vendors don't care if the HR system you bought doesn't talk to your Employee of the Month calculator. The way the code is is the way it is going to be.
• It is unwieldy. Once it has been created and put in a can for delivery, you must wait until the next version before you can expect any improvements. That means you must live with bugs, live with outdated technology, and live with limited features until the next big roll out becomes available. Because canned products are typically very large products that must take into account many, many clients needs, the wait can be a very large one.
• Vendor software has no great incentive to create quality products. They are interested in making money. They need a product that will rival their competitors, but if their competitors aren't doing a better job at meeting an individual client's needs, then they have no desire to do so either.

Does this sound like a scathing review of vendor software? Well, it isn't really. The fact is that the above problems are problems for any software no matter how it is developed. The difference between vendor software and homegrown software is the level of expectation. With vendor software, everyone knows that they aren't going to get a custom-built, highly tweakable, "special orders don't upset us" application. And this is where vendor software comes out head and shoulders above most locally grown software: the expectation level is such that it actually gets done. The product may be poor, it may not solve the problem you wanted to solve, and it may end up costing you far more than you originally agreed to pay.

No matter. When you have a vendor (or the vendor has you), you always have a plan. You have a start date. You have at least an idea of costs. You have an (at least tentative) end date.

So what are the vendors really selling? Their software? No. They are selling their organizational skills. You aren't the first customer they've sold their product to. You are going to present some new problems for them, but 90% of your problems will be old hat to them. They know how long most tasks are going to take. They know how much it will cost. They can present the easily-digestable timetables and expense sheets to the powers-that-be that make them feel that everything is going as smoothly as possible.

Can home grown software be organized like this? Of course--but it doesn't just happen. Home grown software is usually built by technologists--not project managers or accountants. Can your database group's manager tell his boss everything it would take to move from SQL Server to Oracle? No. Can your network manager tell her boss how many total dollars goes into maintaining her backup system? Probably not. These people are too busy keeping these systems running to stop and calculate the costs and labor. When they are tasked to develop software, their technical skills are probably entirely adequate. But can they communicate with the client? Can they project costs? Can they meet deadlines? Can they tell VPs that they just can't deliver something the way they want it? Not and keep their jobs, they can't. The way of handling those kinds of issues is with project managers that can produce budgets, timelines, and documentation. That is a completely different skill-set than what you can expect the average technologist to possess. As a result homegrown software can be a nightmare to move to production.

So, how do you suppose most homegrown software comes into the world? Sadly, it usually arrives at a time when administrators are feeling particularly cheap or when they are feeling particularly rushed. Are they feeling too cheap or too rushed to get good software? No--they still want that--they just can't afford the time for good project management for the task at hand. It is at this point that they offer such useful phrases as "just get it done." The technologists involved usually recognize that they are in an unpleasant situation, but they are not project managers themselves and so can only plod on. The result is often an effective short-term solution, but because no project management was allowed, what is produced soon shows the short-sightedness of its design and within a few years (months?), it is already limping its way towards a vendor solution.