- And the role of programmers and systems analysts.
To use this segment in a Radio broadcast or Podcast, send TIM a request.
I have always admired the work of the carpenter. To watch a craftsman at work creating something is a delight. During High School I took a couple of wood shop classes which taught me the basics and gave me an appreciation for the skills required to create a wooden object of any merit. I have watched carpenters build houses, create impressive bookshelves and office libraries, carve baseball bats with lathes, and much more. Their attention to detail and ability to produce a quality product is truly inspiring, at least to me. In all cases though, they depend on a good set of plans or blueprints specifying the dimensions and materials to be used. Without them, the carpenter is lost. Even if they were to pursue their labor without such documentation, they would likely produce something that might be of interest to themselves personally, but useless for everyone else. This is why the architect or engineer is needed; to design and specify the product so the carpenter can work effectively. Whereas the carpenter works in the physical world, the architect works in the logical world where his/her ideas and designs are recorded on paper or in the computer.
Let me now describe a different set of carpenters and architects. Over the years, I have made extensive use of the carpenter/architect analogy in information systems design. I contend programmers are the carpenters of the industry and the architects are systems analysts. Like the carpenter, programmers live in the physical world and produce programs used in computers and telephones, in automobiles, in aircraft and ships, on the manufacturing floor, and many other places. Again, watching a programmer work according to a good set of blueprints is a delight. Unfortunately, we have built up a glut of programmers and diminished the role of the systems analyst almost to the point of extinction. This means fewer blueprints which leaves the programmer to guess what is to be produced. Instead of working by design, programmers work in accordance to "trial and error," a very frustrating scenario for both the programmer and the end user (the customer). This is the reason why companies waste considerable time rewriting programs, a very costly proposition.
All businesses and organizations depend on enterprise-wide systems to produce timely information, but few truly understand the complete dimensions of their systems or how they work. Consequently, redundant work effort is common, there is data redundancy leading to erroneous or inconsistent decisions, programmers operate in a constant "firefighting" mode, users do not trust the information produced, and in general the company's productivity suffers. All of this because companies have somehow convinced themselves they need more programmers and less systems analysts. Somehow I am reminded of the Bryce's Law: "If we built bridges the same way we build systems in this country, this would be a nation run by ferryboats."
There have been a multitude of tools and techniques introduced over the years to expedite programming; program generators, fourth generation languages, CASE tools, agile programming, cloud computing, and many more. Over time, such fads have come and gone, yet the problem persists. These tools might be nice, but they certainly cannot help the programmer if he/she doesn't know what they are to produce. To illustrate, consider the nail gun as used by the carpenter, an extremely efficient means for shooting nails into wood, and much faster than using a simple hammer. It may be a great tool, but if the carpenter doesn't know precisely what to build, it is useless. The same is true with these programming tools and techniques. If the programmer doesn't know what they are to build, no amount of elegant technology will expedite the development of the product.
If companies are serious about improving programmer productivity, they would be wise to hire a few more architects. The reason for not doing so is rooted in management's lack of appreciation for logical design. They can more easily assimilate programming which produces screens and reports they can physically touch and see, like an "app." Logical design though is more nebulous to them; they typically do not comprehend such things as flowcharts or other such diagrams and believe progress is impeded by such work. Maybe the best way to teach them the necessity of systems analysis is to give them a nail gun and a stack of wood and tell them to build something out of it (without any blueprint of course). This should give them not only an appreciation for the necessity of the work of the systems analyst, but an understanding of how the programmer works as well.
"Good specifications will always improve programmer productivity far better than any programming tool or technique." - Bryce's Law
Keep the Faith!
Note: All trademarks both marked and unmarked belong to their respective companies.
Tim Bryce is a writer and the Managing Director of M&JB Investment Company (M&JB) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at timb001@phmainstreet.com
For Tim's columns, see:
timbryce.com
Like the article? TELL A FRIEND.
Copyright © 2012 by Tim Bryce. All rights reserved.
No comments:
Post a Comment