Why is Software Organic?

We all need to think of software as being organic.  Not in the 'I live, I eat, I breathe' kind of organic material, but definitely in the 'I don't run forever without some tuning, and need to be nurtured from time to time' type of organic. Particularly of interest in software development are websites, which happen to typically have a large quantity of dependencies and 3rd party plugins.

This article is probably common knowledge for our larger clients which have already been though the paces, but as a reminder for them, and a tip for new start-ups to help keep everyone successful, remember this phrase: "After project deployment, there will be a requirement to regularly spend human hours cultivating and maintaining a project, indefinitely."

A maintenance package, or pricing the hosting agreement appropriately, should be used to help with the need to regularly maintain, upgrade, and modify the website over time.  A typical smallish open source CMS website (WordPress for instance) may take as little as an hour or two biannually to maintain, while larger sites may take the same amount of time as often as weekly to maintain.  This is a broad range to determine for sure, and usually takes a good deal of experience to get right.  Perfectly accurate calculations aside, that is still something that needs to be scheduled and planned for in advance (or as experience goes, most things not invoiced will not be prioritized, and will end up becoming even more costly for all parties in time).

The cost of scheduled software updates and regular maintenance is minimal compared to the cost of exploits or failures which regularly happens with insecure or out of date packages and software.  When those hacks or plugin compatibility issues do happen because of out-of-date packages, the cost in business image or downtime due to hacked or broken websites will typically be much more than the costs of providing a maintenance over time.

To keep everyone from starving, we recommend that there is a bit of a cost factored in the regular maintenance of websites. This should be a residual cost (monthly/annual/etc) clearly indicated. We've seen plenty of companies bake the cost of the residual maintenance into the initial development, and that may work for some, but in our experience this usually ends up with a website that isn't being maintained after the website has become a bit stale of updates and the initial investment has run dry.

Further Details

Rarely is a good application ever completed.  It's interdependence on libraries, ever changing compliancies, protocol features, operating systems, platforms, and desire to become more feature-packed keeps the application in a stage of 'reasonably stable functionality'.

As software includes new features or enhancements, the surface area of total potential issues expands.  This larger surface area of the application directly relates to a number of inadvertent side-effects such as: Additional attack vectors available for compromise by bad actors, complexity to performance tuning, total resource consumption required, reduction to stability, increase in time needed for QA testing, etc.

Complicating matters further, as 3rd party or even internal libraries are upgraded, the application surface area is further enlarged (though typically more constrained).  Backward compatibility is another area of issue as well, many times with KYNGIN we have created meaningful updates, but to prevent outages we had to continue supporting past codebases for weeks or even months before we could fully migrate to the new.  Having multiple codebases laying about in production widens the surface area as well.

In the end, the goal should not only be to get the job done, but get it done well in a sustainable manner. In regards or software being organic, a quick way to do the job poorly is to not be able to afford to update and maintain the product after deployment.

Recommendations

Because all software is organic by design, and much of it is interdependent on other softwares, we all probably need to have a little compassion, understanding, and respect for just how complex all of this is and how well it all does work together.  Even with how frustrating it can be at times when a random update breaks large amounts of the internet or when a new software feature demands from us a bit of time when we have to learn something new.

All technology companies use a lot of open source and proprietary software to stay competitive and put food on the table.  Much of this software used to save time and help companies become more efficient has been made publicly free to use, with little direct compensation for its creation.  To get us all here, countless contributions have been made by developers, funded by personal ambitions, community donations, and corporate interests that largely have a similar-minded agenda.

KYNGIN software stack itself is built on top of hundreds of open source products, all of which operate in synchronous harmony (usually :P).  We're incredibly humbled to have the customers we have, and the confidence they have in us, but aside from our hosting platform and software stack, we can't forget this all runs because it utilizes tens of millions of lines of source code, most of which was provided entirely free of direct cost to us.

Please feel free to donate to the wikimedia foundation at this time.