From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <0f120489807d451fadb7c7768fef6dbe@bellsouth.net>
To: 9fans@9fans.net
Date: Fri, 26 Dec 2008 15:44:59 -0600
From: blstuart@bellsouth.net
In-Reply-To: <20081226185254.GA1176@polynum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Changelogs & Patches?
Topicbox-Message-UUID: 717ab356-ead4-11e9-9d60-3106f5b1d025

> On Fri, Dec 26, 2008 at 01:20:17PM -0500, erik quanstrom wrote:
>> appropriately, this being a plan 9 list and all, i find code
>> written from the bottom up easier to read.
>
> Depending on the task (on the aim of the software), one happens to split
> from top to bottom, and to review and amend from bottom to top.
> There is a navigation between the two.
>
> Bottom to top is more easier because you are building more complicate
> stuff from basic stuff.

Some time back, I was trying to understand how to teach the
reality of composing software.  (Yes, I do think of it as a creative
activity very similar to composing music.)  The top-down and
bottom-up ideas abound and make sense, but they never seemed
to capture the reality.  Then one day, after introspecting on the
way I write code, I realized it's not one or the other; it's outside-in.
I don't know what little tools I need to build until I have some
sense of the big picture, but I can't really establish the exact
boundaries between major elements until I've worked out the
cleanest way to build the lower-level bits.  So I iterative work
back and forth between big picture and building blocks until
they meet in the middle.

As an aside, that's also when I realized what had always bugged
me about the classic approach to team programming.  The
interfaces between major parts really comes last, but in assigning
work to team members, you have to force it to come first.
And of course, from that perpsective, it makes perfect sense
why the best examples of programming are ones where the
first versions are created by only 1 or 2 people and why the
monstrosities created by large teams of "professional software
engineers" are so often massive collections of mechanisms
that don't work well together.

BLS