On Wed, Mar 13, 2002 at 10:05:37AM -0500, Teodor Zlatanov wrote: > On Wed, Mar 13, 2002 at 01:51:08PM +0000, David Cantrell wrote: > > No, we're not lagging behind. Software engineering is VERY young - at > > most, 60 years old. Civil and naval engineering are more like four > > thousand years old and mechanical engineering at least two thousand years > > old. It is no surprise that they have managed to iron out a great deal > > more bugs in their processes than we have. And no, I don't think all our > > bugs are ones which have been solved in other engineering disciplines. > I don't think that's a valid comparison. Cars and planes have been > built commercially for only 100 or so years, a span of time very > comparable to software engineering's life span.
When I said "at most 60 years" that's because that's how long computers have existed, and so different people would have different definitions of software engineering. AFA*I*C, software engineering has only been an industry (as opposed to a small bunch of craftsmen providing bespoke solutions) for a considerably shorter period - 20 or maybe 25 years. Cars and planes are a comparitively recent mechanical product. Factories were mass-producing stuff long before - trains, mining equipment, weapons, machines for other industries, etc etc etc. And car and plane manufacturers drew on that pre-existing expertise. > If you would claim that > the mechanical know-how for cars and planes was around long before, > well, mathematics have been around for a while as well. No, I was talking about the processes by which that know-how are applied. > Which brings up another point. People who don't know the math and > algorithms behind programming should not be writing commercial-grade > programs. That we allow, even encourage such programmers to code by > paying money for their services, is one of the reasons why software in > today's world lags behind the other engineering disciplines. I am not > saying we should all have taken college-level courses, but at least an > understanding of concepts like base-n number systems, O(n), and theorem > proof by induction should be a requirement for every commercial programmer > (examples drawn at random). Not *entirely* sure about the latter, but mostly yes. But then, there isn't actually anything stopping me from picking up a hammer and setting up shop as a metal-worker. Other than that I'm not very good at it so won't be able to make much of a living at it. Likewise, there's nothing stopping J. Random Shitwit from picking up a compiler and setting up shop as a programmer. Of course, he probably won't be very good at it. But because our industry is so immature, it's hard for customers (at least the smaller ones) to gauge his competence. > I don't think any amount of QA, documentation, project management > skills, or any other procedural tools can correct for the basic skills > missing in programmers on a team. Of course. So how do you gauge whether a new hire has the necessary skills? Another unfortunate symptom of our immature industry is that there are little in the way of universally recognised qualifications. I sure as hell can't rank someone with a CS degree as being better than someone who is self-taught - whereas "proper" engineering degrees are a pretty damned good indicator. -- David Cantrell | [EMAIL PROTECTED] | http://www.cantrell.org.uk/david This is a signature. There are many like it but this one is mine.
