Modernization

[GCC Consulting]

> -----Original Message-----
> From: 
> filepro-list-bounces+gccconsulting=comcast.net at lists.celestial
> .com 
> [mailto:filepro-list-bounces+gccconsulting=comcast.net at lists.c
> elestial.com] On Behalf Of Fairlight
> Sent: Friday, April 28, 2006 11:50 AM
> To: filepro-list at lists.celestial.com
> Subject: Re: Modernization
> 
> >From inside the gravity well of a singularity, GCC 
> Consulting shouted:
> > As a developer, I do custom system mostly for niche markets.  My 
> >clients
> 
> Keyword:  "I"
> 
> > The presidents of the company asks the same question of each, if I 
> > need a modification how long will it take?  They usually 
> respond that 
> > they will send of an analysis to review the requirements; then they 
> > will review it with programming and then get back with a 
> price.  Then 
> > it will be about xx weeks before they can start and xx weeks to 
> > finish.  My client the asks, what if I need it right away?  
> Sorry, that's our procedure.
> > 
> > How long does it take to get a new report?  The usual 
> answer was 8 weeks.
> > Again they ask, what if I need it now?  8 weeks is the answer.
> > 
> > My client then usually says that my current developer will 
> come in and 
> > get a report done in less then 2 hours.  As for new 
> programming that 
> > we need, it takes him from 1 day to a few weeks from the 
> time we ask him not months.
> 
> Which is all fine and well.  However, besides using another 
> language which adds complexity, these other companies, by the 
> very verbiage you've used, are not only beaurocratic 
> nightmares, they're using -teams- of developers.
> There's a huge difference in the paradigm.
> 
> On your end, you wrote -all- the code.  You know where 
> something is handled down to the table name, possibly even 
> the rough line number if you're anything like I am.  You're 
> very in touch with the code because you designed and wrote 
> all of it, and you've been doing it for years and maintaining it.
> 
> Company 'X' out there has a stock package.  They spent 'y' 
> amount of time developing, 'z' time testing, and put it to 
> market.  They have salespeople probably selling it that know 
> next to nothing about the innards of the software.  The dev 
> team works mostly on bug fixes and the next release.
> They do the occasional customization which by and large isn't 
> needed because they tend to sell their software "as-is" at 
> bigger houses, canned, and all but shrink-wrapped (and maybe 
> even that).  The devs that actually wrote the code probably 
> number 3-10, and that's on a smaller package.  Each probably 
> knows one or two subsystems really well and only a smattering 
> of how the others work.  They need to get together, 
> coordinate, and come up with a consensus of what it will take 
> to get it done.  Is 8 weeks extreme?
> Yes.  Is asking for a formal written spec and at least a few 
> days' analysis time out of order?  Not at all.  Certainly not 
> in a multi-person development model.  Even in a single-person 
> model, I need time to look over my code and consider what 
> will be required--or look over a spec, research any relevant 
> technology I don't already know about, and get my house in order.
> 
> Doing things without a written spec and off the cuff is THE 
> fastest way to screw myself into the ground and get burned on 
> an estimate (and historically, estimates aren't my strong 
> point anyway).  If someone
> -really- wants to rush an estimate, let's just say it swings 
> high if I don't have a chance to research it, knowing full 
> well that I will inevitably have something creep up that 
> requires more time than I'd otherwise expect.  Depending on 
> the area involved (UI, networking, other subsystems), it can 
> be anywhere from a 10% to a 50% bloat factor if I'm rushed 
> into giving an estimate.  Networking and UI are both the 
> worst, really.  Networking has added complexity, UI just 
> needs tweaking seemingly forever--first by me to get what I 
> envisioned at design and during discussions, and inevitably 
> almost half that again to change it to whatever the latest 
> bright idea they came up with while I was coding it the first 
> time around.  If someone gives me ample time to make a proper 
> analysis, they can save themselves on a quote.  If they want 
> to rush, they can pay premium for doing so.  It's unrealistic 
> to ask someone to modify certain things next to instantly, 
> especially in systems of any complexity.
> And of -course- they want it live ASAP, without the proper 
> testing period they should be giving it.  Thankfully I'm no 
> stranger to multi-12hr-day internal beta's.
> 
> I've seen places that won't give you enough details to even 
> FORM a solid spec.  I turned down one place that couldn't 
> even elucidate their business plan in finer detail than 
> "change from Microsoft to Linux".  Those are time sinks one 
> does -not- want to deal with.  It may look like you could 
> retire off them, but in the end your tranquilizer 
> prescription bill goes through the roof, you blow through 
> your own estimates based on their really poor elucidation of 
> what they -think- they want, which isn't really what they 
> actually want (or -need-!), and you end up taking a 
> loss--sometimes a sizeable one.
> 
> Yes, fP makes writing a report in short order, or even 
> changing some good deal of code very easy.  The problem is 
> that (at least as it appears to be the case on this list) 
> most fP shoppes -appear- to be 1-person endeavors, usually 
> 2-person tops.  There are a few exceptions I can think of, 
> but a lot of the developers run solo operations, and smaller 
> operations would
> -seem- to be the norm.  That helps them keep all that red 
> tape out of the picture.
> 
> Red tape aside, you -can- get burned by rushing in.  I've 
> done it.  I don't do it any more.  And if someone insists on 
> forcing me to, they possibly pay more than they had to for 
> having done so.
> 
> Anything worth doing is doing right.  I've been taught this 
> since I was a kid.  Doing things right, including testing, 
> takes time.  If "Company A" didn't have a certain mechanism 
> or system in place for 12 months or sometimes 12 years, 
> there's a DAMNED good bet that they don't -NEED- (with seven 
> capital N's) it in place overnight, much less the "last 
> month" they tell you when they first drop it on your plate 
> and tell you it came from on high that they needed this 
> months ago, it's a rush job.  They simply
> -WANT- it that fast.  There are exceptions, especially if it 
> will cost them business, and it really did creep up on them 
> quickly and externally.  I can understand and try to 
> accomodate that.  But when it's entirely internal and someone 
> just hauls off and makes a decision, "Hey, we should be doing 
> this, let's do it," and then it's a rush to get an estimate 
> and the completed project by means of temporal displacement 
> equipment--uh uh.  Not buying it, and I generally tend to 
> take such "past deadlines" a lot less seriously, especially 
> if it looks like nothing's been planned for at all and they 
> just dreamed this up the night before.  They've lived without 
> it for that long, taking the time to do it RIGHT and right 
> the FIRST TIME is not out of order.  Doing things on a whim 
> rarely gets anyone anywhere good very quickly.
> 
> Into danger rusheth the unwise, at their own peril.
> 
> There's still a huge difference between the beaurocratic and 
> monolithic model of development in "heavier" environments, as 
> opposed to the small and lightweight approach that a 4GL will 
> afford you as a solo or small-shoppe developer.  And that may 
> indeed play to filePro's strengths, and the strengths of 
> those like you who adopted it and learned it inside and out.
> I don't belittle your skill, effort, or ethic one bit.  
> However, there's no reason to assume that because someone 
> wants the time to do it right (as fits -their- business model 
> and ethic for getting it done right the first time), that 
> they're out to screw the customer.  That's just not a blanket 
> assertion anyone can justifiably make, IMHO.  You didn't 
> explicitly, but the implication seems to be there.  I'd take 
> exception with that notion.
> 
Mark,

A I stated at the start, I deal with niche markets.  That said, There are
times when a company needs a modification/report ASAP.  Being able to
deliver the needed programming on a timely basis can mean the difference
between them keep an customer or loosing one.  There are time where it may
be necessary to cut through all of this for the client's sake.

One company I worked for many years ago was having a problem with a module
they had contracted to do for a client.  This client was a friend of mine
and were getting frustrated that after a year of trying they couldn't get
the module to work properly.  The client was about to sue and this was a
$40,000 module that was paid for.

I suggested to the president of the company that he allow the client to talk
to the programmer.  I was told that this is not the proper procedure, he
should talk to the analyst, who would talk to the programmer.  I told him
that it would be cheaper to have the client and programmer talk then to
fight a law suit that he would loose.

He gave in,  The client and programmer met, talked face to face.  The
programmer ask a few questions and the said "Oh, that's what you want!!".
She left the room and 1/2 hour later had the client test the module which
work correctly.

You are correct, I know most of the code I have written for 4 different
industries that I deal with.

However, when I mention speed of development, I am not indicating sloppy
poorly coded programs.  What I am saying is that filePro allows me to
develop and test and then deliver programming on a very timely basis.  As I
mentioned, some modification are quite easy to make and can be done in less
then an hour and be fully tested.

One has to choose the market(s) they are working in.  I have been dealing
with small businesses for most of my career.  Since I come from a business
background, I am able to help those prospective client's who are having
trouble explaining what they need and to work through their requirements.  I
can then set up a contract which outlines clearly what they will be getting
and the delivery time.

One of the advantages that a small company, such as mine, has is that we can
turn on a dime for clients.

On the other hand, one of the disadvantages we have is that we are a small
company.  I have turned down business from companies where I felt I could
not adequately support them.  However, what I have done is find them
companies who could support them and then helped them through the demo and
selection process.  In these cases I am selling consulting services. 

I have managed a medium size IBM VAR having a staff of 4 in-house
programmers and 3 outside programmers plus a support staff of 3.   When I
started there, we were using RGGII on the system36.  When I left, they were
running on the AS400 in RPGIII.  I understand very well the problems of
having a "standard" application to geared to an industry.  However, I have
always been with Software companies who tailored their packages to meet the
requirements of their clients.  Many times the modifications done for a new
client became part of the next release level of the basic package.  These
mods were then offered to other clients, either for the cost on installation
or for a relatively nominal fee as compared to the development cost.  These
could be new innovative reports or complete new modules.