| |
When is a Software Engineer Not a Software Engineer?
By V. Berba Velasco Jr., Ph.D.
The title of “software engineer” has got to be among the most highly abused in the corporate high-tech world. It's also one of the most popular.
And why not? It sounds a lot better than “computer programmer,” and it looks much better on one's business card. Unfortunately, it's often inaccurate. Engineering is, after all, the application of sound technical principles to develop systems that are robust, efficient and elegant. I've found that a great many software engineers can develop working programs, but do little or no real engineering design.
Does this sound harsh? Perhaps, but I've also found it hard to deny. I've encountered very few software engineers, for example, who have clean, crisp and readable coding styles—an essential element of elegant software design. I've also encountered a preponderance of cryptically written functions, clumsy software abstractions and bizarre spaghetti code. To my dismay, I've discovered that even among computer science graduates, many reduce object-oriented programming to the mere use of private data, public functions and object instantiations. It's enough to break a teacher's heart.
Now, I won't go so far as to say that most programmers write spaghetti code. That would not be fair. However, I do think that relatively few programmers have a deep appreciation for the artistry of software development. That's not to say that they're ignorant of such things; not at all. Rather, it's more that the engineering aspects of elegant code design are all too often neglected.
I think this happens because modern programming tools have made proper code design seem like a nuisance. In the early years of computing, people were forced to write out their software designs, pondering many fine details before they ever sat down in front of the computer. Nowadays, with our fast compilers and interactive debugging systems, programmers often find it more convenient to simply sit down and start coding, with just a modicum of software design. Mind you, I do understand that this is sometimes more efficient—when the programming task is fairly routine, for example. However, when such design-as-you-go software development becomes standard practice, then you have the makings of utter chaos.
In part, this problem is also rooted in the malleable nature of computer software. No self-respecting civil engineer would design a bridge by slapping girders together until he has something that works; after all, if the bridge collapses, it could take months to rebuild it. Similarly, no sensible architect would want to build a house without blueprints and floor plans. Yet it is commonplace for programmers to develop software using poorly chosen functions and only the sketchiest of designs. After all, if the software doesn't work, they can always find the bug and fix it—at least, in theory. In practice, these bugs are often difficult to detect, and fixing them can require extensive surgery. The consequences of an ill-designed software program can be disastrous indeed.
For this reason, I believe that high-tech companies need to give software engineering the respect that it deserves. They need to develop a true culture of systematic software design, instead of merely settling for “whatever works.” A company that's looking toward the future must pay proper devotion to the principles of software maintainability, proper documentation and elegant, robust design. It must also inculcate a culture of true software engineering among its employees. The failure to do so may work in the short-term, but it is a recipe for long-term disaster.
About the Author
V. Berba Velasco Jr., Ph.D. takes great pride in working at Cellular Technology Ltd, a provider of ELISPOT analysis tools and ELISPOT expertise. He is pleased to work in an environment where excellence is valued.
Article Source: http://www.simplysearch4it.com/article/800.html
| If you wish to add the above article to your website or newsletters then please include the "Article Source: http://www.simplysearch4it.com/article/800.html" as shown above and make it hyperlinked. |
| Some other articles by V. Berba Velasco Jr., Ph.D. | Using 'Get' and 'Set' Might Be Something You'll Regret
It's an all-too-common pitfall. Programmers who attempt to write object-oriented code decide to make all of their data variables private, while creating public get() and set() ...
People Who Think They're Right
A few months ago, I had a conversation with a churchgoer who complained about religious intolerance. He said (and I paraphrase), "When it comes to religious beliefs, I really ...
A Common Misconception about Object-Oriented Programming
I've seen it time and again. A computer programmer proudly proclaims, "Yeah, my code is object-oriented. See? My data members are all private, and they can only be reached through public member functions. That's ...
Listening Techniques For More Effective Meetings, Part II
In Part I of this article, we discussed the importance of active listening, and how it is important for smooth and effective meetings. In the process, we touched on the topic of reflective listening. Reflective listening is ...
Listening Techniques For More Effective Meetings, Part I
We all know what it’s like when a meeting doesn’t go smoothly. Discussions get derailed, tempers start to fray, and things are seldom resolved ...
Don't Forget the Internal Software Documentation
Internal documentation. It's one of the most frequent casualties in software development.
It's not hard to see why. For most companies, time is money, and they frequently find themselves scrambling to release a ...
|
|
| |
|
