Software Design (was: Re: [tlug] Confessions of a closet OpenBSDuser)

[Josh Glover <jmglov@example.com>]

Jack Morgan wrote:
> On Fri, Jun 28, 2002 at 01:42:01PM +0900, Stephen J. Turnbull wrote:
> 
>>My point is just that (1) as developers we need to aspire to standards
>>higher than "talented amateur," and (2) as users and admins we need to
>>_demand_ higher standards from the development _process_, if we want
>>open source to continue to grow healthily, both in the market and
>>overall.
> 
> 
> So how can we demand higher standards? Well, for starters as Matt as indirectly
> suggested, just don't use the product.

Or, as I proposed, get involved in the projects upon which you depend 
and see how things work behind the scenes.

I am going to pull on my asbestos trousers here and let you know what I 
think about OSS in general:

Many Open Source projects are complete shite. So are many commercial 
ones, but one thing that the commercial environment *has* foisted upon 
some professional coders is formal and careful design.

Now, before I launch into what might be a very messy thread, let me 
offer these disclaimers:

1) I am a big proponent of Open Source, but I am not willing to pretend 
that it has no problems.
2) I make no claims that all commercial software is carefully designed 
and that OSS never is.

Now, the analysis:

Frankly, one of the things that made Unix so much fun in the early days 
was The Hack. Whipping out a sweet little hundred or so lines of 
assembler or C or Lisp (etc.) in a feverish several hours, and having 
the thing *work*! I will admit to many hacks in my own coding, and I 
will also admit that there are few things that give me such pleasure as 
pushing back from the keyboard, eyes bloodshot, brain dead, and fingers 
twitching and numb from too much typing and caffeine at the end of a 
crazed hack session that finished right up against a deadline.

However, hacking is hardly compatible with good software design, and 
good software design is quite lacking in OSS in general.

Part of this is that a lot of the people who helped make Unix what it is 
today are not software engineers and have no real desire to become 
involved in software design theory. This is well and good, as many of 
the Unix utils that we use so heavily are pretty close to perfect now, 
as a result of being very small and specific, and so many people using 
them for so long and having access to the source. In a situation like 
that, applying a quick fix to make something work for you is not a bad 
thing.

However, one thing that Windows users and GUI guys generally point out 
is that the Unix environment is not terrible cohesive. This is the 
result of the way the system was developed, a common philosphy guiding 
many different coders to provide the tools that a usuable OS needs. What 
*is* cohesive about Unix, however, is the way things work. A collection 
of small and specific tools combine to allow you amazing flexibility. 
IDIC,[1] if you will (and I expect that most of you Trekkies out there 
will! ;). So Unix works.

Now, let me bring software engineering back into the spotlight. Compare 
two highly visible Open Source projects: Linux and FreeBSD (I choose 
Free because it is the oldest Berkley based Open Source Unix, AFAIK; I 
have heard that Net actually has a cleaner design, so maybe it would 
have been a better example). BSD has a pretty careful design, and it 
shows. It is generally considered to be more stable than Linux in 
extreme situations, and I would argue that the design philosophy is 
heavily responsible for this. Linux, on the other hand, has a more 
haphazard design, and the Linux developers tend to be more interested in 
adding functionality quickly than the BSD guys. The result? Linux has 
undergone *many* complete redesigns of major subsystems that were not 
particularly well-designed.

I am not dissing Linux here, I am stating what I believe to be The 
Facts. Feel free to disagree with me if you feel that I am mistaken.

My contention is simply that the design of a lot of OSS is, to quote a 
co-worker, "sloppy". And this sloppiness can exhibit itself in bad ways, 
as was the case with the recent OpenSSH vuln. I am not calling the code 
sloppy here, just the design.

Elegant and efficient code *is* very important to a successful piece of 
software, but so are design and *gasp* documentation.

Coding off the cuff of your sleeve is perfectly fine for software that 
is not going to be used in mission-critical or security-concious 
situations. When poorly designed code is used in either of the 
aforementioned roles, bugs that pop up due to poor design are just going 
to provoke statement's such as Jack's, which started this email off. I 
do not like what Jack is advocating in this specific case (meaning that 
I do not think abandoning OpenSSH is necessary, for the reasons that I 
and others have posted previously in this thread), but his is definitely 
an option: stop using software in which you are not confident and thus 
force the developers to a higher level of quality if they want to "compete".

So what is to be done? Well, I hope that more computer scientists (as 
opposed to the "talented amateurs" that Steve mentions) get into OSS. I 
think that software engineering is a very promising field, and that good 
design is essential for high quality projects that contain more than 
1000 or so lines of code. The good news is that university Computer 
Science programs seem to be pimping software engineering and object 
oriented programming a lot more than they used to. Software engineering 
is by no means a perfect discipline, but how can a formal study of 
software design hurt!? Simply studying a little theory should raise a 
lot of questions and intelligent thought in the mind of a good coder, 
and thinking has been scientifically proven to create better software! ;)

Now, my attraction to OOP is that it allows you to implement from a good 
  design (which should be modular, one would hope) in a way that 
expresses itself in the code.

These thoughts are certainly not complete, and not as eloquent as they 
probably should be.

I would like to hear what some of you think, especially Steve, whose 
previous posts on how XEmacs development works have intruiged me (in a 
good way, don't worry).


-- 
Josh Glover <jmglov@example.com>

Associate Systems Administrator
INCOGEN, Inc.