Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re: Musings: Why do well-intentioned projects go so wrong, so often?

by graq (Curate)
on Dec 05, 2007 at 08:13 UTC ( #655049=note: print w/replies, xml ) Need Help??


in reply to Musings: Why do well-intentioned projects go so wrong, so often?

Theory begins by denying reality - to talk about reality, to go around reality, to catch anything that attracts our sense - intellect and abstract it away from reality itself.

Begginning with saying that the outside world is not a fact, that existence can be doubted and that every proposition in which reality of the outside world is affirmed is not an evident proposition but one that needs to be divided, dissected, and analysed.
It is to stand consciously aside and try to square a circle.

Projects fail on expectations and bad criteria. Everyone gets them mixed up and start talking about who's methodoligies are better.

Perhaps, one day, after one has delivered a project where, for example:

a) Scope and functionality is to be reduced to fit the deadline
b) Performance is not an issue
c) Content accuracy and reliability is expected to be wrong at least 6 months after deadline

That is when one should start discussing achievability, business projections and the stock market.

Like an ancient buddhist monk, you should transcend all your teachings and simply deliver the solution. Everything before it and after if is the journey of your life.

(Apologies for my badly recollected quotation)

-=( Graq )=-

  • Comment on Re: Musings: Why do well-intentioned projects go so wrong, so often?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://655049]
help
Chatterbox?
[Corion]: ... gets called once. The data structure for that is just a hash of arrays, mapping the event type to a queue of registered one-shots, and the first one-shot from the queue gets removed and called.
[Corion]: But now I want to register a one-shot for two events, of which only one will arrive, so my data structure doesn't work anymore...
[Lady_Aleena]: Corion, ouchy.
[Corion]: (maybe I should write this up as a SoPW) - currently, the "most efficient" data structure I come up with is a single array which I scan for the first fitting one-shot. Not efficient but I don't expect more than five outstanding one-shots anyway
[choroba]: can't you create a meta-key corresponding to the disjunction of the events?
[robby_dobby]: Corion: Heh. This whole thing smells of Strategy Pattern or MVC pattern.
[Corion]: And performance linear to the number of registered one-shots doesn't feel that bad. Maybe I should collect statistics on how many callbacks are outstanding ;)
[Corion]: choroba: Yes, but the longer I thought about efficient hashes mapping the event type back to their callbacks, and how to keep them in sync, the more I thought that all that optimization might just not be worth it, even if it's horribly inelegant
[Lady_Aleena]: My biggest problem with hashes at the moment is one with 2,501 keys.
[choroba]: how many event types are there?

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (9)
As of 2017-05-29 07:54 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?