Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re: Re: The crime under reusability

by hardburn (Abbot)
on Dec 01, 2003 at 16:26 UTC ( [id://311308]=note: print w/replies, xml ) Need Help??


in reply to Re: The crime under reusability
in thread The crime under reusability

The points you make might show that the performance isn't due to this design decision, but I don't think it solves the points about maintainability. In particular, the OP noted that the programmers didn't have an understanding of the user requirements. No ammount of good design will save you if you don't really understand the problem.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

: () { :|:& };:

Note: All code is untested, unless otherwise stated

Replies are listed 'Best First'.
Re: Re: Re: The crime under reusability
by tilly (Archbishop) on Dec 01, 2003 at 19:05 UTC
    I wasn't saying that this design decision didn't cause the performance problem. I was instead saying that without a detailed post-mortem, you shouldn't conclude that it was that. Personally I'm never comfortable with conclusions unless I have been balancing at least three theories. One theory is usually prejudice. 2 gets me into binary thinking where I have a hard time really thinking through the merits of either. 3 seems to be my threshold to really start breaking things down and identifying what is going on.

    Also when a project goes wrong, it usually goes way wrong. My suspicion is that the database decision is more of a symptom than a cause. The poor understanding of user requirements is another symptom. Firing the project manager is suspicious. I'm sure that if I knew more about the project failure, I would come up with lots more symptoms.

    Symptoms of what, though, is a different story. Were key people not properly prepared for their roles? Does the company have a command and control philosophy which results in more CYA than useful early feedback about potential problems? Was the wrong kind of project structure for the problem in use? Did you have a deathmarch? (These are not mutually exclusive possibilities...)

    There are plenty of classic books from Peopleware which have lots of useful stuff to say on why projects fail and what you can do about it. But without knowing some details, there isn't much that you can concretely say about what should have been done better on any given project.

    Which is why I limited myself to pointing out other possible technical performance problems other than the obvious which plausibly played a role.

      What's a deathmarch? Somehow the (cliché) image of lemmings storming towards the cliff's edge, comes into my mind's eye.
        If you have to ask, perhaps you haven't been through one (yet). Death March does a pretty good job of describing the phenomena.

        Essentially a death march is what happens when a team facing tight (and sadly usually artificial) deadlines attempts to solve the lack of calendar days by putting in more time per day. Things go downhill from there...

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://311308]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others taking refuge in the Monastery: (6)
As of 2024-03-28 23:32 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found