Some thoughts on the costs of software

The cost of software can be divided in a couple of categories. It's not necessarily getting better with new emerging technologies (it's just toooo confusing). But following a couple of principles, you should be able to make up your mind soon enough and go for it. ( Don't get enthusiastic with enthusiasm of others in the next big thing that is going to change the world ). To categorise some costs in software:

- Procurement ( licensing and support )
- In-house development and maintenance
- Open Source adaptation
- Mixing requirements with choice
- Stupidity
- Uncertainty

Each of the above topics has a certain 'sillyness' associated with them that may drive costs higher in your company or increase effort for your department.

* Procurement: When I was working for a very large company, the intention was to reduce overall cost by applying a 'one-size-fits-all' strategy in an attempt to reduce licenses. The famous example was taking everybody off MS Outlook ( that came 'free' with MS Office that everybody was using anyway ) and move everybody over to Lotus Notes ( which started to increase the number of licenses required in that area ).
Another item that I think could increase your costs is the question of 'support'. We like to think that 'if this happens or that', we'd better be able to call somebody to come and fix it. This is why you pay 'ongoing support' for some packages or a 'license fee' that comes with a certain degree of support.

In reality, I've seen that it is very rare that companies make a big fuss about problems that occur in the software, unless it sits at the very core of their business ( like billing services or where their customers need services from 3rd parties that break down ). In practice, there is not much pressure to get software updated and they carry on with the bugs anyway. The most bizarre case I heard was with Lotus Notes and IBM, where a patch for a severe defect in Notes was actually 'licensed' to the customer to solve the defect. ( meaning the company started paying for using a patch for software ). That was the weirdest thing I ever heard of.

How this relates to opensource is clear. There is no 'widespread confidence' that opensource can satisfy needs for ongoing support. But according to the above, if the company is never ready to sue the other party anyway, or is never putting pressure, why pay for the license/support and why not take a suitable OS solution? The main reason is that companies like to feel that they have this stick behind the door...

* In-house development and maintenance may become costly if you're not careful about dimming enthusiasm a little bit of enthusiasts that are roaming around continuously looking for new tools and technologies to use, the only reason being is that they have never used it before. To deal with this is a bit tricky, because you certainly do not want to de-motivate staff by refusing every little new thing ( plus the new technology may indeed be promising ). The big idea however must always be that you're in a particular profession that must provide a 'best-of-breed' service to other people. This means going with technologies and ideas that provide most value to your clients.

Other issues involve policies for re-use. Storing regularly used frameworks and making them easily re-usable, developing an in-house knowledge base where people can find information about API's and development experience geared towards working in that particular company in that particular culture.

* Open Source adaptation is a great way to reduce costs for certain projects. Especially for building Java nowadays it is possible to rely on Ant, Eclipse, XDoclet and various other packages that help out in getting software out there quicker and at better quality. What I see, which is related to the first point, is that open source software is hardly ever used in 'production systems'. A shame because many packages are certainly up for it nowadays. The difference here is sensitivity to 'marketing' and the idea that commercial software is better quality and better serviced than opensource. The only difference I see is visibility ( marketing ).

* Mixing requirements with technology is an interesting one. This one is where an analyst or manager writes a Requirements Document that states languages and technologies to be used. This is very wrong and development should fight this any way they can. Language and technology choice must be done in the architecture or design stage.

The manager may have had good experiences with a certain technology and assumes it will equally perform in the next project. Mixing requirements with design/technology choice is a bad thing. Always go back to the writers to find out *why* something has to be developed using tech A or B. There may be reasons for it and there may not be. However, I also advise to be careful, because you may be opening a snake-pit there of 'politics' and 'excuses'. ( don't necessarily do this if you're Junior, find out from Seniors first what their take is on the situation :)

* Stupidity? well... This is where a new IT manager comes in that may or may not have a degree in computer science. With the new manager in place, the first thing he orders is to move all databases from brand A to brand B. Or specifies that all new development must be done in C++ by standard, or Java. Some standards make sense ( size of project, web/gui/cmdline/back-end against favoured solutions is a good chart to develop ). But numbly favouring a particular vendor or technology without any background and requiring that existing systems be changed to comply is a very bad thing to go for. ( Trust me, I've seen it happen :)

* Uncertainty comes up in situations where requirements of size and scope are not entirely clear. (How is the app going to be used and for how many users). Depending on your architecture, you may end up with very unpleasant surprises down the road when you discover that suddenly people thought this would be a great system to roll out to 5 million users, rather than the initially intended 10,000. It's better to have this information up-front, because the chart of 'size against favoured solution' would have brought you different technologies, development patterns or vendors than you may be working with for now. ( word to developers: Be a bit wary about these 'quick' requests and 'no problem' statements. If you're careful and as is said in Holland 'Look the cat out of the tree', you'll be already more or less prepared for these situations ).