Code as "Story-Telling" Introduction

Computer code is a language of expression. The core purposes of a programming language are to articulate rules and actions. This expression of the rules is done by people, who have the purpose of sending instruction sets to the computer in such a way as to get the computer to execute a series of tasks that achieve a desired and mostly likely testable result.

But the life cycle of programs goes beyond the extent of the first publication. Some computer code exists in a modified state for over 30 years. This life expectancy of code impacts how the written instructions should be targeted. It is not just enough for a program to be designed so that it does exactly what was desired, another aspect of a programs is its human maintainability over its full life-cycle.

When developing code, the business processes are laid out in documents, these documents amount to the intention of what a program should do. The industry is getting better at producing these documents and putting together scope. The problem with the scope is when a change request is applied to the original scope the request amounts to an errata of the scope. Over the life of development of an item the original intention of the software is greatly modified, and you get errata, of errata, of errata and so forth. The issue comes into play that not even the documentation of the business process adequately defines what the true in production business process actually is.

I sometimes view software through the conceit of the software being the real story of a business and that reading a businesses’ software is an exercise in exploring an enterprises’ set of practices. This story telling view of software, when I am reading someone else’s programs or writing the software myself helps me to get into a mind frame while I am developing to know that there will be (most likely) many other people who will work on a piece of software before it’s useful life expires.

This view, as it has achieved fullness has led me to be slightly discouraged with the state of enterprise software that I have worked with. On the web, the software instruction set is usually just dog-pile. In-line code directives (line by line processed very similar to an old BASIC program) piled into pages that are not even organized well into directories, without even the use of basic programming plumbing like methods. In all the organizations I have worked at these code repository’s code could be best summed up by naming them “Silly Buggers.”

A large part of the software writing community strives only to get the exact desired result from software. If the desired result is achieved then software is deemed to be successful. This can be summed up best by programmers who are asked about their software and they reply in its defense with “It Works,” which somehow absolves the software from any necessity of organization, well-craftedness, or maintainability.

If software is the one true repository of the business processes of an enterprise, I wonder how a business can afford to have its’ processes stored in a manner that other human beings are not able to readily understand, or replicate. Additionally if the usage of code goes beyond just getting the correct result, but includes that code has a status as both a rules repository and a dynamic living document, then perhaps the way that the code itself is written should be looked at.