Re: Detail first? Or Big Picture?
- From: MM <kylix_is@xxxxxxxxxxx>
- Date: Wed, 19 Mar 2008 08:31:52 +0000
On Wed, 19 Mar 2008 09:34:21 +1100, "Michael C" <mike@xxxxxxxxxx>
wrote:
"MM" <kylix_is@xxxxxxxxxxx> wrote in message
news:ca1vt3d8ch7s38pohl3njp423rt09f0qnp@xxxxxxxxxx
Nope. The suck it and see approach is ideally suited to, say, an
Access database.
I can see where you're coming from. For small inhouse apps with a small
number of users and easy access to the PCs in question then you can get away
with a lack of planning.
"get away"? I don't see it as getting away with anything. It is a
deliberate action on my part (or was before retirement). "getting
away" implies something like driving recklessly and "getting away"
with a skid that almost killed a bystander.
Now, you might turn up your nose at an Access
database ("toy software"), but many millions of people rely on one.
I hate access with a passion
Me, too! I did say "Access database", though, with the emphasis on the
database part, not the horrendous user interface. Using an mdb within
a VB app is really great. You don't need even to have Access, given
the designer thingy in VB6 (I modified mine to support Access 2000).
but that is a different topic. Even though I
know access I never put it on my resume because someone might want me to do
it.
One can add fields, create indexes, do all kinds of things in a trice.
But of course my scaffolding *does* cover the basics, otherwise it
would hardly be scaffolding, it'd just be a heap of pipes and boards
on the building site.
Still, all the same problems apply. If you make a mistake in the database
and then base 5 years work on that mistake then it can take a very large
amount of time to fix that mistake. Especially when other people base their
software on yours.
Why would one make a mistake and then live with it for five years?
Hmmmm.... nope. Can't answer that one meself!
Then the design wasn't flexible enough.
Of course and that would be a result of a lack of planning.
You forgot that scaffolding again! I'm not just running into the
computer room straight from plowing Top Acre Field and developing a
city financial system.
As an example we
have a system where a person is assigned a job on a regular basis. If that
person cannot do that job on a certain day then a replacement person is
assigned to the job. This is typically done in half hour to 40 min
intervals. Due to a lack of planning we never conceived the possibility that
they would want to break that time down further and have someone cover the
first half of the 40 mins and someone else the last half.
Ah, you see, I would never have thought in terms of 40 minutes or half
an hour. Giving a long's capacity I would have thought in terms of
minutes. Then a change from 40 to 33 to 67 is a doddle. Probably,
just the .ini file affected (I don't use the registry).
The problem with
this is a smallish percentage of our customers would need to do this so we
would have needed to talk to at least 20 customers to realise this was a
requirement. ie, we would have needed to do a lot of talking to customers
and planning, As I said before, if you're developing a small inhouse app
then this is unlikely to be a problem or is going to be easy to fix. But
when you develop a very large app for a large user base then this is *much*
more difficult and planning is critical.
As you've just seen, a simple thing like defining a block of time can
have a very different basis. Perhaps I'm just lucky in choosing the
right bits of scaffolding through many years of experience.
and/or bad. Mine has been that my approach has worked.
In newsgroup fantasy land people can say whatever they like.
Let me just test that supposition:
bodada dididadadum dum dum di dobodo di dah
Yep, you're right!
You would have
come up against issues that resulted from a lack of planning, you're just
not telling me about them.
If planning is such a good idea, why do so many of the British
government's IT projects fail miserably, cost billions over budget and
are often scrapped as not fit for purpose? (Many/most are developed by
American companies, by the way.)
MM
.
- References:
- Detail first? Or Big Picture?
- From: MM
- Re: Detail first? Or Big Picture?
- From: Michael C
- Re: Detail first? Or Big Picture?
- From: MM
- Re: Detail first? Or Big Picture?
- From: Michael C
- Re: Detail first? Or Big Picture?
- From: MM
- Re: Detail first? Or Big Picture?
- From: Michael C
- Detail first? Or Big Picture?
- Prev by Date: Problem in Web Service calling in vb6
- Next by Date: Re: Detail first? Or Big Picture?
- Previous by thread: Re: Detail first? Or Big Picture?
- Next by thread: Re: Detail first? Or Big Picture?
- Index(es):
Relevant Pages
|