[extropy-chat] Some ideas... dumped

[Brian Lee]

I've found that management prefers the code grinders rather than mad genius 
because they lack vision. Not the "Vision" that biz books speak of, but just 
that management doesn't really know what a company or product is supposed to 
do, so they focus on what they can control: personnel, hours, code output, 
level of documentation, etc.

I reflect back on projects I've worked on: successful and unsuccessful and 
it seems like vision is the most important piece. I've been on 6 month 
projects with 4 people and no management. We had no documentation, no 
project plan, and we generated a full product that made millions its first 
year. Then I saw that same project add 40 people, multiple levels of 
management, project managers, product managers, qa, qt, etc etc and it took 
forever to get a new module out. The key difference was that in the 
beginning the four of us had a vision of what we were creating and worked 
toward the common goal.

Later, no one really knew what they had to do and were just sort of "going 
through the motions".

My preferred method of development is a very small, talented team with no 
management at first. There should be at least 1-2 "businessy" progs who can 
speak with investors and other business units to convey the message, but 
still able to generate clean code. Then the other 1-3 should just be hard 
core developers who can all understand (in theory) what the other developers 
are working on so they know what to code next.

The downside is that the project/team/company is a high risk for anyone to 
leave or die, but the upside is that there is no useless dead weight that 
drags against the finished software.

Of course, it's virtually impossible to find a small team of mad genius 
coders with a unified vision so I'm still waiting :/

BAL

>From: Emlyn <emlynoregan at gmail.com>
>To: ExI chat list <extropy-chat at lists.extropy.org>
>Subject: Re: [extropy-chat] Some ideas... dumped
>Date: Mon, 16 Aug 2004 10:26:53 +0930
>
>On Sun, 15 Aug 2004 16:13:34 -0700 (PDT), Adrian Tymes
><wingcat at pacbell.net> wrote:
> > --- Emlyn <emlynoregan at gmail.com> wrote:
> > > One is a concept of web-based identity management
> > > for people out in
> > > the world, to handle all the myriad email addresses,
> > > web site logins,
> > > files, calendars & schedules, contact lists, etc,
> > > etc, etc that we all
> > > accumulate but that get completely out of hand
> > > (because there's just
> > > so much heterogenous crap to remember, like
> > > usernames/password, or
> > > urls, or whatever).
> >
> > Been done.  Google doesn't just have search results
> > for this, it has a bunch of ads from providers.  The
> > main flaw: unless you own the servers, someone else
> > owns the machines your identity resides on.  How much
> > can you trust them?  (Granted, there's some of that
> > even now.  This is a lot more.)
>
>I had a private email to me pointing me to one of these. I must check
>them out, see how closely they match what I'm imagining. If they're
>good, I might try using one, and I'll let people know how it turns
>out.
>
> >
> > > I'll expound shortly on a half baked software
> > > development methodology
> > > that I've got brewing in my head, tentatively tagged
> > > "disposable
> > > code". The axioms are "assume you start with a few
> > > spectacular coders,
> > > genius hackers, who can kind of work together, are
> > > individually
> > > irreplaceable, and most of whom don't like working
> > > with each other.
> > > What can you do?". It's a reaction to the regular
> > > methodologies
> > > (standard big system & agile) which assume that you
> > > want to work with
> > > endless fields of stupified code grinders, and that
> > > the brilliant
> > > cowboys in the corner are a liability...
> >
> > The brilliant cowboys, like anyone, could get sick or
> > quit - especially if you (the business manager who
> > can't see anything but $) try to reduce their high
> > pay so you can pocket more profits.  Cheap code
> > grinders are widely available, and you still have the
> > code even if its makers quit.
>
>I'm well aware of the problems with using excellent people with unique
>skills/talents (rather than cookie-cutout grinders), but I think those
>problems can be ameliorated using the right approach. Mostly it's all
>variations on the theme of modularity.
>
>People have been slagging off the loner coders for a long time now,
>you know, those mad geeks who can't communicate but can churn out
>magic code that no one else can, and no one can understand. I think,
>given that most of our systems are built on a lot of this crazy magic
>code built by these guys (imo), it might be better to not throw out
>the baby with the bath water, and instead find a way to work with
>them.
>
>btw, I don't think the grind method is necessarily wrong, I just think
>there are valid alternatives.
>
> >
> > In reality, high-quality businesses require truly
> > trusted employees.  But try telling the paranoid
> > execs who have fought off all manner of cold-blooded
> > challengers to their business.
> >
>
>Yup.
>
> > As to this question itself, the answer is pretty
> > standard, if not often applied within a single
> > business unit: divide the application into each
> > person's responsibilities, and make a solid API.  If
> > someone needs a new API, they can negotiate for adding
> > it; the executive managing the project is responsible
> > for maintaining the API document itself, as part of
> > the project management documents (like the task
> > breakdown and schedule).  Otherwise, each programmer
> > is responsible for making sure their bit meets the API
> > perfectly (along with other, part-specific
> > responsibilities: databases don't lose data, UIs are
> > usable, and so forth).
>
>That's the kind of thing I'm thinking of, but I've got a mad idea
>about self documenting APIs (think web services, but promoted to the
>level of abstraction of a java space), and distributed systems
>composed almost solely of loosely coupled small pieces, so that the
>overall central control of the api is less necessary, and so
>individual pieces can be replaced almost at whim. There's more to it
>than this... I must sit down and blog this thing.
>
>--
>Emlyn
>
>http://emlynoregan.com   * blogs * music * software *
>_______________________________________________
>extropy-chat mailing list
>extropy-chat at lists.extropy.org
>http://lists.extropy.org/mailman/listinfo/extropy-chat