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 ] ( 2430 views )   |  permalink
Resume Robers! 
In a previous post I wrote about the horrors of being employed by people who do not respect our countries notion of what an "employee" is. Far from complying with the IRS regulations on what it means to be genuinely "employed", today hosts of unscrupulous people typically employ us for statutory work, force us to pay our own expenses, then dump us back into the market whenever any single contract is over.

Worse still, by studying the resumes that we give them, these same people can easily learn who we worked for, and when. Indeed, with the help of a careless secretary or two, from discovering the name of our projects, to the technologies, hiring managers, and their phone numbers, the information you provide a would-be contract ''employer'' can be twisted and doctored in such a way so as to allow legions of inferior workers to steal your job. Indeed, farming the content off of American resumes has become so profitable that reported it's first on-line break in this year!

I personally ran into the result of this type of misrepresentation recently at a major telecommunications company. Outrageously, the person who we interviewed on the phone did not even match the person that arrived on-site. Upon confronting the would-be consultant with the problem, we discovered that not only had this imported worker stolen many of the project names and buzzwords from somewhere else, but that the combination of the contract signed and the internal HR process made it a long time before we could be free of the impostor.

Another example: While working on an extremely well paying gig (it had to be - I was to succeed where four others had not), I saw the resume rip-off artists in action again. This time I was the reason for the security breach. How? Well, after telling a head-hunter 'friend' that I was getting twice the rate he was offering me, he hounded me day and night to tell him who I was working for. After declining time and time again, this person finally tricked a reference I had given him into telling him the name of my client.

What happened next took place in less than six weeks: The VP of IT was contacted by a series of outsourcing firms. Entire teams of workers were hired. After a few weeks, my client declared - from then on out - that she would only use Indians. They started letting people go.

I completed my project and left the company. Interestingly, and within less than 7 months, I discovered that every other project - one of which was generating over 10 Million dollars a month in revenue per month - had to be scrapped. It seems that their paper-pushing employees could simply not do the work that they said their they could do, let alone perform under pressure. A mere 14 months after the first impostor set foot in that troubled company, I discovered that the the company had filed for bankruptcy. While they tried to get their former workers back, good people do not often sit around too long in any type of market.

Indeed, I heard similar tales from my friends at Borland. -After surviving four layoffs (the last under the hand on an Indian manager who had replaced my boss,) the last several years the company stock has routinely traded for under $1 per share. Welcome to the 3rd world.

Of course I do not mean to pick on any particular nationality here. While the problem is common amongst all nationalities (even our own), I can only relate what has happened to me personally.

So what is the problem? I suppose most of it is that Americans can indeed be a rather trusting lot. We tend to take people at their word. But the moral of the story is this: Be careful who you give that resume to! If you are an employer, today more than ever you need to check those credentials carefully. Just because a body smiles and says that they are from MIT, Stamford, Harvard, or even Georgia Tech, it does not prove that they have any college education what-so-ever. The same can be said for any projects and / or technologies they may pretend to represent.

In the words of an extremely competent friend of mine from India: "Americans are so stupid. They think that all Indians are intelligent... but let me tell you, we have plenty of stupid people here!"

So beware of those resume snatchers. The job they are after just might be yours!

[ view entry ] ( 3112 views )   |  permalink
SOA Meltdown 
Hariharan asks: "Can SOA predict slowdown?"

Response: Most can predict a slowdown for large companies who use SOA. Indeed, using the modern definition of an XML based service, SOA itself is inheritantly fat, chatty, and slow. Using a more broad definition (i.e. octet-optimized services), when you hit that XML parsing wall you can chuck that XML SOA noob mess and architect-in something a lot more customized, efficient, and - alas, closed. In XML terms, it is defined as favoring CDATA over PCDATA.

Indeed, until some motion is detected in the realm of ESXML, the best you can hope for when your XML based SOA inevitably becomes sluggish is to either chuck more hardware at the problem, or begin to design for a more customized, secure, and - unfortunately arcane - set of packet-level efficiencies.

Still, big companies do indeed need XML based SOA to help bring some order to the stove-pipe, duct tape, bailing-wire, file and protocol integration mess that we often see today. But be aware that the trade off between pumping metadata along with each and every packet, as opposed to assuming some form of implicitly strongly-typed packets, will still be the trade off for a very, very, long time.

Caveat Architect.

[ view entry ] ( 2865 views )   |  permalink

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