Modernization

[Fairlight]

>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->