[TriLUG] Looking for Software Process Clue Stick

[Steve Litt]

You're going to think I'm crazy, Scott, but I envy you...

On Mon, 14 Jul 2014 08:37:23 -0400
Scott Chilcote <scottchilcote at ncrrbiz.com> wrote:

> Hi Steve, thanks very much for your reply.
> 
> On 07/11/2014 07:29 PM, Steve Litt wrote:
> >
> > 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".
> >
> 
> I think that my description of our situation painted too rosy a
> picture.  I can use the term "demo-ware" instead of prototype.  When
> we sit down with $BIG_CUSTOMER and get a description of their
> problem, it never describes the entire situation.  This occurs at the
> beginning of the negotiation stage.

I think this answers your original question. It sounds like what you
presented them was sort of like a pencil sketch of the machine you'd be
bolting together for them. They might not have known it, but it sounds
like that's what it was. The only thing a pencil sketch can be used for
is a diagram: You can't build a nuts and bolts machine by adding stuff
to a paper with a sketch on it.

> In one example, they showed us a client-server system that they use
> at a production facility that requires several manual, command line
> operations to complete a process that they perform regularly.  The
> process was tedious and error prone, requiring hours on a weekly
> basis. We took notes and screen captures from this meeting, then
> returned to our offices and quickly assembled a prototype of an
> automated process using a web application that we had previously
> developed. 

If I'm not mistaken, you basically made a shellscript with environment
variables and arguments to replace the command line operations, and
oversaw the whole thing with a GUI, right? Nice!

> 
> Two weeks later we showed them a demonstration of a simple graphical
> client that performed the whole process, prompted the user at each
> step, and displayed progress.  They really liked it.  But at this
> phase in the negotiation process, no opportunity for serious analysis
> had occurred. The demo is more of a selling tool ("we can fix this")
> than a foundation for the product. 
> 
> We can't get started on that until hands have been shaken and papers
> signed.

Ahhh, you guys have much more risk-tolerance than I ever had. For one
thing, you're offering a specific deliverable for a specific dollar
amount. Secondly, it sounds to me (please correct me if I'm wrong) that
the deliverabe and the dollar amount are decided before all info on the
problem domain have been captured and understood by your company.

> 
> Once the contract arrives, we are able to find out the full details of
> the target environment.  That's when we discover things about the
> communications link between the client and server system and allowable
> protocols.  That's when we find out which variant of which operating
> systems are in use, how the systems are firewalled, and what
> applications, services, and other limitations exist. 
> 
> So the full requirements arrive well after the initial demo.
> 
> > 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.
> 
> A fair amount of the problem is fueled by unrealistic expectations
> from our own management.  We have a good development team, and we have
> managed to pull rabbits out of our hats in the past by having enough
> of the right pre-built products, and the ability to leverage a lot of
> great free and open source code to make something that works
> effectively. Management begins to view our estimates as padded
> because we get done more quickly than we expected.

Typical management. Too bad they haven't spent a couple years coding
their own analysis, or they'd know better. But, as we all know, only
non-fun thing about coding for a living is the know-nothing
(about programming) management.

> 
> What I was attempting to describe initially is that, having satisfied
> $BIG_CUSTOMER a few times using this approach, they want to use us to
> solve more intricate problems that a specific to their production
> process.  That's where we run into problems.  The likelihood of
> finding existing software products that we can crowbar into a
> solution begins to fade. 

Hmmm,

I'm just thinking: Give me a moment...

What if you were able to isolate the intricate problems specific to
their production process: Get those away, separate. Specifically,
remove all GUI from them: Encapsulate them into pure logic and data.
Know and understand which parts can't be taken off a shelf and bolted
on, but must instead be procured from the machine shop. Do everything
possible to minimize what must come from the machine shop.

Now, for the off-the-shelf part of the job, do what you've always done,
and for those few custom machine shop parts, use Python plus all its
libraries: Python has a library for every conceivable thing. Python
code's pretty concise if you don't need to go GUI. Make sure your tiny
nuggets of custom code have an agreed upon "API" that the
off-the-shelf crew can easily use.

I'll tell you a little story. Dot Com Boom, I get a call from a very
pragmatic (and over 40, he'd been around) IT director at a startup.
These guys have some sort of network of huge Cisco routers all over the
country, supplying Internet to buildings, with software to control all
those routers via SNMP. Trouble is, the software was far from ready.
Their team of 6 Java Jockeys was busy with Enterprise Javabeans and who
knows what else, with probably over six digits of lines of code, and
nothing was going to be ready for weeks. They were still doing their
Cathedral waterfall analysis or whatever people with lots of time do.
Their customers were screaming bloody murder and getting ready to bolt. 

The IT director told me he'd heard of me, knew what I could do, and
wanted me to build the thing, in a week, in Perl with Perl's SNMP CPAN
module. He even gave me a brief tutorial on SNMP. Five days I delivered
the product.

It was ugly. All CLI, not particularly intuitive, but it enabled
everyone to run their routers, and prevented a mass exodus by
customers. It gave the Java Jockeys not only more time to do their
product right, but gave them an understanding of the problem domain
and customer expectations. Everyone was happy.

Now Scott, here's the thing: If their goal had been quick and cheap
delivery, they could have taken 3 more days to clean up my software,
wrapped it in a nice GUI, and they'd have been done. Perhaps you could
do the same thing.


> 
> So we go to our management and say "We don't think it's going to be as
> easy this time."  And management says, "Yeah, we know, but we threw
> 20% more development time into our estimate."  And we reply "20%
> would be reasonable if we could use the same approach that we've been
> using, but we can't.  We have to create a purpose-built solution."
> Then they want to argue with us about how good we are.

I think if you articulate it to them exactly like you've articulated it
in the preceding paragraph, you'd stand an excellent chance of getting
them to adopt more reasonable expectations. Also, make the point that
charging more is good for them: They get more profit. Coach them on how
to articulate the difference between this and the easy stuff your
company has done for the custy before, so the custy will sign off on the
bigger price. Your sales people can let the custy know that, yes, you
can get cheaper vendors to do this, but there's no reason to believe the
cheaper guys will deliver a solution you can actually use. We have a
track record of success in your company.

[clip]

> 
> Thanks for making me think about this further Steve.  I hadn't really
> thought of this as a "threshold" type problem before, but it's
> starting to look that way.  We've been able to get solutions built
> quickly due to the fact that we've been able to leverage our existing
> repository of past work.  We are reaching beyond that now, and not
> finding as much relevant publicly available code and information.  We
> haven't been doing a good enough job of making that distinction.

And...

If you can split the problem domain into a huge chunk that's business
as usual, and a small chunk that's gone beyond the threshold, you can
set one developer on the small chunk, have him communicate the "API" of
his program to the rest of the team, have the rest of the team give him
feedback about the API they need, and have big chunk and small chunk
ready at the same time, and if the communication has been right,
they'll work together and you're done.

I really envy you Scott. Oh man, I hated this shit as a professional
coder/analyst, but looking back, some of my fondest memories were of
doing the impossible, with management making my job harder, and doing it
quicker than expected. After you leave the programming profession, as
most of us must, due to age discrimination, you'll probably fondly
remember this project, and the allnighters you devoted to it.

SteveT

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