[TriLUG] Looking for Software Process Clue Stick

[Tim Jowers]

hi Scott,

sounds much like Agile. Sorry I haven't had time to analyze each response.
Maybe time will come from somewhere.

Most contract sw companies (especially including the big 5 or so) do what
you say at the beginning and then throw in "junior guy who thinks he's an
architect" to run the rest of the project. The code base is crap when
delivered but through lots of Agile iterations (or other iterations) it
does what it is designed to do. This becomes a business of billable hours
and company's hire the cheapest (so lower skilled) they can. So, you might
consider their very profitable approach. Throw prototype over the wall to
junior team and let them learn on the company dime. Seen it dozens of times
on very well-funded projects for huge companies. Crap code bases can have
very profitable maintenance contracts too. And that is yet another avenue
to bring in unskilled people and pretend they are programmers. Seen it on
almost every large contract in the past decade.

Ethically, I think you can explain just that to them. 80% of SW cost is in
maintenance. Most companies want sweet lies on cost. Hopefully you, like I
did, will find companies who are willing to do it right and have a vision
longer than the next quarter, or even the next manager's meeting.

Tim



On Mon, Jul 14, 2014 at 10:39 AM, Steve Litt <slitt at troubleshooters.com>
wrote:

> 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
>
> --
> This message was sent to: timjowers <timjowers at gmail.com>
> To unsubscribe, send a blank message to trilug-leave at trilug.org from that
> address.
> TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
> Unsubscribe or edit options on the web  :
> http://www.trilug.org/mailman/options/trilug/timjowers%40gmail.com
> Welcome to TriLUG: http://trilug.org/welcome
>