Re: Programming By The Seat Of Your Pants
From: mikel (mikel_at_evins.net)
Date: 10/22/03
- Next message: Jock Cooper: "Re: Why don't people like lisp?"
- Previous message: Doug Tolton: "Paul Graham bio pic is from ILC"
- In reply to: David Steuber: "Programming By The Seat Of Your Pants"
- Next in thread: David Steuber: "Re: Programming By The Seat Of Your Pants"
- Reply: David Steuber: "Re: Programming By The Seat Of Your Pants"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 22 Oct 2003 09:59:55 -0700
In article <m2he21a30w.fsf@verizon.net>, David Steuber
<david.steuber@verizon.net> wrote:
> This isn't really quite on topic for c.l.l, but it is strongly
> related.
>
> I am in a situation with myself where I need to basically code by the
> seat of my pants. Why? I have no design, no solid requirements, and
> generally have only a vague idea of what I want. Lisp* seems like
> the tool for the job. Besides, the only way I'm going to learn Lisp
> is to program in it.
>
> Programming by the seat of my pants is something that I do more often
> than not. Sure, I don't have a solid idea for my project, just a
> vague notion. It is never really that different in the business
> world that I have had experience with. The business wants X but they
> don't seem to want to tell me what X really is.
>
> When pressed, the business will come up with what they think is a
> precise definition of X. To me, it is still hand waving, only with
> pictures. Then they like to say, "so how long will this take?" Um.
> Yeah. If I knew how long it would take, then I would know what the
> problem was and its solution. If I know the solution, I have already
> solved the problem.
>
> I can't seem to convince people that time estimates are crap. There
> are even programmers out there who think that meaningful time
> estimates are possible. If you are one of those people, please tell
> me what the hell you smoke so I can get some.
"Extreme Programming" is the buzzword/brand-name for the particular
variety of packaged experience that I've seen working well with this
problem domain. There are other approaches that have pretty good
reputations.
I've been doing this software gig for about 15 years and have worked on
a variety of small-to-large projects. Some have been very well
organized and successful, some miserable failures. The most
consistently successful one I've ever seen is the one I'm working on
right now. It started as a group of engineers in a company that had
just discovered that its market had evaporated, and so we had to --
quickly -- come up with something we could do and that people would
want to buy. How's that for vague and underspecified? Well, we did it.
For various reasons, several of us liked the "Extreme Programming"
approach, and persuaded the company to adopt it as a methodology. It
has worked very well. To boil it down, you get a customer to make some
demands. You turn the demands into 'stories' (a paragraph or so for
each customer-imagined feature that explains what the customer wants it
to do).
Then engineers pair off and estimate how long it will take to implement
each feature. If one of them takes less than a day, you combine it with
something else. If something takes more than about five days, you break
it up into pieces and estimate those. That's because estimates less
than a day or more than five days are worthless.
Then your pairs of programmer implement, for each feature, the simplest
possible thing that could be said to satisfy the relevant 'story'. You
do it by first writing unit tests for something that, if it passes the
tests, it's a solution. Then you write code that passes the tests. Then
you show it to the customer and say 'what's wrong with it?' That
generates an amended version of the story and you repeat until the
software is (close to) what is wanted.
Key things are:
- you talk to the customer all the time
- you work with another programmer because it's faster and more reliable
- you test all the time
- you always have running code (one of our rules is that if anything
breaks the build or the test suite, everyone drops everything and works
on fixing the software until the build and the test suite work again;
in two years I don't think we've had a breakage last longer than about
a day).
- you refactor all the time.
Dynamic languages are very good for this model. It comes out of the
Smalltalk world, but Lisp is of course very good for it.
I've no doubt that there will be people who don't like the model, but
it has worked very well for us. Our survival has depended on it working
well, so you could argue that compels it to succeed; but on the other
hand, it's still a model that we were able to succeed with.
I think it's a lot friendlier to hackers than the waterfall model, and
other models that emphasize ultra-detailed specs and long formal
processes. The problem with those is exactly what you suggested: the
problem needs to be essentially solved before you do any work on it,
and that's rarely the case in writing software products or software for
business. Much more often the customers only have a vague idea of what
they want. The model of coding up a first approximation really fast and
showing it to them allows them to look at it and say 'yeah, but it
should do this instead', and you can triangulate the specification
fairly rapidly.
-- snip --
- Next message: Jock Cooper: "Re: Why don't people like lisp?"
- Previous message: Doug Tolton: "Paul Graham bio pic is from ILC"
- In reply to: David Steuber: "Programming By The Seat Of Your Pants"
- Next in thread: David Steuber: "Re: Programming By The Seat Of Your Pants"
- Reply: David Steuber: "Re: Programming By The Seat Of Your Pants"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
