There have been many papers, studies, books, etc. on the high cost of developing software.
What does this even mean?
When we say software we typically mean a software product to sell to a market or a system to increase productivity. In both cases doesn’t the customer have some idea of the cost and potential value before the project is initiated?
If the initial estimated cost versus the expected value (the ROI) isn’t high enough the project would never be started. In this case you could certainly say software is too expensive or simply it just doesn’t make sense.
On the other hand, if one knew a software product would cost $1B to build but would bring in $5B in guaranteed revenue the software would not be called expensive. You would call this a “no brainer” not expensive.
instead of saying “software is expensive” it is more accurate to say software often costs more than expected and the value hoped for is rarely received. These are different problems.
The factors affecting cost expectations and software estimation in general are very complex. There are again many papers, studies and books, written by people who have made whole careers talking about this area. Factors can include: miscommunication, scope creep, bad estimation practices, market changes, etc. Projects are even abandoned after major investments because of cost overruns and lack of support.
Studies show us that the bigger the project the more likelihood of cost overruns. This we know from experience. We also know from life that things change, stuff happens and people (users, customers, and markets) are fickle.
On the other side is value. Software systems are notorious for not providing the expected value. Products are too, but perhaps to a lesser degree because markets are so brutal. If people don’t like the product they don’t purchase it. This isn’t the case for systems developed by companies for internal use. The users here have fewer options.
I suspect this has something to do with it. Businesses are working to get better at delivering value on internal systems. Perhaps the development of systems needs to better match that for products.
At SEP we practice lean and agile practices to help address some of these issues. Our practices and approaches embrace change and can in essence break larger projects into smaller ones. When we can use a collaborative approach with the client we also see improvement in value delivery. There is a lot to this, if you want to learn more let’s set up a time to discuss.
Build awesome things for fun.
Check out our current openings for your chance to make awesome things with creative, curious people.
You Might Also Like
