Click for AUDIO version.
If you think the physical infrastructure of our country is bad, its bridges and highways, you should see its systems. Like it or not, we are a nation run by systems developed as far back as the 1960’s. No wonder COBOL programmers are still in demand. Over the years I have heard one horror story after another, be it in banking, insurance, manufacturing, or government. I have also written about such snafus, such as at the United States Department of Agriculture (USDA) and the National Security Agency (NSA). Another that comes to mind is the Obamacare health system which was delivered late and horribly over budget. These are mammoth systems wasting taxpayer dollars in the millions and billions. The big question is, Why?
Whereas other countries have cleaned up their messes, such as the banking systems of Japan and Europe, we are just the antithesis. While others are moving forward introducing new banking products, the Americans find themselves in the role of constantly fighting fires. You cannot move forward until you put your house in order by bringing standard practices and discipline into your work effort. This is what happens when you treat system design as an art form, as opposed to a science.
Until the 1980’s, there was an abundance of trained systems people in the work force. We then began to see our focus shift from total systems to how to write a single program efficiently, meaning the Structured Programming and CASE movement (Computer Aided Software Engineering) of that period. This led to a void of systems people and, without such talent, major system projects began to die in the 1980’s and 90’s. So much so, nobody is willing to try it anymore, primarily because they have forgotten how to do so and settle for building smaller things, such as an “app.”
For example, developers no longer know how to write information requirements or project scopes. They may know how to produce a program spec, but have no idea how to develop the high level requirements needed to satisfy the actions and decisions of a business. Without such requirements, developers waste considerable time building the wrong system. Without a well defined project scope, developers frequently wander outside the boundaries of a project and either perform too little or too much work.
Systems design is to programming what architects are to carpenters. Without a proper set of blueprints, the carpenters will likely build the wrong product, regardless of the elaborate tools they may use. Unfortunately, the systems architects disappeared in the 1980’s which explains why we lack the know-how to build systems anymore.
A major system can take several months, if not a couple of years to build, but we now possess the attention span of a gnat. If we cannot produce something quickly, such as in a couple of days, we tend to lose interest. This is why long-term planning is usually no longer than thirty days and why we find ourselves in a reactionary form of management.
When you talk with programmers about doing something bigger and better, the excuse typically is, “We do not have time to do things right.” Translation: “We have plenty of time to do things wrong.”
Like any discipline, in order to perform systems design properly, a standard body of knowledge is required featuring common sense concepts, principles, and defined terminology. Such knowledge should be tested and proven. This is the purpose of a standardized methodology, like “PRIDE,” which is aimed at bringing uniformity to the design and development process. By doing so, it can turn a heterogeneous environment into a homogeneous one, thereby forcing people to speak common language and perform work in a standard manner.
So, the reason nobody thinks big in the systems field anymore is simple; they do not know how to.
“If we built bridges the same way we build systems in this country, this would be a nation run by ferryboats.”
– Bryce’s Law
Keep the Faith!