> 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