Modernization

[Dick Burke]

On Fri, 28 Apr 2006 11:50:11 -0400, Fairlight wrote:

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

It's getting harder and harder to read through your long answers and figure out "What's your point ?".

Dick Burke