[lug] software engineering

[David Morris]

On Thu, Nov 30, 2006 at 12:03:56PM -0700, Zan Lynx wrote:
> On Thu, 2006-11-30 at 11:19 -0700, David Morris wrote:
> 
> > The concept you're striving for here is Systems Engineering,
> > a field newer than even software engineering.  At least as
> > an official engineering discipline, people have *done* it
> > for quite some time with varying degrees of success.
> > 
> > In short, the traditional engineer is focused primarily on
> > how something should be done, while a systems engineer
> > focuses more on the question of why.
> 
> This description sounds like what I was taught as Systems
> Analysis. There are plenty of Systems Analysts working in
> the computing field, usually as consulting experts.
> 
> And of course, plenty of software engineers end up doing
> this sort of unofficially.  When you see what you're being
> asked to do and you go ask, "Why do you want a system
> designed to print out the reports here, make copies in
> triplicate, send one copy for filing, one for the
> archives, and one to a clerk who is going to re-enter it
> into a different computer system?  This would be so much
> better if ..."

Exactly.  There are lots of people who *are* doing it, but
not in any sort of formalized way.  The project I just got
off of and my role on it was a perfect example of how this
can cause problems.  I ended up doing systems engineering
type work, but the project could not recognize this and so I
had all the responsibilities of a systems engineer with the
authority of only a software engineer.  The result was a
disaster.  I was too involved in detailed software
engineering to focus on the higher level view so I didn't
have enough information to convince the project of the
answers to those difficult "why" questions, so huge problems
were ignored until they slapped management in the face a
week after a solution was needed.  The software engineering
tasks also suffered because I wasn't able to focus on the
low level details the extent I needed to in order to
effectively solve problems.  Conversely, when we started the
project we had a dedicated software systems engineer.  The
difference was staggering.  I could trust him to look out
for the higher level concerns and he trusted us (the
development team) to take care of implementation details.

It could be the Systems Analyst positions provide this role
on a project, but I would argue a "consulting expert"
filling the role is the worst possible route to filling the
need.  A consultant is, by definition, around for only a
short time. I have seen time and time again that systems
engineering is easily ten times more effective if available
for the *entire* project from conception until the bitter
end. Admittedly, a consultant will bring a greater level of
experience (vital in systems engineering), but coming on
late or leaving early can have many adverse impacts to the
project.  I can see using consultants for a specific small
task, such as determining requirements, but not as the main
systems engineering presence.

--David