Contribution 44

From WikiContent

Revision as of 20:46, 7 June 2008 by BarryHawkins (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

If you're unwilling to be hands-on, maybe you should keep your hands off

One of the most widespread tragedies in the practice of software development has been the tendency of corporate culture to over-compartmentalize the activities of software development. In the upper echelon of the artificial hierarchy of task separation sits the software architect. Sequestered away from the disturbing din of real life within the company, these persons are liberated from the mundane, in order that they may orchestrate plans that set in motion the work of many, unfettered by such things as domain knowledge and implementation constraints.

Know this; the only people who belong in white towers are the captured princesses of fairy tales, and even then it was not of their volition. Partitioning the activity of design away from implementation destroys the call-and-response cycle between design and implementation. The relevance of your work is directly related to how engaged you are in the domain.

Do your models reflect an understanding of and respect for the knowledge of your domain experts? If not, then your designs fail to meet the needs of your customers, be they internal or external. Such software serves as little more than an artifice whose foremost function is to illustrate its author's ignorance of the domain they purportedly strove to serve.

Are your models appropriately constrained by the implementation technologies that development teams must use? If not, it is our somber obligation to inform you that your models are probably altogether ignored by the implementation team. With your only constraints being imagination and the modeling tool of choice, splendidly artistic and utterly nonviable designs can be achieved. These designs amount to little more than paid performance art, with nobody who'll even go so far as to stick it to the refrigerator with a magnet, much less use it to create working software.

Should this casualty of corporate culture be your lot, and should you find yourself overly comfortable with the arrangement, remember this: if you're unwilling to be hands-on, maybe you should keep your hands off.

By Barry Hawkins

This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Software Architect Should Know home page

Personal tools