Subject: fixing everything
From: Tom Lord <lord@regexps.com>
Date: Tue, 23 Oct 2001 01:31:10 -0700 (PDT)




Many years ago, with lots of guidance from my mentors, I wrote a
Usenix paper called "Tools and Policies for the Hierarchical
Management of Software Development".

It's not a great paper, but it's not bad.  It expresses some really
good ideas that are especially relevant to today's FSBs.

That paper brings together two important fields: 

	software engineering
	integrated development tools

The paper presents some particular software tools for "software
construction" -- higher level replacements for make.  It relates those
tools to an engineering management process: "hierarchical software
management".

The idea was that programmers would like those particular tools
because they were easier to use than writing makefiles.  At the same
time, managers would like those tools because they directly supported
and encouraged a particular workflow that can lead to improved
software quality without increasing costs or effort.

Tools and policies -- leading to quality.

Nowadays, I'm no longer particularly attached to those specific
software tools.  For example, GNU Make has enough advanced features to
eliminate the need for most of the software I wrote for that paper.
And besides, I developed those tools as a relatively inexperienced kid
-- so they weren't designed or implemented in ways that were
particularly mature.

However, I am still particularly fond of "hierarchical software
management".  I think it's an idea that makes a heck of a lot of
sense, especially when we expand the focus from "software
construction" to include the strategy formation process, the design
process, testing, documentation, custodianship, etc.

And nowadays, I'm interested in making money.  So I want to try to
bring together *three* important fields:

	software engineering
	integrated development tools
	free software business models

In my book, anyone who doesn't agree that you can't think about one
of those issues without thinking, equally seriously, about the other
two, simply doesn't know what they're doing.

So in coming days, I'll try to elaborate some specific engineering
processes, the tools needed to support those processes, and the
natural business models that arise out of this engineering process.

What I hope to develop is a picture of what the FSB world should look
like.  I hope to develop a relatively specific agenda for tool
development and process reform.  I hope to propose ideas that are
compatible with the existing culture of FS engineers.  I hope to
develop some particular business models that represent our real
future.

If I succeed, FSB decision makers should want to start working on
implementing this agenda.  If that implementation succeeds, FSBs
should have little difficulty entering and eventually dominating
*every* software market you can think of.  That's a very ambitious
goal, of course.

There are some difficulties with starting this thread.  One is that
the topics I'm going to raise are fairly large -- too large to fully
work out on a mailing list.  Another is that I don't think I have all
the answers -- I'm looking forward to well informed rebuttals and
opportunities to improve these ideas.  But if you don't start
somewhere you never get going.  So let's go.

-t