Evolving beyond apprenticeship - Embedded.com

Evolving beyond apprenticeship

As a software engineer who majored in architectural design (for at least some time) in college, I would assert that, ultimately, the biggest difference between construction and software engineering is the maturity of the construction industry. Software engineering is very much a paradox. While tightly coupled to the “Information Age”, both as cause and direct product, we are somewhat pre-industrial in our organization and methods. It's our curse as a fledgling engineering discipline (aerospace can even consider itself as just EE + avionics in the space sector).

This is one reason that I so enjoy “Separating job functions” and the point it addresses. Unlike the architects of old, we have not learned to unify all stakeholders with formal languages and specification tools. If I'm paying a few million on a new building and don't have someone that can read a floor plan on my team, it's my fault — not the engineering team. And unlike any developer of a product that is mass produced (even tennis shoes, for that matter), we have no clear delineation of career and training between those who design, those who build, and those who certify. Have any of you heard of someone with NO software development experience that has a degree specifically in “Software Architectural Design,” and does nothing more than that? Even the fictitious widget-makers in college textbooks have evolved beyond the era of apprenticeship and round-trip production based on one person. Of course, this is one of the differences in the new Rational Unified Process: the distinction between engineering stage (analysis and design) and construction stage.

Some people disagree, saying that there are more differences. The concept that there is no “construction” stage in software, and that it's all design is not entirely true. There is a construction stage in software, we just don't have the automation capabilities yet to make mass-production and 100% round-trip engineering possible within our tool chains yet. People would have once made the same argument of crafting firearms once, and I imagine we only fight reform in that direction because we've learned from experience that mass-product means lost jobs. (Of course, the history of industrialization also tells us that before full automation comes the employment of cheap and indentured labor to do construction-level tasks: say, from India)

I also have a point of contention with the concept that software engineering is so fundamentally different because it is so intangible. Most people believe construction is guided solely by laws of physics and mathematics, and constraints of materials. More of architectural design is based on principles of psychology/sociology, style, and artisanship — entangle requirements and constraints in their own right — than typically understood. Furthermore, interfaces and component decomposition is not much more discrete and straightforward. Classic Roman architecture used three styles — Doric, Ionic, Corinthian — just for pillars; the typical civil engineer would be hard pressed to count on two hands the number of bridge “design patterns” used around the world. Bottom line is that we're a young field that needs to lose the excuses and build on the lesson learned and evolution of our sibling disciplines.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.