Theories on Long Term Software Viability

I'll try to express here my views on long term and short term software viability and maintainability with a focus on the development process and attitude toward code structure. Hopefully all of this is self apparent.

Software isn't simple. And there are really two minds on how to take software. The monolithic and the functionally decomposed approaches. The theory of monolithic code is that the tighter the code is, the less code you have and the easier it is to maintain. Functional decomposition is the theory that by breaking the code up into little functions you will eventually have to write less code in order to accomplish the same thing because everything is facilitated by underlying functionality.

It's quicker and easier to create monolithic code, or at least, it's initially quicker and easier. As the application starts, the monolithic code base can be hammered out without a great deal of thought. Hence more code can be created much faster because it requires less design. This results in a faster start up time for the software, from starting to 40% of the functionality, it's quicker to deal with monolithic code.

Creating a decomposed code base takes time and careful planning. The underlying classes / libraries need to be well thought out and carefully built so they can be re-used commonly. It takes longer to create a decomposed code base because of the thought and care that must go into code design before writing. Creating new decomposed software is more time consuming from starting to 40% of the functional base.

The second half of development will most likely see the software in functional use. This is where the tables turn because the monolithic code is more truncated and interconnected so more complicated and difficult to maintain. The decomposed code base utilizes functional isolation, hence can be enhanced and tested with greater efficiency and reliability.

I like to think of the monolithic code as 'programming' and the functionally isolated code as 'software engineering'.

Businesses will mitigate the cost of programming by using cheaper staff, automated testing, heavy documentation, frequent release schedules etc. Businesses will mitigate the cost of engineering software by obtaining VC funding or running on high cost business models. Neither approach is perfect but long term viability is obviously more important than the short term viability because all costs are in development, product costs are minimal.

And this is the key to making software. To be successful (regardless of the business model) the focus of building the code must always be building code that is economical to maintain. If this means making the code slower, then buy a bigger computer. Computer equipment is cheap and getting cheaper by the month, whereas human time is expensive and getting more expensive by the month.

It seems that so many areas of business have recognized the efficiency benefits of computing, with the exception seeming to be the software industry.