21–30 of 56 posts
I tend to believe that the job of an architect is not to make the important decisions but to make sure the important decisions get made correctly and to take responsibility for that process and its results.
Earlier quoted context omitted.
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.
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 sor…
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.
They claim that only about 1 out of 5 programmers "get" abstraction. To the extent this is true (and it agrees with my experience in the field starting in 1977 including a dozen years in and around MIT) you can't have "democratic" design processes, for the "software architects" who do get abstraction will be voted down and you'll end up with the usual mess of spaghetti (or whatever they're calling it nowadays).
Hmmm ... another problem I ran into was understanding scaling, O(whatever) issues. At least one project I declined to join died horribly because the people in it couldn't grok that their design wouldn't scale to the level needed for basic customers, let alone big ones (in this case the lead had only done CD-ROM based applications, so his library code for the DB didn't even work when they tested 2 clients, but the bottom line was equivalent to trying to use e.g. the biggest baddest version of Oracle to implement a Google scale internet search engine).
Earlier quoted context omitted.
I'm not justifying the term software architect (I don't like it for other reasons) What are your reasons, BTW?
One reason might be that "real" architects get a bit upset at the use of it in the software world.
After some years of this mindset I finally realized that the proportion of excellent people to mediocre ones is roughly the same in every profession. I no longer draw the lines between "hackers" and "suits" (a kindergarden attitude, really), but between excellent people and mediocre people. It's liberating. You can go into any profession with this mindset and it will be your own personal playground.
Earlier quoted context omitted.
This blurs into my vision of top-notch software engineer without the fancy title, which was the reason I wrote that post in the first place.
In my experience the title is really there to identify who will get shot if the damned thing doesn't work for fundamental technical reasons.
Programmers often neglect the fact that not all problems need to be solved with more code. More specifically, there are problems that are better solved at the architecture level. For example, rather than queue jobs in a wonky static variable, use RabbitMQ or Redis. And instead of implementing search functionality through Hibernate, consider a separate stack which you can grow independently of your core application. W…
I'm not justifying the term software architect (I don't like it for other reasons) What are your reasons, BTW?
Architecture school is very hard, mentally and physically. The perk is the weird mystique that society gives us.
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 t…
Sketch out the big picture, take care of the trickiest details, wrangle your underlings into doing the rest.
Earlier quoted context omitted.
:) 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 ar…
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…
Many of us "20-year-old whizzes" don't do what you describe at all. In fact, as a Systems programmer, it's not incredibly likely that you know 'better than me' what the implications of what you're doing are at an Operating System level. I know 20-year-olds who have contributed source to Linux, Chrome, Firefox, and a number of other Open Source projects. Folks who have worked in industry for 2-4 summers in a row already. 20-year-olds who have gone to Silicon Valley and done the startup thing. (I can go on with this BS forever)
But all that 20-year-old ego stuff aside, it's also important to remember that this is a field that is routinely dominated by disruptive thoughts, ideas, and personalities. All of your experience becomes a hindrance when you start to follow your old steps to the "right solution" every time. For that reason, it's also important that you look to the "20-something whizzes" for insights and ideas that may surprise you and that you actually consider what they say.