Slashdot Mirror
Coder or Architect?
camusflage queries: "I recently was transitioned into an architectural role by my employer. I had been splitting time with development and architecture, in that order. It appears my new duties put me as an architect first, and a coder second, with the coding being at my request. At not even 28 years old, I'm already a lead developer and have people with twenty years more experience looking to me for coding hints and tips. Over that past year with my employer, I've expended much effort on developing credible relationships with other groups in the organization, sure to carry me far as an architect. Since I've already resolved that management is not a track I want to get into, is architecture my most logical next step? What do I need to do to make sure my skills still remain sharp, as I'll be spending less time in the bits and bytes? Any tips from those who have made the transition from development to architecture (both successfully and unsuccessfully) are appreciated."
Make sure that your work is visible though, i.e, be prepared to show that your chosen architectures and the directions you've had the projects take are the successful ones. Management has some problems sometimes with people not producing x lines of code each day
it's in my head
Given the fact that you seem unable to resolve key personal issues using your own judgement, I would have to say you are certainly not ready to make those decisions for others. Stay coding.
After 20 years in the computer industry, I pitch myself as a Systems Architect. If someone doesn't understand what that is, I simply explain:
Analysis
Design
Development
Implementation
Education
All fall under the realm of any decent architect. Nothing was ever built without a little of all of the above, well applied, and when needed.
Stay on top of the tools, keep your finger on the pulse of the brick and mortar materials science realm of the industry.
But always wear the hat of the architect, even when you're doing something as humble writing code.
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
I moved from developer to architect/developer and then into manager/architect/devleoper. There's no doubt that between the three jobs, I find it very hard to do any single one completely. I've been fortunate to have a really great team who I now share the management and architect duties with. I still have the final say on architecture, as I designed the flagship product for our company, but I'm very open to ideas and fortunately have very talented people working with me.
The key to keeping your skills sharp, though is to keep writing software. Not just as a hobby, but as part of your job. Find the time to do it, somehow. If you lose that skill, you're in a position where you could lose your ability to effectively architect and manage (assuming you ever do that as well). My advantage is my roots as a developer and the fact that I maintain it. My best managers in the past were technically proficient and understood problems I was facing, and I could explain it to them in my language. If you lose that, you lose that effectiveness.
This is just my opinion, but it's based on my past exerpience as a deveoper and my current experience as manager/architect/developer.
It's definitely a lot more work than it used to be, but it's also a lot more rewarding. If it wasn't, I'd go back to just being a developer.
The only way to keep your skills sharp is to keep coding. "Pure" architects, the ones who only write edicts from an ivory tower tend not to keep their skills for one simple reason: problems do not normally reside in architecture but implementation (you really pick up on problems in implementation). So you could always work on home projects.
:) )
The second option is to push for a method like XP (Extreme programming) in which everybody codes (in pairs). This allows for your skill (the coding skill that got you your promotion) to be transmitted to other members in the team and to the project you'll be working on. Who knows, you may pair up with a kid out of college who'll teach you a thing or two about coding or ressource management.
Lastly, a rant: why do organizations try to push techies out of the jobs that they do well ? I've seen a gazillion good coders move into management jobs and just Peter Principle out. I've seen good coders move into architecting jobs and all of a sudden lose perspective on the goal of system developpement: deliver a system.
Why is going into architecture or management a promotion ? Shouldn't it be a skill ?
JP Belanger (just a programmer
jpbelang at eloas dot qc dot ca
JP http://www.wearerite.com
Well having gone through coder, architect, consultant contract, CTO, Developer Manager, etc there are a couple things I have learned. Like yourself I am not too old (33). First figure out what you really like. That is the most important factor. If your do not like what you do you will do it ok, but not outstanding.
What I figured out is that I love to advise other people what to do. In other words I love being a consultant / architect / mentor. But in that field you need to stay on top of things. The best way to stay on top of things is to simply read, write and just do what you love. Just doing things at work will not give you that edge. Socialize, attend conferences, write articles. Become involved.
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
"Special Projects"? :) Didn't another poster mention that Special Projects is a euphemism for "We don't have the heart to fire you"?
/.
This is not a slur against you or your skills, and that company could have used entirely different naming conventions, but I found it quite surprising that that term was used in two different contexts within a few days of each other on
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
You're already on that track. You may no realize it yet, but you are.
After all, you will be directing (perhaps indirectly) how many people will be spending their efforts.
My advise, hone your people skills -- the higher you go the fewer and fewer people you will deal with who will 'just see the technically correct answer' -- you'll have to see things from their point of view and then convince either them (or yourself) of the correct answer. :)
Oh yeah, and the advice about being wary of meetings eating your time is good too...
Shut up, be happy. The conveniences you demanded are now mandatory. -- Jello Biafra
At not even 28 years old, I'm already a lead developer and have people with twenty years more experience looking to me for coding hints and tips.
Experience != Specific skills in every area. In other words someone with 20 years of experience still might be coming to you for VB help because he specializes in C++ and doesn't ever want to become a VB expert. I just had a problem with the idea that it's an indication of genius because coworkers call upon your skills in certain areas: that's the idea behind teamwork.
Note that I'm not saying this as a grizzled veteran trying to defend the value of my experience: I'm around the same age, and am often in the same situation (i.e. used as a resource), but every now and then I realize that it might be more that I end up being a sucker than any inherent genius (i.e. if people know that they can ask you and you'll hunt around like a gopher to have the answers for them, pretty soon they'll get lazy and start using you in that respect).
Things I'd recommend (being 28 and in the same position myself):
1) Leave any arrogance you have at the door. People 20 years older than you may not have your raw talent, but they have a lot of wisdom we 20-somethings don't have yet. Arrogance is a sure way to draw resentment from your seniors.
2) There's nothing wrong with unscalability when scalability is not an issue. For example, don't bother architecting your Web application to scale to millions of users when your target audience is only a dozen. New architects tend to overkill every solution.
3) Don't get religious over OS, dev tools, etc. However, don't be too agnostic, either. If your shop is very Windows-based, don't try to revolutionize it with Linux - and vice versa.
4) Document, document, document. UML comes handy here.
5) Ask people about their concerns - just because you're the architect doesn't mean you have to be all-seeing. You just have to be smart enough to know who can help you identify and think through problem areas.
6) Prototype, prototype, prototype. Hack the code if you need to - it doesn't have to be pretty.
7) Architecture != Code Organization. Architecture can affect code organization, but it is a separate issue. Two projects with the same architecture can have completely different code structure. Don't get caught up with code organization. That's an issue to tackle later.
8) Read books about software architecture. It may seem beneath you, but it's definitely worth it. It certainly cannot hurt, and mainly it helps to cover your ass in case you need to defend your decisions. I've had to write memos to defend my design, and it's very easy to do when 3 or 4 famous books agree with you.
The first thing that ran through my mind after reading your post was "been there, done that" or at least I thought so at the time. Some of the best advice in response so far has been along the vein of "don't get cocky". It really doesn't take much to get that label of primma donna or 'difficult to work with' and it's damn hard to shake.
The economy is going to hell in a handbasket and some of the first people to go sound just like you. Fewer years of experience coupled with a higher hourly rate make a good target. I'm not saying it will happen, the odds just favor it. FYI, I'll grant you I might be biased as it just happened to me.
The longer your work on a system fixing problems, the more people come to you when they decide to alter it. It's a natural progression and no big deal.
It sounds like things are going well for you in the office. Keep doing what your doing and make sure you continue to produce results and that your happy doing the work. With those two things in mind, you can't fail.
Career direction doesn't matter until you come across the ideal job, and go "Wow! I want to DO THAT!!!" There is not a single person here that will be able your office, your environment, or what you will need to do there to succeed.
~~ What's stopping you?
As much as I wish I could assure you that you can be an architect for the rest of your career, from my own experience I have to advise you to do otherwise. Like many who are responding to this article, I, too, have been an architect.
;)
Currently, I work at a high-profile software start-up and guess what? No one has the official role of architect. We have a very experienced, very successful development and management team, too; apparently, they do not see granting someone the title "architect" to be beneficial to their success. For the trolls out there: the lack of an official architect will not be a reason a company like mine fails.
Others replying to your article have mentioned that it is important to like what you do. I concur, and that will always be the best compass for your career. But, having said that, I think the role of architect may indicate that you are currently in an anomalous position: chances are good you may merely be smarter or more capable of viewing the big picture than everyone around you. However, what if you were in a different company, or working on a different team? You may find that you are just barely keeping up. I contend that in a different environment, with others who may have skills to match or exceed your own, you may actually be more succesful as a developer than an architect. Therefore, don't pigeonhole yourself unnecessarily.
Further, nearly every successful architect that I have ever seen eventually succumbs to the need to become a manager. It's just part of the natural order of business: in a good company, those who lead and mentor need to become managers because they are best suited to tending to others, to steering the ship. That doesn't mean every manager is good as a leader or mentor (I've met my share of pointy-haired bosses, too), but invariably every good architect finds limits to their influence as an architect--and discovers that bearing a managerial title can actually increase their effectiveness.
Or consider another dimension: maybe it's not what role you should play (developer or architect or manager), but perhaps in what type of industry you work. Architects can often be much happier as a consultant, either for someone else's firm or their own; it is difficult to remain satisfied in a staid, old-line firm where 70% of the challenge is keeping ahead of maintenance.
Having only relatively recently passed through the same dilemma you face, I encourage you to understand the simplicity of the choices as you perceive them to be contextual. I, for example, chose to move on from a role as an architect and individual contributor, to accept a role as a director and department head because I understand that I had too many skills (such as a knowledge of the business, how to work with customers, and project management) that would have evaporated had I not made the transition. Of course, there are other skills I now have the chance to learn, too: how to *really* please customers, not just once, but on a regular basis; how to design an organization; how to architect systems for an entire company rather than for a single application; and (trickiest of all) to motivate, encourage, and develop the careers of my staff, especially when each one of them may have an inkling of their own desire to be an architect!
Ultimately, though, I did make my choice because I understand that I can apply the same skills that I honed as an architect (and many others I learned along the way, including some new ones), but on a much larger canvas. It would be a loss to yourself and to both your current and future companies if you only allowed yourself to be an architect. Strive for those positions that allow you to have a stronger impact, if you are really the right one to be making that impact. My decision to become a manager hasn't at all changed who I am or what I like to do. I still architect a great deal, frequently when my own architect is elsewhere deployed.
Remember: try to understand your dilemma may be contextual; that continuing to be happy about what you do is the best guide; and that you owe it your peers to impact your organization in a way commensurate with your actual skill. You are just at the beginning of your career: just wait till you see what happens next.
I think this "I'm an X; being an X means I don't write code anymore." is a pure fucking invention. I myself am a consultant which means I am a gun for hire and I tell people what to do a lot, and I come up with the architecture, but brother let me tell you I write lots of code. One of the things I've learned after being a consultant is that 95% of jobs are not necessary, i.e., you could fire 95% of the people at an organization/project and end up with the same result. Here's the dirty little secret: as a society we invent jobs for people to do because "everybody gotta do something." Most people are fucking useless.
Even junior programmers these days have to architect large systems because of poor leadership, mismanagement, and dead wood in the department. Its not suprising to see even the most junior underpaid programmers designing important components with no input from above. If this is part of the junior or entry-level requirements, then the compensation should reflect that, but it doesn't. And if the project fails in some way it's the newest, lowest paid guy's fault. If something goes right, PHBs and higher-ups try to take the credit.
These especially apply for touchy-feely jobs like "information architecture," but can be applied to any job within McCorporation.
1. Clearly define yearly goals. Make sure they're realistic and qualitative, not quantitative. Include in your goals learning something you are interested in. Have your manager sign off on them.
2. Touch every project you know of that's related to your work. No need to get heavily involved. Look at the project, know what's going on, know the technology, know how it will affect your work. Write an opinion, recommendation, or just a report. Make it short and high-content. A pretty picture never hurts. Make sure to email it to PHB, as he probably won't remember to look at your intranet site. At least then his sec2 will have read it. Do this at least once mid-way through each quarter.
3. Write quarterly reports. Trump up any work you've done on popular projects, keep work on politically sensitive projects to a few lines. Again, email to PHB. This time he'll read it. They always read quarterly reports.
4. Request at least two weeks of training a year. Make these requests at least two months before you want to go, or within ten minutes of hearing your boss mention extra budget money. Include summaries of what you learned at these training sessions in your quarterly reports.
5. Request to go to at least two conferences per year. Again, write about what you learned at these conferences. Include in reports.
6. Write a yearly report and hand it over in November, along with next year's goals. Make sure your yearly report shows that you met or exceeded each of your goals.
7. Don't piss too many people off.
-----------------
So that's it. Do this and you'll be an information architect for as long as it amuses you. I'm serious.
Now if you need some ideas on training and seminars, and the general work part of being an information architect, just go here: Object Management Group - you should be able to take care of the rest here.
Good luck.
I don't what the problem is for someone to feel that they're special or a prodigy. As long as the person isn't all high and mighty about it, I think it does people good to think they're something special. They'll be more confident and feel better about themselves.
If we were all taught in school that we're just like everyone else and that no matter what you think, you're just plain old homo sapien, I think there would be a hell of a lot more depressed people around.
Or people wouldn't try at all.
The reason people put in all this effort is because they think they are different and can make a difference. It doesn't matter what the reality of it is. Are we better off knowing that we're plain, if that is indeed true? Where is your justification that we're not, other then a movie?
By saying that we aren't unique, you are yourself acting like some all-knowning being, who can see beyond our so-called social lie. Because of that you are making yourself sound exactly opposite to what you want to be perceived as -- you're being perceived as someone who thinks they know everything because they've seen a movie and understood one of the concepts within it that may or may not have been true.
Submitting circumstances to public forum, and being able to assess viable conclusions is a *key* and vital skill required of anyone who desires to manage.
Never let yourself be governed by those who chose to run from hypocrisy or contradiction.
Garner this skill wisely, though. Don't capitulate to "collective think".
As an engineer, alway seek a solution that *solves* the problem, and never let the prejudices such as those stated by this troll to sway your judgment.
A good architect knows no bias other than a desire to get the job done, and done properly.
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
Seriously my career adivice would be..
Get a girl/boy friend
Jump on a place and travel for a year using some of this money you've accumulated from being a hot coder. You should be visiting places like russia, iran and china - anywhere *interesting*
Get drunk with people you shouldn't - live to regret it.
Take casual job in a country where you don't speak the language - or one where you do but don't understand the culture.
etc. etc. etc.
The point? You've obviously been so keen on you 'career' you've forgotten what living is for. The USA economy is going into major recession and at the moment you are just another interchangable piece of cubical fodder. Go and grab some real life exerience while you still can, because in the long run it's what you learn and apply from that which is going to make your life and career worthwhile for the next 40 years - not being given some ridiculous company job title
I'm working on Enterprise Management using Tivoli, and architecting the system to cater for worldwide implementation in a global organization. Those of you familiar with this software know it is not trivial. If I didn't have the background of being a coder, tester, supporter and implementer, I'd have no clue how to design a complex system.
To answer your questions:
"...is architecture my most logical next step?"
- I'd say so. Do you want to be a code monkey for ever? Probably not. If you can code AND design, there is a much better future in it for you. Coders are a dime-a-dozen these days. Top-notch coders are rare. You can't just come out of the local community college and architect a complex system and do a decent job at it. You need experience.
When I first got into programming, I thought I'd do it for the rest of my life; it is that fun. Now I'd rather design a system from the ground up. It's almost like playing with Lego - and getting paid for it! Get your ideas together, design it on paper, and then build it using bits and bytes. I can design something, get programmers to help build it (getting my hands dirty at the same time), and see it work in a production environment. Then move on to the next project.
"What do I need to do to make sure my skills still remain sharp?"
- Study. Research. Read. Code. Code in various languages. Play with various OS's. Repeat. Be a mentor to others you work with. Share knowledge with each other.
When I'm done at my "day job", and when the wife and kid are asleep at night, I do research using the web. I learn new computer languages and new methodologies. I read /. I stay as sharp as possible, and using my skills and newfound knowledge, I can apply that to designing systems. Use the most appropriate tools available for the job. Maybe Perl. Maybe awk/sed. Maybe C/C++/VB. You get the idea. You might be limited by what your company allows.
The web is your friend. You can get ideas, software, and all sorts of stuff from it. You can learn at your own pace. In my opinion, you're much more "rounded" and "marketable" if you can do both development and architecture. Throw in support, implementation, various OS's, hardware/network setup and experience in many languages, and various methodologies, you will be employable anywhere you go.
It's not easy being an architect. You screw up, and it can make developers life difficult, and will require more support resources if it ever makes it into production. It could be a nightmare for your successor on the project. The reverse is also true. Wrong design decisions can be costly. Look at Civil Engineering. Design a bridge incorrectly, and it can be costly - it falls down and/or kills people. Software gone bad is just costly in different ways.
Learn as much as you can. In today's economy you can quite easily be laid off, no matter how good you are at what you do. That's life. If you can be a "jack-of-all-trades", the greater the chance of employment. Going from development to architecture design is a damn good move in my opinion. If you ever get laid off from your job, you could always fall back on your coding skills and maintain systems until the economy picks up.
Good luck.
If you're as good as you say you are you'll make 10X as much as working for any employer. If you're not, you'll come back a little older and a little wiser.
About a year ago I went through this transition at a startup (FYI, that startup is no longer there) Here's a few things to look out for:
1. Many people inside a company may have different ideas of what an architect does. If you describe yourself as one, there can be all kinds of misperceptions to deal with.
2. In many companies, architects are considered a luxury item, so when times are tough they are rarely hired.
3. You will get age resistance, since most architects are older than you.
4. The definition of architect is very fuzzy. At some companies like Sun Microsystems, Architects have Phds and 10 years experience on average. They don't really lead a group, but primarily do specifications and handle
meetings (and occasional coding to stay fresh). At a startup, they are you and me. They could be asked to do almost anything from test planning to project management in addition to specifications and the like. Depending on where the managers/officers of the company come from they will have a different expectation.
BTW, don't take too much guff from people about being arrogant. I've led 40 somethings before too.. it's not that we are better.. just different. In my experience the 20 year guys don't want to deal with leading and are on their fourth or fifth primary language so I don't expect them to remember the details like I do on my 2nd.
Oh another side note, don't code on the project you are architecting if you can avoid it. Writing minor stuff or interfaces are ok, but not serious long term coding. I know a lot of people are telling you otherwise.. but it can often lead to odd, ugly conflicts of interest and time. What's easier to code is often not the right answer architecturally and with deadlines as they are.. well you see the problem.
DescSuit
As a real-life Architect (bricks and mortar), I take exception to software developers appropriating the name of our profession, and what's worse, using it as a verb. You make twice as much as us, you have more job security, at least find your own word!
After reading other comments, I think many have jumped to the conclusion that the person soliciting info wants to become a full blown manager. I'm working at a place where there's a project manager and a technical lead. The project manager deals with time cards, upper management, meetings, while the technical lead deals with the system architecture and focuses on high level technical issues.
I personally lean towards the technical lead side of things and tell my supervisors this as well as in interviews. I let them know I'm not interested in doing time sheets or listening to other employees crying on my shoulder because of some company problem.
Right now I do architecture (share duties with technical lead), coding, and maintenance all at once at a small company. Typically, you can do this in smaller companies where you wear multiple hats becuase they cannot afford to load up on one person per role. In larger companies that I've worked at before, you are usually (not always) shoehorned into "a role" and that's that.
It just boils down to knowing what you what out of life and career, letting others who are responsible for you know this. Don't be afraid if your company isn't comfortable in living with this. If they don't like what you're telling them and if your good, you can find a better fit elsewhere.
The problem is YOU have to figure out what YOU want prior to acting on it. Do you want to move up the "corporate ladder" (if there is one)? Would you be comfortable there if you don't and someone else does? Do you want to stick to the technical side of jobs? How much do you want to be in control of things?
I am a young software architect, promoted a few years ago (when I was 26). The transition from lead developer was difficult, mostly because I resisted the fact that 'architect' is really quasi-management. It is a role that requires gobs of communication, documentation, and strong leadership skills.
The key, I find, is to somehow remember your passion for the role of desinging and preaching systems to a group on a regular basis. I look for things that remind me why I like coding, design, and bringing good sense to the people I serve. And remember, you serve the entire company; your role is to make decisions that will enable the business, and be within the abilities of the developmers and testers.
Ignore the fact that you are younger, it will only undermine your authority. Remember to excercise your authority when it is important, and to let the little things go. And, humility will buy you loads of respect.
Most of all, dream constantly about software design, etc. ... as innovation is the product of passion, and borderline insanity. And, never stop learning. Don't let a month go by without reading a dozen books and implementing at least a handful of things based on what you learn.
Will you stop coding? Only if you want to. You are now a leader, so if coding is essential, then you direct your copmany to allow for your position to code. I set asside 10-20% research time (coding/reading), and I prototype around many of the new technologies we add to our product regularly. And, you are Free to contribute to the GNU project in your spare time ;P
mx
If you are as proficient as you think that you are you should start your own company. Top of the class? In any other role you will be working for people stupider than yourself.
Wow, sounds like your a talented guy going places. A few thoughts from the peanut gallery: Many projects have architects but no architecture. Software Architects need to be part systems engineers. A smarter guy than me wrote that 70% of all software defects are requirements based. This means that figuring out what to do can be more important than being a rocking coder. Technical Architects take on the jobs that others may not be able to. Fight the fires that need fighting not what you find personally amusing. Architects never say, "I don't know how to do that, so its not my job to fix it". They say "Let's make a plan and figure this thing out with Bob, and Jane,...". I like to do Horizontal Prototyping early on. Creating a fabric for your less experienced team members to flush out can really help in Distributed Realtime/Communications stuff. (But I'm sure that's not new to anyone). Parallelism is the key to meeting deadlines. Keeping your team members moving can , at some times, be more important than sleep (provided your employer has good / and hopefully free coffee). Performance models are a hard sell, but they can save your butt. Might have to do on your free time. Dale Carnegie wrote that 20% of what you learn is technical, the other 80% is people skills. He was right.
Bzzt! Few people have ability to make themselves irreplaceable
You don't 'make' yourself irreplaceable. Either you are or you are not.
I once worked with a government agency where much of the work was done by consultants. The consultant's idea of making themselves irreplaceable was to take all the comments out of my configuration files to make sure that anyone else would have great difficulty getting the machines to work.
Target is to make people replaceable and places easy to work. Make projects fasttrack, and be there on date, and be quality dependent. Reduce stress levels, and put project support on people strongest points, not weakest - XP.
That sounds like the type of bubblehead speak worthy of the pointy haired one. What the heck does that utter drivel mean?
Why not leverge a few underlying synergies and look for opportunities to upwardly impact positive attributes while we are at it?
I don't see any reason to believe that the current fad for 'Extreeme Programming' is any more substantial than those that preceeded it. It shows all the signs of being a management fad, it panders to the egos of those promoting it pretending that they are some sort of elite while peddling a small number (between 5 and 7 is usual) of plattitudes that are dubbed 'core truths'. Near as I can make out all XP boils down to is 'a small number of true experts are better than severl hundred also rans'.
Unique people often are hightly opinionated, get in way of actually doing things. After all that company does not benefit from them.
Again what the heck does that mean? Most people are unique.
What does 'opinionated' mean? That I value my opinion over those of other people? Pretty hard to be an original thinker if you always defer to conventional thinking.
If you want to make a significant impact in a field you have to be confident enough in yourself to take on the opinionated buggers who have already established themselves. That will make you 'opinionated' in the minds of the people who think you are wrong.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
One trend that (for better or worse) has been building for the past few years is the building maturity of software as an engineering dicipline. We're not there yet, but in about 15 years some of us will be counted on to develop systems that will be verifiably bulletproof and someone will be sued if it fails. (We may look back at the 90's as the good old days when even high-school kids could make good money cranking out code.)
150 years ago bridges used to collapse regularly; even 100 years ago bridge collapses were not unusual. But today, we're building bridges that will be around forever. What happened? Just before the American Civil War, Civil Engineers got together and decided to become more professional. This also led to standardization of building materials and design processes. Yes, you don't see people building bridges and dams totally off-the-cuff, and it takes a few months to do it right. Today, most bridges have a signature of a certified Civil Engineer on the blueprints and you can guess where the lawyers will be looking if there is a problem.
In the next few years all the SW-CMM process stuff will become critical ( http://www.sei.cmu.edu/ ). There are a few highly organized projects deployed and becuase we're taking measurements we can show that going through all the steps does decrease costs in all phases of a project. With the dot-bomb contraction there's a little less pressure and a little more time to do it right the first time.
The group that will push this through are those who are today identified as (usually) Architects. If you have a customer who can't figure out why there's an Architect on the project who's billing at a higher rate than a coder and yet doesn't produce any executables (my current problem) you can go back and show how, by applying a dicipline, the resulting system will be more stable and usable (my current solution). And even a PHB will see that--developing the communication skills to explain (as best as possible) the latest neat-o blivet to the founder's son is the hardest part of the job.
Of course, I'm still coding. But as a previous poster brought up, it's only to help out in a crunch or to get something started and ultimately my code is maintained (or rewritten) by someone else within a month of my writing it. But actually coding a, say, JSP is the only way to grok what you can do with it.
And giveback? Mentoring that new kid or getting that old COBOL programmer to get with the program is easy. Getting your employer to see the value of process is valuable (start with a new, small project and collect some quantifiable measurements). We are going to have to build a solid environment that we can develop solid systems on, and I don't think it will come from any MonopolieS.
Just to play devil's advocate, I'm going to propose this: software development is so inherently unpredictable that an architect's work is largely useless! In other words, coming up with an overall software design is the easy part. Yeah, you need to do it, but it's almost a tongue-in-cheek endeavor because you know it's all going to change anyway. How many times do you get into situations where the final result bears very little resemblance to what's in the original architectural documentation? It's happened to me in every single project I've worked on. The real brains are at the development level because that's where you have to think on your feet, analyze real-world behavior of that function or API that you thought you could use but turned out to be for sh*t, come up with workarounds when you find out that X component isn't compatible with Y component, etc., etc. The more experience I get with this industry the more I get the feeling that the "higher" you go on the totem pole the "dumber" you can be and still fake the job! Right on up to managers who know zilch. And I'm not talking about IQ, either -- from my perspective, it looks like when someone gets promoted to a "higher level" position it's almost like they are retiring, not assuming a more difficult job -- kind of like "I paid my dues, now I can start to take it easy a bit and relax". You know -- like they are sick of memorizing API's and want to sort of rest on their laurels and deal with software on a "higher level". I have felt this way for a while, and I keep feeling like someday there's going to be this great revolution in the software community where it's like "the Emperor's New Clothes," and someone somewhere is going to say "hey, wait a minute, that manager that's earning way more than that developer doesn't know jack sh*t!" Even if he/she did at one point and went soft/forgot it all/got outmoded. It just seems to me that software is complicated, it's not simple and it can't be reduced to simple principles, ever. So the person who really has to get their head around all that complexity and all those specifics and know and remember it all is really the person who should be "honored" the most.
Whatever -- like I said, I'm playing devil's advocate. But until I run across a real life situation where it's obvious that the "upper level" folks are really assuming more responsibility than the developers -- not accountability, mind you, but responsibility -- then I'll change my mind. It's entirely possible that for all I know I've just been unlucky so far in terms of the management teams I've been exposed to. Fact is, I'm still waiting for it all to make sense -- and that means making sense to someone who accepts 0.0% B.S. and 0.0% compremise of principles.