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.
Subscribe to:
Post Comments (Atom)
2 comments:
As programmers employed by a company in order to write software, we must understand that the company has invested a considerable amount of time in the development of said software. That time translates directly into money for wages. Having performed development work way back in the day of dBaseIV/Clipper for government contractors in DC (circa 1988) gives me a different perspective on this. It was impressed upon me that getting the job done in whatever was the quickest means possible was the order of business. Of course it had to work correctly; however, organizing the work in a manner so that future programmers revamping the project could easily work with it was not a part of the task order. If such code organization WAS required, we first got the software to work, and THEN we put the code cleanup on a future billable task order. ;-)
This is not to say that the industry has not learned any lessons. In my current gig, we are highly organized and take great care to create re-usable code and libraries. It does make for a more enjoyable programming experience, and those of you that know me know that programming is NOT my first love.
The real issue here is how the paradigms of programming shift very rapidly. Programming in Microsoft Visual Studio 2005 is vastly different from VS 2008. Microsoft is eschewing HTML for XAML on the front-end, although the back-end is staying with C# and VB.NET and such. When a company is faced with revamping legacy code to work with new technologies, a company has to look at the expense of doing such a conversion. Often the choices are either to stay completely with the lesser platform, or leave a portion of code in the prior platform while programming with the new tech going forward. Either way, it's cost that drives these decisions. In which case, it behooves us to build our projects in a "value-added" way, writing our code in the way it needs to be written and insisting to our managers that this is proper and worth the billable time.
Thanks so much for the post Tracy.
Of course so much of the industry has changed. I think it is a real shame that I was not cognizant of the computer industry in the 1970’s when they where building the first version of UNIX and C. I think that most of the 1980’s were spent looking for a computer system architecture that could be widely adopted. In the 90’s we were busy transferring business processes to the computer systems, and by 1998 we had developed an approach for integrating our back end systems with web front ends. But now, we have ported most of the business logic over to our systems (and got a nice productivity boast from this), and now have to figure out how to maintain these systems.
In 1988, much business was still conducted with manual processes that were passed from person to person as a person took over that job. Most of the computations were still performed on a ten key calculator. In 1988 even the concept of a member of the executive committee to oversee technology was not standard practice.
These days we have to deal with the legacy of huge amounts of left over software that is no longer well understood. A lot of the reason that the code is not understood is that it was produced in the fastest means possible.
In today’s world, a whole business is in its code. Current business has rested all of its eggs in technology, and it is getting harder and harder to gather understanding of what was originally meant by a piece of software. And that piece of software represents all the organizations business logic, its sales pipelines, its future business prospects and its customer management. Computer systems now are business critical, and that may force businesses hand in how much they are willing to invest in developing their software.
Post a Comment