[lug] Career advice

[David Morris]

On Sun, Jan 3, 2010 at 12:36, Nate Duehr <nate at natetech.com> wrote:
>
> 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.

This is where a "Systems Engineer" comes into the project.  Note that
I use the word in the traditional engineering sense, NOT the
bastardized definition being applied to administrators to satisfy
egos.

The purpose of a "Systems Engineer" is to provide the interface
between Customers and Engineers.  They balance requirements, design,
customer needs, and customer feedback.  The Systems Engineer also
provides the interface between different engineering disciplines (when
relevant) and/or multiple groups working on different aspects of the
project.  In order to be fully effective, a Systems Engineer should be
outside the project structure.  The lead Systems Engineer on a large
project (or the only one on a small project) should have authority
almost equal to the project manager he is working with.

Strictly speaking, a "Systems Engineer" is an optional role in any
project...many successful large projects who have nobody who fills
this role.  However, a good Systems Engineer can make a big difference
on a large software project, including helping to avoid the problem of
the "beautiful designed but totally useless software".

I've worked with some great Systems Engineers over the years in the
Aerospace industry, and worked other projects with a complete lack of
them.  It can make a big difference.

--David