[TriLUG] Looking for Software Process Clue Stick

[Steve Litt]

On Fri, 11 Jul 2014 14:51:35 -0400
Scott Chilcote <scottchilcote at ncrrbiz.com> wrote:

> Hello LUGers,
> 
> I'm associated with a small software company that tends to follow this
> general philosophy:
> 
> 1. Analyze the problem.
> 2. Propose a solution.
> 3. Build a functioning prototype.
> 4. Demonstrate it to the customer.
> 5. Add features.
> 6. Deliver.

Nice!

When I was a programmer/analyst (otherwise known as a hired gun), I
pretty much used this same process. There's no way on earth I'm going
to flat bid the project, so I work by the hour, and if I work by the
hour, I'd better deliver something that works and shows promise within
one day.

I can't think of specific books or web pages, but I'll give a few of my
own opinions.

> 
> Notice that the prototype transitions into becoming the product. 
> 
> This process has worked reasonably well so far, due to the fact that
> they build small, simple components that are individually testable. 
> Then they combine them one at a time and wring out the interfaces.  It
> resembles Test Driven Development, but the tests are not especially
> rigorous due to the aggressive schedule.  The approach has a lot in
> common with unit testing, but in a RAD context.
> 
> My concern is that the customer's requirements are growing more
> complicated as we proceed.  This approach does not appear to scale
> well.  The customer expects a robust, modular, and extensible product
> at the outcome.

Sounds to me like either:

A) Your problem analysis was lacking, or

B) The customer is willy nilly adding krap and doesn't expect you to
   say "no".

If it's B, that's easy. Either tell them "no", or let them know that
this is brand new information requiring huge modification to the very
foundation of what they've received so far, do they want to proceed, or
just pay you for what they've gotten?

If it's A, well, that happens to everyone. This stuff isn't easy, or
we'd all be getting minimum wage. A couple hours' discussion with the
customer, plus a couple diagrams, isn't a sure-fire way to get a
complete spec. Just rewrite and try to bury the time in more productive
billable time.


> Past experience tells me that it will require more work to retool a
> prototype as the basis for the product, than it would to take what we
> have learned and make a clean start.  

As a guy who has worked on many Rube Goldberg machines that started out
as clean designs and then got all sorts of stuff bolted onto it by a
multitude of maintenance programmers of varying skill and programming
philosophy, I agree: making a rickety mess work is difficult, and when
something goes wrong it's more so. I'd rewrite.

> I have faced this problem over
> many years as a software engineer.  I can't think of a time that I've
> won the debate.  How do you answer "Can you guarantee that it will get
> done faster?" 

Is that asked by the customer, or by the principals in your
organization? If your own organization, ask them if they can
*guarantee* that bolting stuff onto a flawed base will get done faster.
Nobody has a crystal ball.

I get the impression that you can do the rewrite in a couple to a few
days. That sounds like a *much* better idea to me, assuming you believe
the current prototype to be structurally flawed.

> 
> That should not be the question, but it always is.  In the short term,
> building on the prototype gets results.  In the long term, it becomes
> the growing snowball of kludge.  We can break off pieces and clean
> them up, but only to a point.  It was not designed to be a structural
> foundation.

How about declaring a version 1, having the client work with that for
awhile while you make the version 2, which they think only delivers
more features, but you know is built in accordance with the problem
domain.

> 
> If anyone has a good source of wisdom on this topic I'd be very
> interested.  I already have Yourdon's "Death March", which seems
> premature.

All I can say is we all feel for you, we've all been there (at least
those of us who ever went freelance). Here is some stuff I wrote on the
subject almost 2 decades ago. The software is very different, but the
humanity and the principles are identical:

http://troubleshooters.com/tpromag/9809.htm

SteveT

Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance