Engineering Jobs

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 stylesan 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 efficientwhen 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 itat 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.

V. Berba Velasco Jr., Ph.D. takes great pride in working at Cellular Technology Ltd (http://www.immunospot.com, http://www.elispot-analyzers.de, http://www.elispot.cn) where he serves as a senior electrical and software engineer. He is pleased to work in an environment where excellence is valued.

Share This

“Software Engineering” - Whatever That Means
If a programmer hands you her business card, it probably won’t list her title as “Programmer;” It is more likely to read “Software Engineer.” This raises the interesting question: does a programmer’s daily job rise to the level of an engineering discipline? I think it would be more accurate to call programming an emerging engineering discipline.

Evolution of the Field
Since around 1975, various people have tried valiantly to impose discipline on the chaotic, egocentric, idiosyncratic practice of programming. And just at the turn of the century some professional institutions have started to establish the core competencies that would let a programmer call herself a software engineer.

Vision of the Future
Will we see the transformation complete: will programmers be licensed and regulated like other engineers? Personally, I think it’s too early to bet one way or the other - programmers are remarkably individualistic and there will be be very strong resistance to regulating what they regard as their craft. On the other hand, offshore development and the rise of software-based lawsuits are changing the landscape much as barbed wire changed the American west of the 19th century. If you’d like my prediction, ask me again in a decade.

Today’s Situation
But if you are going to work in the world of the programmer, you’ll have to understand some of the standard ways in which complex software is constructed. If you want to sound erudite, you can refer to them as “software development methodologies” or “development models,” but if you’re talking to a programmer you’re better off asking, “So, how do you folks build software around here?”

About the Author
Bruce Taylor is the owner and principal of WorkingInUnison, an Organizational Development consulting firm located near Boston, Massachusetts. Bruce helps software organizations of all sizes to create low-stress, supportive, adaptable working environments, so that the engineers, leaders, and managers can work as effectively as possible. He provides executive coaching for senior managers who are creating superior organizations, management coaching for technical leaders who are adapting to new agile practices, and individual coaching for engineers who are upgrading their skills. Bruce has a Masters in Computer Science from Duke University, a Masters in Community Psychology, and a Certificate in Job Stress and Healthy Workplace Design, both from the University of Massachusetts. He can be reached at http://workinginunison.com or at brucetaylor@workinginunison.com.

Share This

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 what being object-oriented is all about.” I’ve even heard this kind of drivel come from the mouths of Computer Science graduatespeople who have presumably studied object-orientation in the classroom, or who would have had ample opportunity to educate themselves.

Scholars may quibble about the fine points of object orientation; however, one thing is for certain: merely having private data and public functions does not constitute a proper object-oriented design. Rather, proper object orientation entails much more.

One of the most basic elements is information hiding. This means that objects should only present the information that needs to be seen; that is, it should present a coherent and well-selected interface of functionsone that does not betray the data contents and internal workings of the class. In other words, the manner in which the functions are implemented remains hidden from the user, allowing the developer to alter the implementation as needed. (Some also refer to this as “encapsulation,” whereas others state that encapsulation is merely a means for hiding information. I lean toward the latter view; however, for the purposes of this article, this distinction is unimportant. Suffice to say that information hiding is a key element of object-oriented design.)

When a programmer declares that his code is object-oriented by virtue of having private data and public functions, he is placing the cart before the proverbial horse. Using private data and public functions is merely a means of achieving information hiding; it is not a goal in itself. For example, consider a design in which every single data member has corresponding “get” and “set” accessors (e.g. a data member “x” would have matching “getx()” and “setx()” functions). In this example, information is poorly hidden, since the choice of functions (indeed, their very names!) betrays the manner in which the data has been implemented.

Inheritance is another key element; that is, specific classes are to be derived from more general ones. Inheritance is a means of implementing abstraction; that is, it allows the user to identify objects with common characteristics, and which should therefore use common code (or at the very least, common interfaces). This is part and parcel of thinking in terms of objects, as opposed to thinking primarily in terms of functions and procedures.

Yet another key characteristic is polymorphism, which allows a descendant object to override its parent’s member functions. With polymorphism, a descendent object does not have to respond to a message exactly as its ancestor does; rather, it can have its own implementation. Note that the descendant objects do not have to override these functions; rather, they should simply be allowed to do so, as needed.There is much more that can be said about the nature of object orientation; indeed, scholars often contend over its precise definition and its principal ideas. Whatever the case though, the point remains: merely keeping private data and a set of public functions does not constitute an object-oriented designnot in any meaningful sense of the term.

About the author:

V. Berba Velasco Jr., Ph.D. is a senior electrical and software engineer at Cellular Technology Ltd, a biotech company that provides ELISPOT analysers, human PBMCs and serum-free cell culture media.

Share This