POV-Ray : Newsgroups : povray.off-topic : I found this interesting Server Time
1 Oct 2024 22:26:38 EDT (-0400)
  I found this interesting (Message 105 to 114 of 154)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: scott
Subject: Re: I found this interesting
Date: 9 Apr 2008 07:35:27
Message: <47fca9ff$1@news.povray.org>
> Yeah, I'm sure that happens. In fact, it's the kind of thing you see on 
> the Daily WTF all the time. But, as everybody always points out, the 
> *real* WTF is that MANAGEMENT FAILED TO ALLOCATE SUFFICIENT RESOURCES.

Management would say that the resources would be better used elsewhere (and 
they are sometimes correct).

> Hey, maybe that's why we have this long, complex design process specified 
> in the first place?" But, obviously, this did not happen.]

I guess that's another risk, if you have a hugely complex and long design 
process with nobody checking it is being followed, then of course people are 
going to avoid it.



HAHAHAHHA - best laugh so far today!


Post a reply to this message

From: Invisible
Subject: Re: I found this interesting
Date: 9 Apr 2008 07:46:39
Message: <47fcac9f$1@news.povray.org>
>> Yeah, I'm sure that happens. In fact, it's the kind of thing you see 
>> on the Daily WTF all the time. But, as everybody always points out, 
>> the *real* WTF is that MANAGEMENT FAILED TO ALLOCATE SUFFICIENT 
>> RESOURCES.
> 
> Management would say that the resources would be better used elsewhere 
> (and they are sometimes correct).

Well, what should happen is that a project is either properly resourced, 
or put off until such time as it can be properly resourced. The problem, 
as you rightly point out, is when people demand impossible things and 
get them rather than being told to take a walk.

[Indeed, I've seen a definite recurring theme of "promise the customer 
absolutely anything to make them hand over their money, and worry about 
whether it defies the known laws of physics later". Ultimately it is 
again management's responsibility to make sure their salesmen don't do 
this...]

>> Hey, maybe that's why we have this long, complex design process 
>> specified in the first place?" But, obviously, this did not happen.]
> 
> I guess that's another risk, if you have a hugely complex and long 
> design process with nobody checking it is being followed, then of course 
> people are going to avoid it.

This is the staggering thing.

This made a basic beginner's error. If anybody at my uni *ever* dared to 
pull a stunt like this, they'd get their work *severely* down-marked. 
[Usually anybody stupid enough to try this also sucks at programming, so 
basically they get their work failed and have to start again.]

It blows my mind that we actually *got away* with this crap. There are 
external auditors who should have spotted this one and had somebody 
fired - and probably half the company shut down. Not doing what your 
procedure documents say you're doing to do is a BIG DEAL to these 
auditor types - even if in principle it doesn't "matter" as such. The 
fact that you didn't do what the documents say *is* the problem.


> 
> HAHAHAHHA - best laugh so far today!

It is pretty hysterical, eh?

Now try ACTUALLY USING THIS SOFTWARE FOR A LIVING! >_<

For you, it's just some words on a page. For me, it's a daily reality. 
This, surely, is enough to make a grown man cry... :'{

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*


Post a reply to this message

From: scott
Subject: Re: I found this interesting
Date: 9 Apr 2008 08:53:38
Message: <47fcbc52$1@news.povray.org>
>> Management would say that the resources would be better used elsewhere 
>> (and they are sometimes correct).
>
> Well, what should happen is that a project is either properly resourced, 
> or put off until such time as it can be properly resourced.

What if postponing the project means a big loss in income/profit?

> [Indeed, I've seen a definite recurring theme of "promise the customer 
> absolutely anything to make them hand over their money, and worry about 
> whether it defies the known laws of physics later". Ultimately it is again 
> management's responsibility to make sure their salesmen don't do this...]

And then you won't win any projects at all, because your competitors 
salesman are doing this (even if just a little bit).

> For you, it's just some words on a page. For me, it's a daily reality.

Don't worry, I have more than my fair share of similar situations here.


Post a reply to this message

From: Invisible
Subject: Re: I found this interesting
Date: 9 Apr 2008 09:14:10
Message: <47fcc122$1@news.povray.org>
>>> Management would say that the resources would be better used 
>>> elsewhere (and they are sometimes correct).
>>
>> Well, what should happen is that a project is either properly 
>> resourced, or put off until such time as it can be properly resourced.
> 
> What if postponing the project means a big loss in income/profit?

Then it should be properly resourced. ;-)

Cost/benefit analysis. If this project is really that important, you 
should be assigning resouces to it. If you can't do that, you can't have 
the results. You don't get something for nothing...

