On Thu, 8 May 2008 14:36:12 +1200, "Pete Dashwood"
<dashwood@[EMAIL PROTECTED]
> wrote:
>
>
>--
>"I used to write COBOL...now I can do anything."
>"Clark F Morris" <cfmpublic@[EMAIL PROTECTED]
> wrote in message
>news:ca4424196gg94gb1bft0mlbg432u5r26im@[EMAIL PROTECTED]
>> On Thu, 8 May 2008 02:59:42 +1200, "Pete Dashwood"
>> <dashwood@[EMAIL PROTECTED]
> wrote:
>>
>>>
>>>
>>>"chuck" <charles.leviton@[EMAIL PROTECTED]
> wrote in message
>>>news:b771707f-7b70-4d26-a01d-ccd21d0e6ef5@[EMAIL PROTECTED]
>>>> On May 5, 11:22 pm, Robert <n...@[EMAIL PROTECTED]
> wrote:
>>>>> On Mon, 5 May 2008 10:30:13 -0700 (PDT), Pakku
<pa...@[EMAIL PROTECTED]
>
>>>>> wrote:
>>><snip>
>>>>
>>>> But attempts at conversions get bogged down with changed business
>>>> specifications. As soon as system users hear there is going to be a
>>>> conversion they want all these new requirements to be incor****ated-
>>>> kind of like "While you are in there making this change, why not
make
>>>> this additional teensy change as well" that most programmers know
>>>> about!
>>>
>>>Yeah, users are the pits... Always wanting something, never satisified.
>>>
>>>They despise techies and don't even try to understand the basics.
>>>
>>>They just don't seem to get it. Computer systems are there for us to
>>>improve
>>>our skills. So we can go down the road and get even more money for not
>>>providing service.
>>>
>>>And what's with this "It's great, but can we just have this one small
>>>change...?" We sweat blood to give them what they told us they wanted
>>>when
>>>we did the requirements gathering, and then when we deliver it, they
want
>>>it
>>>changed.
>>>
>>>Like we should be responsive to them changing their minds. As if we had
>>>nothing better to do than be at their beck and call all day.
>>>
>>>It's time they figured out who the dog is and who the tail is around
here.
>>>We can bring them to a standstill any time we want.
>>>
>>>They don't understand the awesome responsibility we have to carry every
>>>day.
>>>And all we ask is for them to be clear in what they want and be glad
when
>>>we
>>>deliver it, even if it is no longer relevant. Not our fault if the
>>>business
>>>changes and the markets change and the technology changes and what they
>>>needed before isn't what they need now... THEY signed off the
functional
>>>spec. ('Course, we wouldn't have started work if they hadn't...)
>>>
>>>Nah, don't talk to me about users.
>>>
>>>Bloody wimpy little cry-babies who're never satisfied...
>>
>> My response to users was ask for things regardless of how hard you may
>> think they are but be prepared for unexpected responses because the
>> seemingly impossible may be very easy to do while the obviously simple
>> may be very expensive to accomplish.
>
>A very good approach. As long as you let THEM assign priorities...
Assigning priorities was up to levels of management removed from me.
This at least gave them a feel for possible costs.
>
>> They seemed to accept this.
>> Unfortunately, putting in a number of changes can mess things up.
>
>Certainly can, if it is done in an uncontrolled and unprioritised way.
>
>If changes are iterated and prioritised within timeboxes, it DOESN'T mess
>things up. In fact, it ensures that useful, desired functionality is
>delivered in a timely manner.
>
>The problem is not with users wanting change.
>
>That is to be expected.
>
>The problem is in the IT department NOT wanting it, and not knowing how
to
>deal with it.
>
>It stems from the old school IT approach of everything being planned to
the
>last detail and signed off before any work commences.
A lot of this was due to the resources available at the time. Also we
were designing the data stores and frankly we inadequately specified
some of them. Tools available these days when we have far more
resource so we can afford the costs of flexibility allow for less
advance planning. I can remember being insistent that most jobs
should take only 100K of main memory. Now a couple of gigabytes is
good for the bigger ones and multiple megabytes is reasonable. Care
has to be taken with some decisions because undoing them later still
is a killer.
>
>EVOLVED systems are far better than PLANNED systems. (In the time you
spent
>planning, you could have done another iteration of the core functionality
>and got it working, as it is required NOW.)
>
>But that is a heresy that few here will understand...
>
>In order to evolve systems, it requires a change of mindset and
methodology;
>most of the people in this group work on sites where that isn't going to
>happen any time soon.
>
>It takes confident IT people (developers, analysts, and managers) to
build
>systems without planning :-)
>
>We know very well that whatever we build is going to be changed, so why
plan
>it down to the last detail?
>
>Identify it. Build it. Take another look at it. Repeat until agreed time
>runs out.
>
>Evolution.
>
>There are three key factors in this approach:
>
>Iteration.
>Interaction.
>Timeboxing.
>
>> Examples are Vista and various other ill fated operating system
>> releases from various vendors.
>
>Actually, there are millions of people who are very satisfied with Vista
>(I'm not one of them... :-)) And there is no evidence to suggest that the
>"problems" with Vista were caused by overwhelming change requests.
You make enough changes and the unanticipated side effects can deliver
a severe blow. What has surprised me is the favoring of XP over Vista
by both PC World and PC Magazine. Walter Mossberg in the Wall Street
Journal also has been skeptical and critical about Vista. Apple's OS
also has been rated more favorably than Vista by a number of reviewers
who weren't known for being Apple aficionados.
Note that this disease is not confined to any one vendor. There have
been releases of Apple's OS that got less favorable reviews. As
someone who was responsible for the installation and maintenance of
IBM's mainframe operating system (MVS then) and who still follows
discussion of it as z/OS, I am aware of the tendency of bugs to creep
in. I sometimes wondered how my installation was able to keep running
given some of the bug re****ts I saw.
>
>Pete.
|
