[lug] Career advice

Nate Duehr nate at natetech.com
Sun Jan 3 12:36:21 MST 2010


On Jan 1, 2010, at 9:13 PM, David Morris wrote:

> On Fri, Jan 1, 2010 at 18:43, Rob Nagler <nagler at bivio.biz> wrote:
>> On 1/1/10, David Morris wrote:
>>>  A good software architect is critical to the success of a large
>>>  project, but many software projects don't have anyone with the
>>>  appropriate skill set to architect a large software system.  Every
>>>  successful software project has such a person, though the managers
>>>  don't always realize it.
>> 
>> Fascinating.  Either my company has no successful software projects,
>> or your statement is false.  Since there are quite a few companies
>> which rely on our software, and we have been in business for 10+
>> years, your statement is false.
> 
> I'm guessing you misunderstood my statement.  Not surprising as I
> don't even understand what that paragraph says and I wrote it. I can
> only assume temporary insanity at the time I wrote that!
> 
> So let me rephrase:
> 
> A software architect is critical to the success of any large software
> project.  Every such successful project has a software architect (or
> sometimes more than one), but not always designated as such.  The
> person filling that role might not even realize what he is doing and
> consider it simply good software engineering practice.  But the
> existence of a good software design (as indicated by a successful
> project) is a clear indication that someone, knowing or not, filled
> the role of a software architect.
> 
> I should also note that in my experience, a "software architect" is
> one of the people actively writing code.  People who call themselves
> "software architects" but don't write code or only do so as a
> secondary task are managers.  I have worked on projects with a
> "software architect" who never touches code.  They might have the
> title, but they are most definitely not the software architect for the
> project.  Someone else ends up fulfilling that role in their place
> from among the coders.


How do we factor in situations where a company is "top-down" controlling software in this way and ignoring user and tech support feedback on the customer's desires, though?  I've seen beautifully "architected" software fail utterly miserably in the real-world because either a) the Architect was so disconnected from reality that they didn't know what the customer actually wanted, or b) whole areas that should have been included (Network/Software SECURITY issues often fall into this category) were completely ignored by the Architect.

"Yeah, that's great software, but no one will ever let that on their Network, let alone allow that code anywhere near a public IP address."

Seen that more times than I can count in Tech Support roles over the years.  And sadly, in about 75% of the cases numerous people could "see the train-wreck coming" but upper management had been promised by the Architect and their management that the code would release on a certain date, come hell or high water, and everyone else knew it'd never sell to anyone nor make the company a dime.

--
Nate Duehr
nate at natetech.com

http://facebook.com/denverpilot
http://twitter.com/denverpilot








More information about the LUG mailing list