Site Sponsors:
Who-Do -v- Who-Design? 


The software world is far too often torn between the 'fear of design' versus the 'fear of implementation' camps. Unfortunately, in tough times, quality - or deliberate, maintainable architecture and design - far too often takes a back-seat to the 'just do it' camp. But if there is always time to do it over, why is there no time to do it right?


We had similar issues at Borland. The classic misconception over 'whodo' -v- 'whodesign' is what eventually split the company into the 'architecture' products, and the 'cool tools' company. While the company was struggling, they called it "role based" software development.

UML had a similar split for awhile... but notice today the trend toward creating tools that generate code from models. Very nice... and very inevitable.


Today it seems that the classic rift between those who 'see' (or design), and those who 'do' (implement) is closing up pretty quickly: Indeed, and IMO, the best architectures come from those who know no such limitations. -Why should one who designs a car not appreciate how it is driven, as well as built? -Should software things not be designed so as to be a joy to build / maintain, as well? Even the designs of the best architects have been hacked to bits by code monkeys. -Thus many software architects have found that software development can be a massively frustrating spectator sport. From the other direction (bottom up), designing for full life cycle support is not something that we should be trusting things like an ESB to do for us. Caveat CEO.


The funny thing about those who fail to realize that architecture is just part of a good, personal, hands-on skill set (or vice versa) is that - when times get tough - those who can do more than one thing have far fewer problems in the market. Indeed, just this very day I witnessed how a great friend of mine, who is an extremely competent VP and a Director, is now very happy at the prospect of doing 9-5 software development work once again. The pay is less, but the life is more.


Indeed, while there will always be those who can just barely hold their own by cutting-and-pasting someone else's code into our designs, there will be those who have to live with the inevitable architectural mess. Thus witness the need for a "hands-on" Architect who rises from below, or descends from above, that can jump in and make it all work / keep on working. An understandably priceless skill set, it is a niche few can fill.


So over time, either from the top-down or the bottom-up, it often pays to eliminate the artificial boundaries that we place between architecture, design, management, and implementation... certainly more so in those small and mid-size companies. Those who treat software development as a mindless commodity usually get the brining morass of unsupportable code they deserve. Few in America understand this " but it is why so many American companies are a burning madhouses of broken, leaking, threadbare architecture. Again, SOA can help, but it is just as prone to misuse on the large scale as any other technology.


So a master tradesman who can both talk the talk, as well as walk the walk, is more priceless in our industry than ever before. While there seems to be fewer and fewer of us that who can span the management / architect / developer gap, those who have mastered that trick all seem to have one thing in common: Be the need instilled in them be put there by nurture or nature, we tend to truly love what we do! After all, isn't that larger part of being a 'professional' mean that we 'live', or 'profess', what we say wedo?


[ view entry ] ( 2402 views )   |  permalink

<<First <Back | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | Next> Last>>