>> [Indeed, I've seen a definite recurring theme of "promise the customer 
>> absolutely anything to make them hand over their money, and worry 
>> about whether it defies the known laws of physics later". Ultimately 
>> it is again management's responsibility to make sure their salesmen 
>> don't do this...]
> 
> And then you won't win any projects at all, because your competitors 
> salesman are doing this (even if just a little bit).

Well, then the other companies get a reputation for failing to deliver a 
quality product, and you become known as the people who take slightly 
longer but deliver something worth the money. :-D

Obvious counter-example: Micro$oft. But then, they have a monopoly in 
almost all areas they trade in. Few others are so lucky.

>> For you, it's just some words on a page. For me, it's a daily reality.
> 
> Don't worry, I have more than my fair share of similar situations here.

Heh. Seriously, adding up currency without performing a conversion 
first? This stuff isn't exactly complicated. It's about the most basic 
stuff there is!

Tell me, have you ever seen projects where they think "yeah, we'll 
design and build the software, get it working, and then add security to 
it later"? Every time I see this, unless it's a really trivial 
application, I can practically *guarantee* that it won't work. Security 
needs to be designed in from day #1. It's usually extremely hard to add 
it later. I'd almost put *money* on that trick failing...

Obligatory QC reference:

http://www.questionablecontent.net/view.php?comic=926

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*


Post a reply to this message

From: scott
Subject: Re: I found this interesting
Date: 9 Apr 2008 10:09:11
Message: <47fcce07$1@news.povray.org>
> Cost/benefit analysis. If this project is really that important, you 
> should be assigning resouces to it. If you can't do that, you can't have 
> the results. You don't get something for nothing...

Yeh you can, you just get the results but end up with buggy code that cannot 
be reused very easily in future :-)  From a managers point of view there is 
no point in getting extra resource for no visible benefit.

> Well, then the other companies get a reputation for failing to deliver a 
> quality product, and you become known as the people who take slightly 
> longer but deliver something worth the money. :-D

That's fine for frequent short projects, but for infrequent or longer 
projects (eg 5 years or so) unfortunately that never really happens.  You 
get new people, new supplier selection methods etc.  Nokia worked like this, 
in their supplier selection tables they had a column for "supplier 
confidence" where exactly what you said was take account of.  But they make 
loads of phones the whole time, someone making cars or office blocks does so 
far less frequently.

> Heh. Seriously, adding up currency without performing a conversion first? 
> This stuff isn't exactly complicated. It's about the most basic stuff 
> there is!

Try things like offering the customer some extra feature for $X, which they 
accept, then a year later they change their mind and you say "oh, that costs 
$X/2, we can take that much off the price".  Just because the person 
involved forgot what they said 1 year ago.  Customer is not happy and then 
requests detailed cost analysis of your whole product...

> Tell me, have you ever seen projects where they think "yeah, we'll design 
> and build the software, get it working, and then add security to it 
> later"?

Try, yeh we'll inform some dimensions off-the-cuff to the customer, then 
think about design later.  Or yeh we'll make the design and then think about 
EMC and thermal performance later.

> Every time I see this, unless it's a really trivial application, I can 
> practically *guarantee* that it won't work.

Ditto.


Post a reply to this message

From: Invisible
Subject: Re: I found this interesting
Date: 9 Apr 2008 10:13:13
Message: <47fccef9$1@news.povray.org>
>> Tell me, have you ever seen projects where they think "yeah, we'll 
>> design and build the software, get it working, and then add security 
>> to it later"?
> 
> Try, yeh we'll inform some dimensions off-the-cuff to the customer, then 
> think about design later.  Or yeh we'll make the design and then think 
> about EMC and thermal performance later.
> 
>> Every time I see this, unless it's a really trivial application, I can 
>> practically *guarantee* that it won't work.
> 
> Ditto.

What, you mean you have to actually, like, design something to not 
overheat in the first place? You can't just add some extra fans afterwards?






OK, I'm sorry. That's probably not even funny from where you're sitting...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*


Post a reply to this message

From: scott
Subject: Re: I found this interesting
Date: 9 Apr 2008 10:18:05
Message: <47fcd01d@news.povray.org>
> What, you mean you have to actually, like, design something to not 
> overheat in the first place? You can't just add some extra fans 
> afterwards?

"It's always worked before"


Post a reply to this message

From: Nicolas Alvarez
Subject: Re: I found this interesting
Date: 9 Apr 2008 10:18:19
Message: <47fcd02b$1@news.povray.org>
scott escribió:
> I have to learn, that you always need to

GAH

That's what I was talking about. It looks so ugly in English.


Post a reply to this message

From: scott
Subject: Re: I found this interesting
Date: 9 Apr 2008 10:25:31
Message: <47fcd1db$1@news.povray.org>
>> I have to learn, that you always need to
> 
> GAH
> 
> That's what I was talking about. 

I know :-)

> It looks so ugly in English.

Agreed.


Post a reply to this message

From: Darren New
Subject: Re: I found this interesting
Date: 9 Apr 2008 12:07:57
Message: <47fce9dd$1@news.povray.org>
Invisible wrote:
> Well, people claim that Lisp is an [impure] functional language too, and 
> AFAIK Erlang is about as pure as Lisp is.

It's functional in the sense that you only assign once to a variable. 
It's not functional in the sense that calling "read" on the same file 
twice (in any language) can give you different results. Erlang just has 
lots more of that latter kind of non-functionalism.

But yeah, you have to pass the seed to the random number generator, and 
it gives you back your random number and a new seed to remember for 
later. :-)

How does Haskell handle things like the function for "the time right now"?

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.