In comp.risk:
Date: Tue, 5 Sep 2006 14:45:13 +0100
From: "Martyn Thomas" <······@thomas-associates.co.uk>
Subject: UK 141M-pound benefits computer system shelved
"A new computer system used to process benefits payments has been scrapped
at a cost to the taxpayer of (UK) 141M pounds, the BBC has learned. The IT
project, key to streamlining payments by the UK Department for Work and
Pensions (DWP), was quietly axed at an internal meeting last month. ... It
is the latest in a long series of computer problems for the government."
[Source: BBC News, 5 Sept 2006]
http://news.bbc.co.uk/1/hi/uk_politics/5315280.stm
[Phillip Hammond, the Conservatives' shadow work and pensions secretary,
is quoted: "It is pretty disgraceful that after two and half years of
spending public money on this project, the government has walked away from
it. We never hear of somebody actually losing their job because they
have failed to implement a project they were responsible for." PGN-ed]
Well, can we at least assume they didn't use Lisp? No more than
almost all of the other failed software projects?
--
__Pascal Bourguignon__ http://www.informatimago.com/
"This statement is false." In Lisp: (defun Q () (eq nil (Q)))
On 2006-09-06 00:43:16 +0100, Pascal Bourguignon <···@informatimago.com> said:
> Well, can we at least assume they didn't use Lisp? No more than
> almost all of the other failed software projects?
Yes. Also that the reason projects like this succeed or fail has
nothing to do with the language choice.
Tim Bradshaw <···@tfeb.org> writes:
> On 2006-09-06 00:43:16 +0100, Pascal Bourguignon <···@informatimago.com> said:
>
>> Well, can we at least assume they didn't use Lisp? No more than
>> almost all of the other failed software projects?
>
> Yes. Also that the reason projects like this succeed or fail has
> nothing to do with the language choice.
I'm not so sure. At lot of these enterprise-y projects collapse under
the weight of their own technology infrastructure, and the rigidity of
the technologies used prevents a re-design (or makes it politically
infeasible) once a certain point has been reached. They tend to be the
last word in over-specified, under-thought, inflexible rubbish, in my
weary opinion.
--
Tiarnán
········@yahoo.com (Tiarn�n � Corr�in) writes:
> I'm not so sure. At lot of these enterprise-y projects collapse under
> the weight of their own technology infrastructure, and the rigidity of
> the technologies used prevents a re-design (or makes it politically
> infeasible) once a certain point has been reached. They tend to be the
> last word in over-specified, under-thought, inflexible rubbish, in my
> weary opinion.
The fact that they don't use Lisp is a symptom of this, not the cause.
Technical solutions rarely solve social problems, and this is a social
problem.
Managers like to manage, and like to control. This means that, if
unchecked, they will dictate every detail of the project, even before
starting to build it. And once it's specified, it can't change,
because that means losing face: there seems to be manager-virtue in
never changing one's mind, because that is an admission that somehow
calls into question all of the manager's other decisions.
It's not the rigidity of the technology that prevents a redesign; it's
the rigidity of the project management. The rigidity of the
technology is nothing more than a recapitulation of the rigidity of
the management, and throwing Lisp into the mix would not solve the problem.
Charlton
Charlton Wilbur <·······@mithril.chromatico.net> writes:
> The fact that they don't use Lisp is a symptom of this, not the cause.
> Technical solutions rarely solve social problems, and this is a social
> problem.
I don't think it's as clear cut as that, though you're half right.
The cost in wasted time of re-engineering a system written in an
inflexible language, with bog-knows how many serialization libraries,
hairy object interfaces and mis-designs is a technical problem.
> Managers like to manage, and like to control. This means that, if
> unchecked, they will dictate every detail of the project, even before
> starting to build it.
Ah, but they don't build it. I have always found the 'mushroom'
approach helpful in these situations.
> The rigidity of the technology is nothing more than a recapitulation
> of the rigidity of the management, and throwing Lisp into the mix
> would not solve the problem.
Indeed, perhaps Java is beloved of project managers because it so
closely mirrors their thought-processes. Seriously though, any
organization that functions like this is waiting to have its clocks
cleaned by a small technically-driven company.
--
Tiarnán
Tiarnán Ó Corráin wrote:
> Charlton Wilbur <·······@mithril.chromatico.net> writes:
>
> > The rigidity of the technology is nothing more than a recapitulation
> > of the rigidity of the management, and throwing Lisp into the mix
> > would not solve the problem.
>
> Indeed, perhaps Java is beloved of project managers because it so
> closely mirrors their thought-processes.
I thought it fairly apparent that Java and C# are designed for
corporations who want replaceable programmer cogs, not intelligent
mavericks who "know what they're doing." The programming culture is
completely opposite that of Lisp. There are advantages and
disadvantages to each culture, generally regarding your own code vs.
external dependencies. For instance, there's a much higher chance that
an external Java or C# dependency is going to work, without you having
to futz it and customize it.
Cheers,
Brandon Van Every
> Well, can we at least assume they didn't use Lisp? No more than
> almost all of the other failed software projects?
That assumption would seem a safe bet.
My money's on Java. But it would be good to know what language it was.
Perhaps its on theregister.co.uk ?