[lug] software engineering

William D. Knoche Bill.Knoche at Sun.COM
Mon Dec 4 10:33:17 MST 2006


<stuff snipped...>

I guess I am not too concerned about all this.

I have held the System Engineer title many times at several companies (though 
not recently).
Here, at Sun, the title is used differently but I help it here too.
Almost everyone in product engineer has the title Staff Engineer (including 
myself) though we all know that we all have the responsibility to do the system 
engineering role or at least question what is being done and why. I have friends 
at other companies like IBM and HP and yes even Microsoft where this is also true.
When I was in IT the system engineering role was held by the "architects".
I am far less concerned with who actually does it as much as whether it gets done.
There are lots of popular engineering "styles" that suggest this gets done at 
various stages and by various roles.
I see lots of teams using some strange combinations of extreme engineering, 
design for test, design for quality, etc.
There are undoubtably many ways to get a sufficiently well designed, well 
implemented product of adequate quality built and delivered.

Much of the concern seems to be over a notion of absolute quality and a romantic 
notion of "better times". Well, that notion may well be dead.
We saw it in the automotive industry. I was sure MB had sold out and that very 
well built, finely engineered cars were history. The reality was that in general 
folks weren't willing to pay for that and they wanted a new car every 3-5 years 
anyway (designing cars to last 20 years no longer made sense). We all lament 
that cars are designed to last 100k miles and they pretty much fall apart 
shortly there after. But, that became the design point and we can't then argue 
that engineering didn't understand what they were supposed to do or that 
management made a poor decision - they decided that was the economic model and 
directed engineering to drive all the cost out of a 100k mile car that requires 
no maintenance. Apparently that is successful since that is what folks are buying.

I should also note that over the years specific responsibilities have been 
shifted from one org to another and sometimes back.
When I started writing code for DOD even unit test and design review was owned 
by the QA folks. Now it seems that engineering owns unit and integration testing 
and QA does final test as large external "betas", sometimes as the actual 
product release (fixing the bugs as customers find them) shifting the role to 
support.
It would seem at them moment the support orgs own most everything from inbound 
marketing, product requirements, revenue attainment (in the Stallman model since 
the bits are free), test and root cause analysis,  and of course patch delivery.
In the end everything is starting to look like a "system integration" problem 
executed by the service org.

It should also be noted that a popular joke a few years ago was that the biggest 
contribution form the worlds largest software company was a demonstration of 
just how low one could set the quality bar and still get people to pay $100 year 
after year. It was of course intended as a very nasty criticism but now seems to 
have turned out to be a useful metric that everyone is using.

Things will likely change some more, some will embrace it, some will hate it and 
many will "discuss" it.
Coming from a science background I am compelled to say that this is all a good 
thing - as long as there is active disagreement and discussion and change things 
over time will move in a more "successful" direction (evolve).

I don't know where we will end up, how long it will take, or if any of us will 
like it but I do know how it will happen.

-- bill
___________________________________________________________________
William D. Knoche                       Bill.Knoche at Sun.COM
I/O Technologies
Market Development Engineering          Phone:    303-223-4848
Sun Microsystems, Inc.                  Fax:      303-223-4848
500 Eldorado Blvd. UBRM05-150
Broomfield, Colorado 80021
___________________________________________________________________




More information about the LUG mailing list