6 ms·

As a software architect for the last ~10 years I have to disagree. His point seems to be that if you get a job as a software architect you'll end doing nothing

by modoc 17y ago

As a software architect for the last ~10 years I have to disagree. His point seems to be that if you get a job as a software architect you'll end doing nothing but meetings and creating UML diagrams. I'm sure there are places like that, I've worked at one (Rational Process - shudder), but there are many places where they need someone who can provide architect level application design, who can see the forest through the trees, who can balance the needs of the business, the 3rd party integrations, and the technology. My current contract role has me providing architecture (usually just a 1-2 page design doc, not often UML), mentorship, and coding some of the trickier stuff. I still code a lot, but I also have responsibility over the whole software ecosystem and hence some power to decide how things go. I mentor developers, perform code reviews, and work on process improvement too. It's a great role.

smikhanov 17y ago
I'm sure there are places like that, I've worked at one (Rational Process - shudder) Thank you for your honesty :) The bottom line of my post was "beware of the advertise SA positions, they tend not to offer what is usually expected from an advanced position like that". I also think that a key to being a good SA is to keep writing code, no matter what happens. Looks like this is exactly the case for you.
- modoc 17y ago
  I absolutely agree that if you like coding, don't ever stop. It will also make you a better architect. In my experience, large companies who use Rational will have their architects buried in Rose building UML and writing 150+ page docs all day. Smaller and/or agile/XP companies will be looking for a super experienced coder, who can mentor, and look at the big picture, see the business drivers, etc... Ideally this sort of thing can be figured out early on in the interview process. "How do your other architects spend their time?" etc...
  - hga 17y ago
    Hmmm ... I think you can do both. I used OOSE (from the book, the cut down version of Objectory (prior to it becoming the Rational Process)) in a project ... but it was just me and a bright newbie almost right out of college, with someone added for a last feature. It worked fantastically well, e.g. I had to stop working on the project for a few weeks to attend to the prototype (that I'd hacked up in in a 6 week burnout), and when I came back the newbie had neatly iterated the design and was able to slip right back into coding with no fuss. By the end of the project my estimates for how long to finish a unit of work were accurate to 30 minutes (by then I'd been programming for two decades, so it wasn't all the process!). On the other hand, I wonder if Objectory/OOSE/Rational Process solves the wrong problem. If you're going to use imperative OO to build a big complex system, yea ... but maybe you should try e.g. functional programming. I.e. the other relevant development that came out of Ericsson was Erlang and was for the same problem space (e.g. telephone switches). Still, I feel that if you use parts of it correctly for the right sorts of problems (especially ones that are pretty well understood, e.g. I'd been figuring out for 5 years how to do my project correctly before I had a chance to do it as detailed above) it can be very useful.
    - hga 17y ago
      CORRECTION: the newbie had neatly iterated the design and I was able to slip right back into coding with no fuss
hello_moto 17y ago
There should be more people like you. The biggest problem in our industry is that there isn't enough mentors to tell the young people that they were wrong all this time.
- modoc 17y ago
  :) I think the biggest problem in the industry is that many of the "young people" (I'm still young, dammit!) don't really want to learn or be mentored. Seems like there's a slew of folks in the junior to mid-level developer arena who got into CS because it was going to make them a lot of money, not because they love to code. I love it when I'm working with people who love to tinker with new libraries and APIs, who are working on something neat in their spare time, etc... They make much better developers than folks with a CS degree who do what's assigned to them from 9-5 and that's it. I'm not saying you have to work a ton, but just be interested in the whole tech universe:)
  - meta 17y ago
    As best as possible, I think a company should screen for that in the Interviews. (given that Interviews are sometimes a effectiveness gamble, I realize that it can be difficult to screen for that). I usually watch to see if they light up and get into conversations when I ask questions in the Interview related to our tech. If they don't get that expression and interest (hard to qualify but I think most people know what I am talking about) than that is a lot of hire points lost. If you spend an hour talking computers and they never 'light up', I feel, they are probably not the right fit.
  - jerf 17y ago
    I blame the myth that young hackers are somehow strangely more knowledgeable than their elders because of the putatively ever-changing nature of technology. I've always been suspicious of this self-serving narrative (in what other engineering field is this true?), but as I approach what passes for Old Fartness in this industry (30) now I know it's bullshit. All the twenty-year-old whizzes I know are experts at taking something like Ruby on Rails, trading in the quality of the underlying framework to put together a hack-job very quickly, and then promptly getting themselves stuck in a morass that they can't get out of because they don't even understand why they are in a morass. Hand these people something with a lot of technical assets they can borrow against and yeah, they can toss something together fast, but that's hardly "better" then what I can do now, which is actually produce technical value. (Mind you, I'm not saying that's necessarily a bad thing. There's a time and a place for that. What is a bad thing is that the developer won't understand the tradeoffs they just made, and probably didn't make the tradeoff after a sober and careful balancing of the costs and benefits, but did it because it's all they know.) Anyhow, my point is that thanks to that mythology, a lot of younger people don't think they can be mentored by the old farts they think know nothing in this rapidly changing technical environments. The old farts (at least the ones who have ten years of experience and not one year of experience ten times) have learned that frankly, the tech world isn't changing that fast (different languages, different APIs, pretty much the same messes). There's plenty of mentoring to be done, but you gotta accept that the mentors are going to tell you some things that may shattered your treasured conceptions of the programming world....
bmelton 17y ago
I'm in almost the exact same boat, though I find that much of my job is in just predicting pitfalls, and in anticipating when things won't work. As a federal contractor for an agency that prefers to use COTS/GOTS software, there is a surprisingly great need for having a developer that can look at a given piece of software, intuit how it works, probe its sales and development teams to say "Well, this claims to do Kerberos authentication, but it really does GSSAPI, and hence, won't work with your existing OpenSSO implementation." I also code a lot, mentor other developers, etc., and yes, it IS a great role.
japherwocky 17y ago
This is much closer to the role a real architect plays in a real architecture firm. Sketch out the big picture, take care of the trickiest details, wrangle your underlings into doing the rest.

by modoc 17y ago

smikhanov 17y ago

I'm sure there are places like that, I've worked at one (Rational Process - shudder) Thank you for your honesty :) The bottom line of my post was "beware of the advertise SA positions, they tend not to offer what is usually expected from an advanced position like that". I also think that a key to being a good SA is to keep writing code, no matter what happens. Looks like this is exactly the case for you.

modoc 17y ago
I absolutely agree that if you like coding, don't ever stop. It will also make you a better architect. In my experience, large companies who use Rational will have their architects buried in Rose building UML and writing 150+ page docs all day. Smaller and/or agile/XP companies will be looking for a super experienced coder, who can mentor, and look at the big picture, see the business drivers, etc... Ideally this sort of thing can be figured out early on in the interview process. "How do your other architects spend their time?" etc...
- hga 17y ago
  Hmmm ... I think you can do both. I used OOSE (from the book, the cut down version of Objectory (prior to it becoming the Rational Process)) in a project ... but it was just me and a bright newbie almost right out of college, with someone added for a last feature. It worked fantastically well, e.g. I had to stop working on the project for a few weeks to attend to the prototype (that I'd hacked up in in a 6 week burnout), and when I came back the newbie had neatly iterated the design and was able to slip right back into coding with no fuss. By the end of the project my estimates for how long to finish a unit of work were accurate to 30 minutes (by then I'd been programming for two decades, so it wasn't all the process!). On the other hand, I wonder if Objectory/OOSE/Rational Process solves the wrong problem. If you're going to use imperative OO to build a big complex system, yea ... but maybe you should try e.g. functional programming. I.e. the other relevant development that came out of Ericsson was Erlang and was for the same problem space (e.g. telephone switches). Still, I feel that if you use parts of it correctly for the right sorts of problems (especially ones that are pretty well understood, e.g. I'd been figuring out for 5 years how to do my project correctly before I had a chance to do it as detailed above) it can be very useful.
  - hga 17y ago
    CORRECTION: the newbie had neatly iterated the design and I was able to slip right back into coding with no fuss

hello_moto 17y ago

There should be more people like you. The biggest problem in our industry is that there isn't enough mentors to tell the young people that they were wrong all this time.

modoc 17y ago
:) I think the biggest problem in the industry is that many of the "young people" (I'm still young, dammit!) don't really want to learn or be mentored. Seems like there's a slew of folks in the junior to mid-level developer arena who got into CS because it was going to make them a lot of money, not because they love to code. I love it when I'm working with people who love to tinker with new libraries and APIs, who are working on something neat in their spare time, etc... They make much better developers than folks with a CS degree who do what's assigned to them from 9-5 and that's it. I'm not saying you have to work a ton, but just be interested in the whole tech universe:)
- meta 17y ago
  As best as possible, I think a company should screen for that in the Interviews. (given that Interviews are sometimes a effectiveness gamble, I realize that it can be difficult to screen for that). I usually watch to see if they light up and get into conversations when I ask questions in the Interview related to our tech. If they don't get that expression and interest (hard to qualify but I think most people know what I am talking about) than that is a lot of hire points lost. If you spend an hour talking computers and they never 'light up', I feel, they are probably not the right fit.
- jerf 17y ago
  I blame the myth that young hackers are somehow strangely more knowledgeable than their elders because of the putatively ever-changing nature of technology. I've always been suspicious of this self-serving narrative (in what other engineering field is this true?), but as I approach what passes for Old Fartness in this industry (30) now I know it's bullshit. All the twenty-year-old whizzes I know are experts at taking something like Ruby on Rails, trading in the quality of the underlying framework to put together a hack-job very quickly, and then promptly getting themselves stuck in a morass that they can't get out of because they don't even understand why they are in a morass. Hand these people something with a lot of technical assets they can borrow against and yeah, they can toss something together fast, but that's hardly "better" then what I can do now, which is actually produce technical value. (Mind you, I'm not saying that's necessarily a bad thing. There's a time and a place for that. What is a bad thing is that the developer won't understand the tradeoffs they just made, and probably didn't make the tradeoff after a sober and careful balancing of the costs and benefits, but did it because it's all they know.) Anyhow, my point is that thanks to that mythology, a lot of younger people don't think they can be mentored by the old farts they think know nothing in this rapidly changing technical environments. The old farts (at least the ones who have ten years of experience and not one year of experience ten times) have learned that frankly, the tech world isn't changing that fast (different languages, different APIs, pretty much the same messes). There's plenty of mentoring to be done, but you gotta accept that the mentors are going to tell you some things that may shattered your treasured conceptions of the programming world....

bmelton 17y ago

I'm in almost the exact same boat, though I find that much of my job is in just predicting pitfalls, and in anticipating when things won't work. As a federal contractor for an agency that prefers to use COTS/GOTS software, there is a surprisingly great need for having a developer that can look at a given piece of software, intuit how it works, probe its sales and development teams to say "Well, this claims to do Kerberos authentication, but it really does GSSAPI, and hence, won't work with your existing OpenSSO implementation." I also code a lot, mentor other developers, etc., and yes, it IS a great role.

japherwocky 17y ago

This is much closer to the role a real architect plays in a real architecture firm. Sketch out the big picture, take care of the trickiest details, wrangle your underlings into doing the rest.