[lug] software engineering

Sean Reifschneider jafo at tummy.com
Wed Nov 15 11:18:09 MST 2006

On Wed, Nov 15, 2006 at 01:13:45AM -0700, Nate Duehr wrote:
>This possible solution to the dilemma falls apart a bit on the example 
>from today, though... someone *is* paid to write the installer for 
>Ubuntu, methinks.  Hmmm.

The point I'm trying to make is not whether someone is paid or not...  The
comparison was brought up between civil and software engineers.  Both are
usually paid in the course of their work.  Funding levels for the Golden
Gate Bridge and the Ubuntu installer are quite different.  When you don't
have the funding, you may cut corners in things like the description of the
"Expert" installer mode.  That's the point I'm trying to make.

Of course, the $75m that went into the bridge went a lot towards raw
materials.  But, a lot of that went to design, engineering and
construction, particularly in todays dollars.  This was $75m in the 1930s,
when a million dollars was Real Money (tm).

I have no numbers to back up what the costs of designing, engineering,
and constructing a bridge are spent on the people doing the work, which
would make it more of a fair comparison...  However, my gut feel is that
the funding levels are much higher there than they are in a lot of

While a lot of the effort of creating a bridge is just the moving around of
Heavy Stuff (tm), I'd still say that the complexity of engineering the
Golden Gate Bridge is on par with at lot of software projects.  Again, no
hard numbers for comparison between civil engineers and software engineers.
This is all speculation.  But, when you're dealing with millions of dollars
of Heavy Stuff, and lots of people using it, I think it's easier to get
serious funds for the engineering than it is with, say, building
another installer...

>lurking, right?  Our installers are "our" first and best chance to put a 
>good foot forward, and if the darn stuff won't even install -- that 

Sure, I hear what you're saying.  However, installers are in a Hard Spot
(tm).  On the one hand they are the users first software they run in a
distro, and their success is pivotal to that user being able to use other
software.  On the other hand, once the installation is done, that user may
not use the software again for a year or more...

>"We're a Cisco shop.", like that's the only router in the world.  :-)

We periodically tour facilities in our work, and I feel bad for the sales
guys pushing their nice shiny facility and saying proudly "We're a Cisco
shop" because as soon as they say that, my reaction is to subtract a few
points.  Largely because of experience.  I think Cisco is getting better
these days, but they've had a lot of problems keeping up with new
technology they've purchased, being able to correctly integrate it into
their test and support infrastructures.

>You think there are that many?  I think that's the mystery I'm trying to 
>solve there... just how much testing REALLY goes into things?  I know 

Sure, I think there are that many.  When interesting software offers real
beta programs, they tend to fill up quickly.  Most Debian users I know are
running testing or even unstable unless they're in a production
environment.  Gentoo is a distribution built just for these software test

>etc... kinda a "proof is in the results" approach, but no good way to 
>tell if the last 100 patches broke something major in an installer?  Do 
>you kinda see where I'm headed here?

I don't see that as the test pilot job, but I see what you're getting at.
There have been various efforts to run various components through
regression tests regularly, but it seems like one of the things that Linux
uses to it's advantage is just throwing out well-reviewed software for the
users to test in their exact environment.

As far as I know, all the efforts to regression test have been pretty
limited in scope and haven't really gone anywhere long-term.  Regression
testing takes a lot of effort and a lot of hardware to do right.  I think
regression testing is good in theory, but in general I think the Linux
processes have worked well I think.  I mean, Microsoft does regression
testing of their software, right?  And they're aren't known for having great

>Heh.  Nice.  But only one guy, and no army of testers wanting to take 
>his spot?  There's still a motivation problem underlying all of this 

No army of testers?  Are we talking about the same Linus?!?

>Okay, but is experimentation and goofing off really disciplined formal 
>testing?  I get it... I do, but I'm asking where the next level is. 

I may just be taking the "test pilot" idea too far, so maybe a better
analogy is in order.  Not sure what though.  My picture of the superstar
test pilot is not one of disciplined formal testing, but trying out
experimental new technologies...

 Read error: 666 (Connection reset by Satan)
Sean Reifschneider, Member of Technical Staff <jafo at tummy.com>
tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability
      Back off man. I'm a scientist.   http://HackingSociety.org/

More information about the LUG mailing list