 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
And lo on Mon, 07 Apr 2008 05:44:56 +0100, Gail Shaw sa dot com>
<"<initialsurname"@sentech> did spake, saying:
>
> "Chambers" <ben### [at] pacificwebguy com> wrote in message
> news:47f931ae$1@news.povray.org...
>>
>> The disdain that "real" programmers feel for newbies who crank out quick
>> code using "toy" languages is, I think, more akin to the disdain "real"
>> mathematicians feel towards business math majors. Sure, they can "press
>> the buttons", but they don't really know what they're doing. It's not
>> about jealousy - after all, many programmers who started out writing
>> assembly code are now using higher level languages and cranking out code
>> just as quickly. It's about perceived understanding of what your code
>> actually does.
>
> Agreed.
>
> What bugs me no end is that some people don't want to learn. They're not
> interested in understanding what the code does. They just want to get
> something 'working' (for certain definitions of working) as fast as
> possible.
Time is money - hey it took me a third the time to produce this working
code then you did yours. Oh sure your code scales up whereas mine conks
out with large input, and sure your code is robust whereas mine fails if
someone sneezes at it in the wrong direction; but mine works *now* with
what we're using *now* and it took less time to write then yours - neh neh
neh neh. ;-)
--
Phil Cook
--
I once tried to be apathetic, but I just couldn't be bothered
http://flipc.blogspot.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> What bugs me no end is that some people don't want to learn. They're not
>> interested in understanding what the code does. They just want to get
>> something 'working' (for certain definitions of working) as fast as
>> possible.
>
> Time is money - hey it took me a third the time to produce this working
> code then you did yours. Oh sure your code scales up whereas mine conks
> out with large input, and sure your code is robust whereas mine fails if
> someone sneezes at it in the wrong direction; but mine works *now* with
> what we're using *now* and it took less time to write then yours - neh neh
> neh neh. ;-)
IME it seems that most software that is written in-house is in response to
demands from other people, so there is often huge time pressures on getting
results.
For instance, application A may be developed all very nicely and in time to
do exactly what is needed. It's tested and everything is well, so it is
used regularly. Then one day, employee X comes along and says "hey software
dude, my customer needs result X from the software tomorrow, can you modify
it to give me that info please.". So then software dude modifies the code
in a very hackish way just so that employee X can give some result to his
customer the next day.
The problem is, that then software dude doesn't go back and make everything
nice and test it (he has other stuff to do), the software just gets left in
this "bad" state. Repeat the situation above a few times and you end up
with a big mess.
We have an application here that followed that exact life cycle, you could
see very easily the central well-designed part that someone took a lot of
time over, but the problem was that only accounted for about 10% of the
code. The rest was just ugly hacked on feature after feature.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Bill Pragnell <bil### [at] hotmailcom> wrote:
>>> Warp wrote:
>>>> I have learned to reread everything I write. I reread all my news posts
>>>> before I send them (well, at least if they are longer than a few lines).
>>>> Sometimes I spend more time re-editing and fine-tuning the text than
>>>> I spent writing it for the first time... :P
>
>> And it shows, your posts are without exception fluent and well reasoned.
>
> I write too many commas, though. That's because I tend to instinctively
> put a comma everywhere where I would put it if I were writing in Finnish,
> where commas are used quote a lot. In English commas are used more rarely.
>
> I have lately tried to get rid of this instinct when writing in English.
Commas are tricky... most native speakers aren't too sure where to put
them. I know when they look wrong or right, and when there should be one
when there isn't, but I'm not sure I could describe the rules. I guess
the main thing is to use them to avoid ambiguity when parsing a sentence.
FWIW your comma usage is as correct as anyone else's around here.
Just don't get me started on apostrophes :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> IME it seems that most software that is written in-house is in response
> to demands from other people, so there is often huge time pressures on
> getting results.
That doesn't address the original point of "some people can't be
bothered to learn about stuff", but rather "why software ends up being
poor quality".
> For instance, application A may be developed all very nicely and in time
> to do exactly what is needed. It's tested and everything is well, so it
> is used regularly. Then one day, employee X comes along and says "hey
> software dude, my customer needs result X from the software tomorrow,
> can you modify it to give me that info please.". So then software dude
> modifies the code in a very hackish way just so that employee X can give
> some result to his customer the next day.
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.
As with many things, you find it's not a computer problem, it's a human
problem. ;-)
I'm still ****ed off about our project management system. We have a
large and elaborate set of policy documents, procedure documents and
document templates describing how when software is to be developed
in-house, you're supposed to
- Establish a development team.
- Define the scope of the project.
- Produce a set of timelines.
- Plan the user requirements gathering process.
- Select "representatives" from all the affected "user communities" and
iteratively construct a set of user requirements. (Each specific
requirement is numbered for future cross-referencing.)
- Get an authorisation signature for the user requirements document from
management, the developers and all of the user representatives.
[Have you noticed there's no code yet?]
- Construct a technical software design specification.
- Construct a "tracability matrix", describing how each individual
aspect of the proposed software design is directly tracable to one or
more numbered user requirements.
- Have all relevant parties review the design document, ensure that
there are no user requirements missed, check for any potential
regulatory issues, etc. (Possibly requires iterative redesigns.)
- Get authorisation signatures on the design documents from management,
the developers and the user community reps.
[Have you noticed there's no code yet?]
- Write the code for the application, following all the various
guidelines about module naming, comments, algorithm documentation, etc.
- Perform testing. [I'm not even going to go *into* the whole testing
process, but suffice it to say it's every bit as complex as the spec and
design process I just described.]
OK, so here's what really happened:
- The CEO's nephew [are you seeing this??] decided what the system
should do, locked himself in a room for 3 months, and programmed it.
- A team of writers was established.
- They spent about 2 months writing a set of user requirements to match
the actual capabilities of the software actually written. (!!!)
- They wrote up the design of the system and made up design
justifications for the essentially arbitrary design decisions present in
the software.
- They completed the rest of the testing phase.
- They rolled out the software for production use.
It was at *this* point that they suddenly realised "oh, gee, in the UK
they sometimes do projects for customers who are paying in a currency
that ISN'T dollars". [What *should* have happened is that they also
realised "oh, gee, maybe we should have actually ****ing ASKED people
what features the software needs to have rather than just guessing. Hey,
maybe that's why we have this long, complex design process specified in
the first place?" But, obviously, this did not happen.]
Obviously, when you have a large, complex financial processing system
built under the *assumption* that only one currency exists, just adding
the capability to process arbitrary currencies is a "rather nontrivial
operation". Obviously what *should* have occurred at this point is that
people realised "holy crap, we've completely miss-spec'd the system! I
wonder what the hell *else* we got wrong?!" and took the thing back to
the drawing board, or at least for a major redesign iteration.
[Hopefully preceeded by an *actual* requirements gathering phase this
time...]
And, as should be *studendously* obvious, this is not what happened.
What *actually* happened is... what you described, actually. Somebody
took a few days to add a little button that lets you select what
currency you want, and next time you look at the data, it actually
remembers which currency you said.
It doesn't, you know, make any *notice* of the currency or anything. But
it lets you input it, and it displays it. :-)
"How much money did we make last month?"
*whimpers quietly*
And then we get the top-level managers asking why the figures are so odd...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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
|
|
| |
| |
|
|
|
|
| |
|
|
