Slashdot Mirror
World's Biggest 'Agile' Software Project Close To Failure
00_NOP writes "'Universal Credit' — the plan to consolidate all Britain's welfare payments into one — is the world's biggest 'agile' software development project. It is now close to collapse, the British government admitted yesterday. The failure, if and when it comes, could cost billions and have dire social consequences. 'Some steps have been taken to try to rescue the project. The back end – the benefits calculation – has reportedly been shifted to a "waterfall" development process – which offers some assurances that the government at least takes its fiduciary duties seriously as it should mean no code will be deployed that has not been finished. The front end – the bit used by humans – is still meant to be “agile” – which makes some sense, but where is the testing? Agile is supposed to be about openness between developer and client and we – the taxpayers – are the clients: why can’t we see what our money is paying for?'"
You wouldn't understand it.
You would exploit it.
You wouldn't do anything to make it better.
You would waste time complaining about everything.
But it might make it clear that it will fail much earlier and then at a lower cost.
Agile assumes you have smart, talented, dedicated individuals doing the work. Then again if you have that pretty much anything works.
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
I refer to it as "Monkey's Paw Development" (And before anybody asks agile to me ends up being "Hey let's ask developers what they'd wish for in an awesome development environment. Then give them that but give it to them in such a way that they regret ever asking for it.")
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
"Before I learned the art, a punch was just a punch, and a kick, just a kick.
After I learned the art, a punch was no longer a punch, a kick, no longer a kick.
Now that I understand the art, a punch is just a punch and a kick is just a kick."
I've worked with a few different methodologies in my time, but now that I'm older I realize all you have to do is follow common sense. It's really not that difficult.
That question would indicate to me that they're doing Agile wrong. Agile development ought to include a short feedback loop that includes not only the client, but automated tests. So, if this question is legitimate, then something is very wrong with how this project has been run.
Even if I knew that tomorrow the world would go to pieces, I would still plant my apple tree. -Martin Luther
Agile Needs Testing? Open Source It.
It's perfect for that. Open an issue tracker, let folks dump in the requirements. Give us the backend API, and I'll work on it for free an hour or two here and there, just for grins.
Oh, it's closed source? Well, I hope it's a massive disaster and you learn your lesson. You can't pay for the brightest minds. They wouldn't be caught dead slaving away at those software houses. But let them do it "for the good of mankind", they'll be brow bashing each other for a chance to get their beautiful bit of brilliance in the code base.
The government is the client. There is no reason for the public to be involved in an unfinished project.
"World's biggest" and "agile" don't really go together. One of the core tenants to agile is to break things down into small chunks. Multi year contracts for a predetermined end product are waterfall by definition. Either way, I have seen waterfall work just fine and I have seen True Agile[tm] fail hilariously miserably (to which most Agilistas respond with some form of the "No True Agile" fallacy). The most important thing is tight iterations. If a 2 week sprint fails, then it is not that big of a deal. If a 2 year death march fails? Someone's getting fired, since its the equivalent in agile-land of failing 52 sprints straight.
It's the usual crowd screwing money out of the government
HP/IBM/Accenture/BT
https://www.whatdotheyknow.com/request/130677/response/322518/attach/html/3/FOI%203648%20Response%20181012.pdf.html
.
I would love to know how cheaply this same project could be done. Probably by one person. Probably a $10,000 project with the final project size 100 times smaller, run 100 times faster, 100 times more accurate. [That is what I achieved after a payroll application they tried to force on our dept. was discarded and we rolled our own.]
Future software challenges should take a government boondoggle, any boondoggle, and have contestants try to make one that actually works with one-hundredth of everything.
It is interesting that Apple, eons ago, knew that some developers were not just 10 or 20% better than others but were 1000 or more % better. Bet this government project didn't require staff to be skilled on Defender.
I come here for the love
Just because you're agile, doesn't mean you crap daisies and unicorns. I often see inept upper managers latch onto agile as the latest magic bullet which will solve all their problems with no other changes on their part. Except they keep all the micromanagement bits, discard all the engineer empowerment bits and hand their scrum team a year's worth of priority 1 stories to implement in the next sprint. Good managers will likely be successful no mater what methodology they use, bad ones will likely fail no matter what methodology they use and the ones in between will have mixed results no matter what methodology they use.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
All Agile methodologies really are are different ways of implementing the Spiral Model of development. If used correctly, any of them can work fine. Unfortunately, that's only in theory. In practice, Agile generally becomes an excuse to use Code and Fix, which is the worst methodology and the most prone to failure. Beware anyone who claims that Agile is the solution to anything.
To me, "Agile" isn't meant to be free for all. Rather, it's meant to decouple the development of large software into more manageable chucks and teams.
Someone still has to helm this and there has to be a rather obvious set of goals and objectives to attain.
The problem I've seen with Agile, is that often, the software is being developed as it goes and to me, that's poor use of the "Agile" experience.
To me, Agile would mean that the software architect(s) know what they are doing, and have a bloody good idea of the road map to take to get there.
The "Agile" part is that for each of these goals to achieve, there is a separation of tasks and an agreement on implementation specs.
Any single team has full knowledge of the objectives of other teams and thus, this team can concentrate of their specific task and at the same time, mockup whatever is required to support their work based on any of the dependencies which depends on other teams work.
Unit Testing, Functional Testing, etc, all of that must come into play.
The Agile process should NOT be 'on-the-fly', which is what I've often seen, for that is the reason why we get delays and development costs going over budgets.
The UK Government used to have its own internal computer consultancy. This was called the Central Computer Agency - the Central Computer and Telecommunications Agency after it took over running the government phone network.
CCTA was staffed by a mixture of experienced civil servants and expert contractors, and provided support to all UK government department's computer projects. It had procurement experts, sizing experts, code, architecture, the lot. When these experts were not working for Departments they worked on UK and international standards and methodologies. Some of you may remember the OSI, ITIL, PRINCE, PROMPT, SSADM, CRAMM, BS7799/ISO 27001/2, BS5750, etc...
In those days UK Government projects ran to time and came in on budget, with CCTA project managers. But CCTA was constantly under attack from the computer industry, who saw CCTA as an expert gatekeeper, stopping them from making major profits out of government projects. They lobbied for its closure constantly, and in 2000 they got their wish. CCTA's major functions were closed down and the rump moved to OGC
Interestingly the CCTA Security and Privacy Group (the only UK Government computer security organisation at the time) had been closed down earlier at the request of GCHQ and MI5, who wanted to take its budget and responsibilities. The SPG arguably ran the first CERT (though not called by that name) in 1984, and was influential in developing, inter alia, early AV company liaison and security accreditation with initiatives like Common Criteria.
The UK government departments, encouraged by a variety of groups with ulterior motives, cut off its nose to spite its face. They are now a byword for incompetence and overspend. The collection of experts which existed in Riverwalk House during the 1980s and 1990s will never be replicated again...
Project failures are hardly a programming problem.
Project management, software engineering processes (specially requirement engineering) and design are the most risky. Hiring programmers which are fit for the project is still a risk factor though.
The bigger they are the harder they fall...
Hi:
I've seen Agile projects fail. The answer was always 'We didn't do Agile hard enough.' No. Agile can be as foolish a project management method as any other but it seems to have a religious component to it. There were always some unbelievers to needed to be rooted out. Probably they were casting magic inefficiency spells or something.
Worse yet is when companies try to do product management via Agile. If it's so wonderful, why don't we run payroll via Agile?
A lot of the 'agile' models reward talkers and people who take immediate action and can rattle off buzzwords, at the expense of more introverted engineers who like to investigate and plan before they act. In a continuously moving environment such as a social networking site, that reward system might be appropriate. In a financial back end doing mission critical work, that sounds like a disaster. So, no surprises here. One size does not fit all companies.
Open source developers will not flock to work on a bureaucracy-ridden welfare allocation and tracking platform, of all things.
I will if I get to work on the 'open source developers benefits module'.
Have gnu, will travel.
...because of the development model.
They fail because there was not enough though put in up front and the requirements are vague.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
maybe if you oh included programmers with "skin" in the game (like the few hundred unemployed ones on the dole rolls) then maybe this might not have near failed.
Any person using FTFY or editing my postings agrees to a US$50.00 charge
Agile/Extreme programming is the alternative medicine of software development. It's a collection of mostly unrelated and sometimes contradictory concepts, the only common thing between them being lack of widespread adoption. Like alternative medicine, it has components that are useful in some circumstances. These give unearned credibility to Agile, even though they were there well before it. The problem is also similar, these components are taken to the extreme and are claimed to be universal solutions to every situation. For example, acupuncture is useful to ease pain, but no matter what the charlatans say it doesn't help against cancer. Similarly, frequent testing during development can be useful, but test-driven development is taking it to the extreme, and it doesn't work at all in for example web development. And like alternative medicine has homeopathy, Agile/Extreme has their own set of ideas that are total bullshit like pair programming.
Wouldn't it be better to get 5 smaller firms to write it for a tenth of the cost each and then grade them based on user experience and number of bugs reported. Once they all finished or given up give the rest of the money to the firm that did the best job!
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
Funny thing, our agile development service provider is something called Rally. Some of the trivial things I ask for takes them two releases to implement and release. The entire code runs on their servers, and they have all the data with them. Still it takes them two releases to implement "I want to clone my queries and make minor changes". Then our top management wants our shrink wrapped software, installed on our customer's machine, who won't show us the data because it is proprietary, to ship with brand new features every three months without any regression. I used to call it insane. Now I know the right name for it. It is called agile development.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Having seen both the waterfall model and the agile model I would say that both models needs to be applied correctly to work. The agile is working for incremental development in small steps where you can adjust and adapt as you go, the waterfall works for long iterations but it requires that each step is thoroughly analyzed for problems. It works fine for slow projects but not for quick to market and cheap projects.
Changing process method in the middle of a project is a sure sign that it's time to abandon ship because the management doesn't have a clue what they are doing.
One of the primary reasons for a large project failure is that people aren't working with the same goal in sight. Even the single worker needs to know what the overall picture is and what they are supposed to do and why.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
is the excuse regularly given here in the UK.
There was a study done years ago that claimed that the chance of a project failing was proportional to it's size. Unfortunately, I cannot find a link to it this morning. If this hypothesis is true, then blaming the failure on Agile is inappropriate, as the root cause of failure is the fact that the project was too big to manage. The usual approach when things go south, is to throw more money and developers at the project--rather than scaling it back. A better approach would be, slowly merging welfare payment systems 2 into 1, like a single-elimination tournament. Yes, theoretically it would be more work, but the risk of failure is mitigated. For example, if there were 8 systems, there would be 4 merger projects--and one failed. You now have 5 systems to deal with merging, and 3 successful teams. Take the best two and merge 4 of the five into 2, etc. Big huge projects are to be avoided--humans just can't manage software development on that scale very well.
I used to wonder what was so holy about a silent night, now I have a child.
Basic problem here is non-programmers in the management visualize software "product" being manufactured somewhat like a very sophisticated assembly line or teams of workers putting together a product like they did before the assembly line was invented. But software is organic, it is grown. It is not grown like rows and rows of corn in a field but more like growing a city from a village. You are not going to plunk down a new 80 story skyscraper in downtown without huge disturbance to existing structures and users near by. You are not going to add a new Lorentz transform based asymptotic wave form expansion feature in the middle of the simulation sequence without huge disturbance. Or add payroll processing of German employees to you American HR system without serious disturbance.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
"'Agile' has been treated as a silver bullet – not as what it really is – just another design methodology – while much of what is supposed to happen with an agile software development project – especially regular and repeated testing of prototypes - has been conspicuously absent."
So no surprise it failed. If you throw away the most important bits that are supposed to ensure some quality and functionality, what you expect what happens?
No development methodology or project management style is going to help you if: 1) people are not telling the truth about their progress and 2) the project has numerous stakeholders (or a revolving door of stakeholders) with conflicting goals pulling the project in different directions.
From the article:
"[...] back in September they were telling us everything was great then too: so either they were lying then or they are lying now or they have been lying all along"
From another article:
"The senior management responsible for delivering the programme has also undergone a significant overhaul in recent months, with UC programme director Hilary Reynolds being the latest figure to be taken off the project after just four months in the role."
"[...] esponsibility for the framework is now being moved to the Government Procurement Service – as we've always said it would."
Being called 'Agile' doesn't mean that it is in the spirit or letter of 'Agile'.
The reality is that 'Agile' is in practice more of a brand than anything else. Project Managers love to apply the terminology to their projects. This does not mean they actually meaningfully follow a consistent set of behaviors, just that they use similar sounds words.
'Agile' is like 'Cloud' and 'Web 2.0'. While each phrase may have coined with a particular specific concept in mind, they became more hype than anything usefully descriptive.
XML is like violence. If it doesn't solve the problem, use more.
This should be suppose an article about "agile" and the Universal Credit. After reading the article there is no information what-so-ever, except that the Universal Credit project has been admitted to be failing.
So why is Universal Credit an "agile" project?
Why it is failing?
What is Universal Credit anyway?
Maybe that is why Twitter is so successful, the whole article is just a Twitter message: "Universal Credit, suppose to be biggest Agile Software Project, is failing".
Here is some more information:
http://www.guardian.co.uk/society/2013/apr/29/universal-credit-pilot-scheme
http://www.guardian.co.uk/commentisfree/2013/apr/30/universal-credit-iain-duncan-smith
Is it called "agile" because it's a "step-by-step approach" ?
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
The government is the client. If they are not sufficiently distanced from the dev team, they cannot properly manage the project.
My CIO laments that 30-40% of our projects fail. That seems below the norm. So Britain should expect this to take 2-3 tries to get right. And then start over Judy because there is a new development paradigm.
In software, lawyering, and baseball can you get paid to fall so much.
deleting the extra space after periods so i can stay relevant, yeah.
Quite bad troll attempt.
It's like you throw validation and verification out of the waterfall model or the v model. Do you think it would work?
Whether it was 'waterfall', 'agile'', or whatever, every project that I've worked with that seemed to put more effort into using the most hyped phrasing to describe their process than into actually developing the project has been doomed.
I liken it to religion. The spirit of most holy texts is quickly lost in the actions of adherents as they focus on the specific content rather than the message. For Christianity, specific belief in the divinity of Jesus seems to often be more important than adhering to his teachings. Similarly, in Agile, managing to map words like 'scrum', 'sprint', 'epic', 'user stories', and so on to what you do is more important than internalizing the original intent behind those words.
Projects that don't make a lot of effort to 'conform' to any specific renowned fad tend to do well. They also tend to do the sorts of stuff Agile advocates without using the words.
XML is like violence. If it doesn't solve the problem, use more.
I actually don't disagree, but I would think honesty would compel one to note that one could replace the word "Agile" in that paragraph with the name of any of the structured, "rigorous" methodologies and the observation would be equally valid. Unless one has unlimited time and budget, and the architectural equivalent of demigods, the structured methodologies fail very often too.
sPh
If you're an organisation full of MBAs who think their developers are peons and everything can be solved with meetings then the methodology won't matter.
Over my career, i've worked in the UK Benefits Agency processing claims, i've worked in their IT departments, i've worked for the outsourced departments later supporting them, and i've worked for a software company which loves agile (but will do waterfall if pushed).
The problem here isn't waterfall/agile. The problem here isn't .Net/Linux.
The problem here is the parties involved. On one side you have a government agency where people obtain seniority largely through age, not skills, and the main skill that is relevant is passing the buck when things go wrong and taking the credit when things go right (really, this is government agencies through and through - not to mention, most people with real skills/brains get out as soon as they can). On the other side you have the dinosaurs of development (not necessarily age, but sizewise).
Somebody earlier in the thread stated this whole project could have been delivered with much lower cost, with just a few devs, in a much shorter time. I'm 100% in agreement with them. The only real complexity of most government systems is the labyrinthine workflows, but they are documents and strictly followed in their paper variants, its just a matter of getting an understanding of this and turning it into software.
My recommended development approach for this project would have been as follows:
1) Hire some decent devs. They don't need to be hotshots, what is being developed is fairly simple from a technical standpoint. Mainly guys who can follow a spec.
2) Take a bunch of people who actually do the work for real, the paper pushers. Take them down the pub and get them rat-arsed. Listen to them bitch and whine about all the idiotic things they have to do in day-to-day operations.
3) Take notes of their bitching! It may help if you are drunk!
4) Any requirements given to you through the official channels are probably worthless. Dump them. They will simply mislead you from what is actually required.
5) Build the system based on what you learned from the drunk employees.
6) Demo it to the stakeholders and hand over.
7) Contract fulfilled.
Oh, and of course.... 4) Profit... erm...
I would really like to see some forensics on failure as big as this.
What went wrong?
Time estimates were too narrow? Testing failed or didn't exist? Project management? Bad programmers? Bad code?
Changing targets?
Noone speaking up when they noticed things going bad, for years? (It seems ridiculously common.)
It would be interesting to know if there's a good method to detect early warning signs of a failing project.
Changing process method in the middle of a project is a sure sign that it's time to abandon ship because the management doesn't have a clue what they are doing.
I gotta call BS on that. You're claiming that if they adopt a modern practice, and it fails, and they go back to the traditional practice as soon as they see the new practice failing, that they're automatically clueless, don't know what they're doing, and should be thrown overboard.
You'd really know they were clueless if the new practices were failing, but they just plodded ahead.
And, seriously, you think a project to implement a government program is going to have the problem of "people aren't working with the same goal in sight?" That makes sense to accuse that in most software projects, but the goals are not subjective or very flexible here. And I disagree that on large projects everybody needs to know the big picture. On a large project, the vast majority of people should be looking at their own part, and trying to get them to look at the big picture is going to cause a lot of mistakes. Most people are not any good at thinking about the big picture, and zooming in on the details at the same time. Those that you do have who can do that should be the team leaders or managers.
Yes, on small projects, you want everybody to think about the big picture. Because the "big" picture is small.
Two principles were key and could be used in any methodology.
1) Address risky (new technology, undefined specs, etc.) first
2) Regular time boxed functional builds.
If you can't address the risks successfully, then at least you can cancel the project early.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
Hee hee. I worked for Jack in the early 1980s when he had a teeny little company called Softaid. He had a very down-to-earth take on things, and I suppose that extended to today, he'd advocate picking the tools that make sense. The zealots seem to be the ones that adopt things blindly and hope they'll work, all while declaring those who don't adhere to the "one, true way" as apostates.
Just because the failure of one project is caused by .NET does not mean that a project not based on .NET is going to succeed. In fact, traditionally 80% of software projects fail.
This project is clearly failing for the second from last reason. It is also failing because it is not an "agile project". An "agile" project cannot fail and cost Billions because it must always deliver runnable software with a maximum of a few weeks delay if you use some "semi agile" process like scrum or immediately any point if you use some true agile process.
Once you deviate from "Working software" for more than a couple of sprints (everybody can make a mistake) then you are no longer doing agile. I have seen so many "agile" projects which seem to define "Working" as meaning something like "a prototype which would never work at full scale" and so they have never addressed the major problems of their class of system.
If they are "billions" of pounds down whilst doing agile, then they should have already delivered plenty of working systems and have hundreds of happy users. In this case they are a "success" even if they were a bit slower and more expensive than some other projects. If, however, they really haven't delivered anything then what they were doing was an unplanned disaster using "agile" as an excuse for not having a proper plan.
Whilst I know that the "waterfall" method of development is famed for it's failures. Whilst I know that those failures are spectacular and huge. I really don't see how you deliver, for example, 5% of a working mobile phone network. You just have to have a big interlocked plan with a working phone, transmitter, backend, management and interconnection all planned together. I don't believe that such a thing can be done in a true "agile" way and pretending that you are doing it in an agile way is a dangerous fantasy. Only once you have a working network can you start to improve it in Agile increments.
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
For complex problems, you need highly competent people, and then get out of their way. That is was Agile basically does. "Individuals and interactions over processes and tools", it is right there as the first step in the Agile Manifesto. My guess would be that these idiots went for the cheapest offer that did Agile, but did not have good people. Processes can only help, but can never turn incompetent people into competent ones. Agile is not about not needing really good people for complex projects, it is about having the processes not hinder said really good people from doing their work. Or to put it differently, if an Agile project fails, most likely it is not the fault of the Agile approach, but personnel that cannot cut it. These people will still not be able to cut it with the waterfall model.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Yes. By people that do not know the first thing about Agile. The first statement of the Agile Manifesto already clearly states "Individuals and interactions over processes and tools". Those that see Agile as a silver bullet are not even capable to understand that simple sentence or did not bother to find out what Agile is.
Also, Brooks "There is no silver bullet" still applies and there is zero reason to expect it will ever go away. Are these people completely and utterly disconnected from the real world? Have they not done even minimal research on what software engineering for complex projects entails?
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
An "agile" project cannot fail and cost Billions because it must always deliver runnable software with a maximum of a few weeks delay if you use some "semi agile" process like scrum or immediately any point if you use some true agile process.
The trouble is, you can have software that runs and passes some tests, yet still does not meet all of the mandatory requirements for the project and therefore may have no value at all in the real world. You don't get any credit for meeting 90% of the mandatory requirements on a job like this. The idea that having software that runs and maybe passes some tests has some sort of inherent value might be the biggest fallacy perpetuated by the whole Agile movement. It's just not true, and therefore neither is the claim that agile projects can't fail as a result.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
It is not really. "Individuals and interactions over processes and tools" is the first thing you need to know about Agile. It says right there in the Agile Manifesto that it is not a silver bullet and does not try to be one. The problem is all those "managers" without the first idea about software development, that think it is a process problem, because they also have not the first idea on how to select and manage competent people.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I have never, not once, seen a requirements document that accurately captures exactly what the system will do. [...] The whole point of stories is to do things in small, end-to-end slices to produce functionality quickly, let the product owner see it and play with it and then get a better idea of what they really want.
Well, in this case, "what they really want" tends to be defined literally by Acts of Parliament and/or policies set by the highest legal authorities in the government. I know it's popular to mock politicians in Europe for having no idea what they're doing economically, and it seems there's some truth to that in light of recent events, but you don't implement software to automate a major component of your national tax and benefits system in incremental changes with one guy designated as the project owner who can change his mind every now and then as you go along. That guy is the Chancellor of the Exchequer, and he has a few other things to do apart from responding in timely fashion to Bob the Programmer's request for clarification of how to implement the national tax rules.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
An "agile" project cannot fail and cost Billions because it must always deliver runnable software with a maximum of a few weeks delay
Of course an agile project can fail. Anything can fail. Event stuff that isn't using .net. I'm not saying this was Agile (most projects claiming to be Agile, aren't) but just running an Agile project doesn't guarantee the software will be runnable after a few weeks delay... An when it isn't your project is failing. But that doesn't mean you aren't following Agile procedures. Agile isn't some magic cure all formula.
An "agile" project cannot fail and cost Billions because it must always deliver runnable software with a maximum of a few weeks delay
Of course an agile project can fail. Anything can fail.
Failing to read the article is one thing. Failing to read the summary another. Failing to read the comment you are responding to is worse, but somewhat traditional. However, failing to read the quote you yourself choose from the comment you are responing to is... is ... uh special.
I'm not saying that agile can't fail. I'm saying that repeated early regular failure is a key part of agile. You are supposed to deliver "working" software all the time. Early on in the project that software may have very limited features and value, however it is supposed to always add something of value to the users life. If you fail to do that for a period of several months then your project has already failed and should be cancelled for a cost which cannot be more than a few tens of kilo pounds.
In order to fail and cost Billions they must have been a very long way from doing agile development.
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
"The Guardian reported earlier this week that five companies working on the IT contract - Accenture, Atos Origin, Oracle, Red Hat and IBM - had claimed that work on the UC system had been halted" link
AccountKiller
http://en.wikipedia.org/wiki/Basic_income_guarantee ... Winners of the Nobel Prize in Economics who fully support a basic income include Herbert A. Simon,[51] Friedrich Hayek,[52][53] James Meade, Robert Solow,[54] and Milton Friedman.[55] ..."
"A basic income guarantee (also called basic income or citizenâ(TM)s income) is a proposed system[1] of social security that regularly provides each citizen with a sum of money unconditionally. Except for citizenship, a basic income is entirely unconditional. Furthermore, there is no means test; the richest as well as the poorest citizens would receive it. The U.S. Basic Income Network[2] emphasizes this absence of means testing in its precise definition, "The Basic Income Guarantee is an unconditional, government-insured guarantee that all citizens will have enough income to meet their basic needs.
Just give every citizen (and maybe permanent resident) in the country a fixed amount per month and be done with it. Probably on the order of 50% of the per capita GDP, divide by twelve months. All you need to confirm is identity, citizenship, birth/death, and banking details for direct deposit. Then you are also set up to deal with the rise of robotics and AI displacing the need for most human labor over the next twenty years.
Contrast with:
http://en.wikipedia.org/wiki/Universal_Credit
"Gareth Morgan has written a detailed piece about the effects of welfare reform on benefits received, including Universal Credit.[6] The Universal Credit has some similarities to the negative income tax, but should not be confused with the universal basic income or basic income guarantee. There is some debate as to whether it should even be considered 'universal' at all given that it is subject to income levels and conditions around work availability.[7][8]"
Or in other words, it the requirements are buggy, it does not matter if you have great developers...
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
you base your product on .NET
Stop being dumb and bigoted. There are tens of thousands of .NET projects if not more that have succeeded. For example Stack Overflow, which any decent programmer uses.
This space for rent.
The problem I've seen is analogous to building skyscrapers and garden sheds. Some projects, like skyscrapers, have be complely designed in advance and built to be a skyscraper. You don't build a 2-story building then decide it works pretty well and then add another floor, and so on, until you have a skyscraper.
At the other end, you want a shed to protect your tools from the weather. While you could design a shed and the process to build it the way you would a skyscraper, but that's a lot of expense and it's going to take a long time. Instead, if you wanted, you could throw up some supports and put up a roof. This gazebo works well and protects your stuff from the rain. It's pretty easy to add walls, and so on.
Agile is useful for certain kinds of projects and the "classic" way is good for other kinds of projects. The real problem is that people try to use the same methodology for every project.
Stop being dumb and bigoted.
I think you failed to notice the shill posting that I was responding to. I didn't bring up .NET to bash it, rather to respond to someone who was trying to compare it to RedHat which is a system that .NET clearly doesn't approach in any of maturity, flexibility or stability.
There are tens of thousands of .NET projects if not more that have succeeded.
That's hardly a recommendation. There are hundreds of thousands of projects that have been based on PHP. There are probably millions of such projects which are based on excels. The fact is that almost every problem system has lots of "success" stories. Many of those would have been much more successful if they chose a less problematic system but that doesn't mean that they aren't in their own terms successful.
Look at some key criteria for choosing a good system
When people choose .NET, they are choosing a system which is locked into one vendor. They are choosing a system which has a record of a number of serious disasters and lack of performance at higher system demand levels. Most of all, they are choosing a system from a vendor which is more willing to pay shills to turn up on forums astroturfing their success than they are willing to solve the underlying problems of their system. This doesn't guarantee failure any more than choosing a solid system guarantees success. However, it can be a single decision point which causes some given project to fail.
Compare the decision to choose .NET to the decision to choose SQL or C or even Java. Even though they have their problems, each of those systems has multiple suppliers and it will be possible, if for example your Java supplier has a bad security record, to migrate to a different one which is more responsive. That gives a more solid environment and a better chance of long term success.
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
So, it has to expand upon the existing system, and must deliver new function, and must be delivered on time, and on cost? That's an iron triangle and therefore must be waterfall, and with a ton of contingency.
Fire the project executive that picked Agile for that one....
Beware: I believe all are created equal, and have the right to life, liberty, and the pursuit of happiness.
There are three things I have learned never to discuss with people... Religion, Politics, and Agile.
Without a decent proportion of "smart, talented, dedicated individuals" you're most likely going to fail whatever methodology you use.
Problem seems to be there's a large industry (and certified professionals embedded in middle-management) who have vested interests in pitching approaches, not solutions - and however good a programmer you are, you're not going to make the 'big-bucks' without at least flirting with management. This is a good thing, but tends to make people tie their colours to a particular mast.
IMHO most methodologies are good - some have particular strengths for particular tasks/organizations - but basically they're just common sense (formalized in a way that you can slap on a power-point and justify to the clueless guy with the money).
A theoretical worker works for a company that switched from water-fall to Theory of Constraints. He was naturally dubious, but after his intro decided that he quite liked the idea (he's certainly been guilty of coasting on a task that was coming along nicely and was going to finish by the planned end date).
Then the bad stuff happened - "We automatically lop 25% of the estimate as this is more efficient".. I can see some savings, but howabout we're more realistic and just see if this stops stuff over-running. Then we start planning (tasks, estimates, buffers, dependencies etc) and start piecing it together. End of the first day we've formalized that this project cannot be delivered ontime using TOC. So well somebody decides some dependencies can be removed. Oh, and then somebody else starts adding 'programmer tbc 1' to the plan etc.
Basically, projects fail for all manner of reasons and this is often associated to the methodology. Reality is that it's the same old humans pushing the same problems into the systems, which then just fail with slightly different nomenclature.
The problem is that in practice you usually can't get a full definition of what a major project is supposed to do until after you've implemented it. It's simply too large, and there's too many things nobody thought of until they tripped over them during implementation. And worse, the longer you spend analyzing the problem to figure all those things out before-hand the more changes have to be made to the requirements because the problem you need to solve is evolving and changing over time. Your process is nice in theory, it merely fails to acknowledge reality.
Agile often goes too far the other way, though. Sometimes things are changing too fast to keep up at all, which is usually a sign that you need to be in R&D phase rather than trying to design and implement a production system. And there's usually a minimum amount of the system that has to be present for the system to function sensibly at all, trying to release anything before you've got to that point is an exercise in futility.
They are choosing a system which has a record of a number of serious disasters and lack of performance at higher system demand levels.
What serious disasters? Do you have any references that of any, especially ones that say it was because of .NET? Those sound like typical things that people who only read Slashdot for news seem to believe. I remember the London Stock Exchange fiasco, but that was because of incompetent people rather than the technology itself. In the last quarter, Microsoft's Server and Tools division recorded an increase in revenue of 11% despite completely free alternatives available.
if for example your Java supplier has a bad security record, to migrate to a different one which is more responsive
Like who?
This space for rent.
>An "agile" project cannot fail and cost Billions because it must always deliver runnable software with a maximum of a few weeks delay
You're literally just saying that a project can't fail because it's supposed to succeed. There's many reasons agile projects can fail. If a team is unable to deliver a working release then the project has failed. Also, if the release works but doesn't incorporate the required functionality then the project has failed.
-1 disagree is not a modifier for a reason. -1 troll, flaimbait, redundant, overrated are NOT acceptable substitutes.
Agile most certainly can fail and cost billions. You develop a base, get it working. Then you add a few features, and get those working. Then you add some more features, and get those working. You repeat this process for many years, delivering working (really working) code every step of the way. Eventually you realize that you're still years off from finishing the project. Your code is working, but it doesn't have all the features that you need to actually distribute it and bring it into use. You can't afford to bring the project to completion, so you stop it.
Perhaps this was due to unrealistic expectations, perhaps it was due to an overestimation of how much work could be accomplished per unit time. Regardless, agile is not immune from any kind of failure.
-1 disagree is not a modifier for a reason. -1 troll, flaimbait, redundant, overrated are NOT acceptable substitutes.
I like Agile methodologies, although I recognize that they are not suitable for all type of projects. But on this case, the problem is not the supposed methodology used. The UK government (well, that goes for every government) has failed big projects with different methodologies (waterfall, prince2, ...) The problem resides on the companies used and the view of the bureaucracy that they need to cover their asses.
Once thing that peeves me is that the are people, even here, thinking that programmers are code monkeys. Your analogy with building is absolutely wrong. The programmers are not the workers that do the actual build. That is the job or your make, msbuild or ant. Compared with actual building, construction on a software project is infinitely cheaper. The programmers are the building architects, your tests (be either unit, integration, system or what not) are the formulas used by architects to calculate that the distribution of strength allows the building to stay upright. Every analyst, project architect or project manager on top, is just additional bureaucracy. Especially the ones that have done no coding at all and think that the system they have designed is the 8th wonder of the world. I don't think anyone will ask someone that doesn't know the steel coefficient of elasticity or its strength properties to design the next skyscrapper.
Finally, to answer to someone over here, in software development you can start designing first a "hut", and then, as you advance in the project you can refactor, add or delete code (which is just an architectural plan) to support a bigger system (first a two story house, then a 10-story building, then your skyscrapper)
... so much as a reflection of the fact the risk of development failure increases proportionally with the size/scope of the system being developed, and this is/was a very large system.
Or, to paraphrase a quote I heard (Google can't find it for me, alas):
"There are two types of complex system; the type that started out as a simple system and grew more complex over time; and the type that doesn't work."
I don't care if it's 90,000 hectares. That lake was not my doing.
If this happens, it's because you aren't following a key agile principle, which is to deliver working *useful* software on a regular basis. It's the first damned paragraph of the "agile manifesto principles" document:
We follow these principles:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
The software isn't valuable if it can't be used.
Now I'll happily admit that in some cases, this is impossible, but the point is that these cases are not examples of cases where agile has failed; they are examples of places where agile actually cannot be used, and therefore whoever has been running them has only partially implemented an agile process. Partial implementations of agile processes are, unfortunately, doomed to failure. The agile process consists of a set of mutually reinforcing practices that, if any are neglected, can all fall apart quite quickly. This says nothing about whether agile is realistic for the rest of us, because *most* software projects don't have constraints that mean a reasonably-sized team cannot have a working system that is doing something useful within 4 weeks (which is about the longest an agile process will usually let you go without delivering useful software).
I've been on multiple agile projects and let's just say that it failed over and over when Agile was the only methodology employed.
Agile plus Test Driven Development plus peer programming and/or code review plus a solid set of automated unit test tools tends to work. Agile also works best in an environment of mostly mediocre developers who happily code what is on the sticky note. They are willing to work on one mundane task after the next after the next.
Agile also works extremely well when you have at least one full time "cowboy" who is creative and is expected to follow the project through and regularly identify which direction things are moving and catch when you're about to be boxed in before you get started.
Agile is almost perfect for database applications which require no new technologies and can be implemented in a single uniform method across the board. It's absolutely ideal for projects where it's just a huge amount of code made up primarily of lots of forms with lots of data. This is why things like "Business Intelligence" middleware is so important. When these types of projects are being made, often the developers shouldn't be working on trying to write optimised queries which require fancy handling of stored procedures for example. Get the project finished, throw a crap load of hardware at running it and then optimize it afterwards. Make sure that no code is written at all without a unit test to make sure that when optimization happens, it continues to work as designed.
I have often wodnered why exactly it is that big projects, paid for by the public, always seem to fail so spectacularly. Over the years I have made some wild guesses, and some of them may be plausible:
- They are too ambitious. It is a well known phenomenon that complexity very easily becomes hyper sensitive to small variations of the premises, even if the components are very simple (like Mandelbrot). It would probably be a lot easier if they started by making a simpler tool - instead of trying to calculate everybody's entitlements everywhere in accordance with whatever the current rules, perhaps one could start by making a tool that solves one or two of the most burdensome problems social workers face, and design it so that it can be easily extended later, when it has proven its worth.
- They keep changing the specifications. This is partly because legislation that governs the input to the system changes unpredictably.
- Those in charge may be highly qualified, but with the wrong qualifications.
- They didn't spend enough time understanding the problem they wanted to solve well enough.
- They lack the will to really see it through.
Perhaps the solution for complex projects is to be found in the world of biology; an eco-system is a very complex entity, but it works because there is room for failure; individual components can fail without endangering the whole, and this in fact helps to evolve the whole over time.
I think they just wasn't agile enough
>An "agile" project cannot fail and cost Billions because it must always deliver runnable software with a maximum of a few weeks delay You're literally just saying that a project can't fail because it's supposed to succeed. There's many reasons agile projects can fail. If a team is unable to deliver a working release then the project has failed. Also, if the release works but doesn't incorporate the required functionality then the project has failed.
No he isn't. He is saying "not(p1 AND p2)" p1 is "an agile project can fail" and p2 is "an agile project can cost billions".
An agile projecr can fail in several ways:
Examples of "calling it agile" are: starting to do an analysis round of several man-years filling up a backlog with thousands of stories already estimated to help the development team; analysts that are not willing to validate the "working software" so that the team has to keep guessing for long periods of time;....
For those who don't have time to read to the end of the article (apparently most posters):
"while much of what is supposed to happen with an agile software development project – especially regular and repeated testing of prototypes - has been conspicuously absent"
To some degree, agile is sold as, "Implement this and you'll never have to really manage a software project again." Just follow the steps, we are told, and everything will just work itself out. When agile fails, we're told it is because the steps weren't properly implemented. Everything is put on the method and very little demanded of the ones in charge. That's a really prescription to fail; accountability is the first requirement for success.
Mandating success does not mean you can't or won't fail.
For every system there's a lower bound of features where it becomes useful, which requires a certain lower bound of code and thus work to achieve. Until you've hit that, you can't deliver working software, unless you define "working software" as "runs and passes some tests" which, according to your own message below, you don't. And there's no reason why reaching that point couldn't cost billions (at least in theory; in practice it's hard to see how any software could cost billions).
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Dude, you're trying to espouse the benefits of Open Source vs. Closed Source, and we've all been down this road before.
As for suggesting PHP (*shudders*), I believe there's a subreddit for that: http://www.reddit.com/r/lolphp, dedicated to all the things that your programming language's professor would have a heart-attack over, if he / she ever actually read some of these posts.
People tend to choose .Net because not only does it work, it works well. C# is a phenomenally quick and clean language for writing code in, code which tends to be both fast and easily understood. What more, .Net itself actually isn't limited to the MS world, as Mono and ASP.NET do run (at last check) on other OSs, and are free, last I checked: http://stackoverflow.com/questions/4738168/how-does-running-asp-net-on-linux-compare-to-the-standard-microsoft-centric-solu.
I am John Hurt.
The client is the government. You are not the government. You are the end user of the software and the client/customer of the government.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
He said something you don't like, specifically pointing out the hypocrisy of Slashdot, so he is a shill. You are proving the GP's point.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
*most* software projects don't have constraints that mean a reasonably-sized team cannot have a working system that is doing something useful within 4 weeks (which is about the longest an agile process will usually let you go without delivering useful software).
This debate has, very reasonably, become a matter of the degree of applicability of agile methods.
Insofar as most projects are incremental changes to existing systems, I could agree with the quote. This is not, however, where you find the hard problems in software development.
Could the mega-project in question have been restructured as a series of useful, incremental changes to existing systems? Maybe, but doing so on a basis of anything more than wishful thinking would have taken some non-trivial planning and analysis, which is anathema to agile zealots (though not, I imagine, to agile's founders, who seem to be fairly pragmatic.)
Perhaps they should have tried a no management approach?
Have you fscked your local propeller head today?
While you can use a spanner to pound a nail, a hammer is better. "Agile" like "object-oriented", "top-down design", "structured programming" and many others before it, was just the latest in the long line of "faddish" software engineering methodologies. It has its place, but it is not the be all and end all. It is a tool that must be used judiciously and in the appropriate circumstances. My impression of "Agile" is that it works best on initially small projects with minimal requirements that grow quickly by accretion. At some point in time a certain threshold is reached, the law of diminishing returns kicks in and "Agile" gradually loses it potency. I cannot imagine "Agile" working in a situation where the requirements are the size of an encyclopedia set and not a lick of code is written. I don't see it working very well in this kind of scenario.
so don't be surprised. The taxpayers, by the way, are not the client. The goverrnment is the product owner. Therein lies the rub.
-- Jimtown Kelly
I thought Agile was the solution to all the problems in the world!?
I used to be
He said something you don't like, specifically pointing out the hypocrisy of Slashdot, so he is a shill. You are proving the GP's point.
I called him a shill because he came in with a non sequitur post bringing in Red Hat when nobody is accusing Red Hat of being responsible for this and to do so (given the number of successful Red Hat based systems) would be stupid. When there were big public .NET failures, the very reasonable accusation was that, by choosing a new and immature system which had not been proven in big systems (and still really hasn't), the IT companies were being suckered by Microsoft. Probably mostly because senior management were doing favours for their friends.
Accusing a web site of hypocrisy would be so obviously stupid that not even he did that directly. There is not just you and some other guy. There are many people who have many different views. Obviously what one person says about one topic has very little chance of agreeing with what another person says about an unrelated topic, as in this case.
Until Microsoft publicly forswears the use of Astroturfing, something they have been repeatedly proven to be involved in, it is reasonable to accuse irrational supporters of theirs of being shills. Other people who want, for some reason, to promote views favourable to Microsoft and find themselves being caught up in this should demand that Microsoft stop using money to influence the public debate and should accept that, until Microsoft does that, Microsoft is limiting their right to be taken seriously.
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
What serious disasters? Do you have any references that of any, especially ones that say it was because of .NET?
The big ones I know about are mostly in-house / intranet type things I wouldn't talk about. There are hints on the internet; look up things "intranet failed" and then correlate with previous big announcements from Microsoft or their partner's .NET marketing teams.
if for example your Java supplier has a bad security record, to migrate to a different one which is more responsive
Like who?
There are at least three major commercial strands of certifiable Java; Oracle; OpenJDK (Ubuntu / Red Hat) and IBM. This is before you start talking about specialist versions like the Java compilers used to make software for Android. You can find a comparison on Wikipedia. Also consider things like gcj
If you are thinking of migrating away from Java, gcj is great. You can port to it and then dispose of the JVM completely. Otherwise it's got major compatibility problems which limit it as a mainstream alternative.
Of the above, probably the most important is Red Hat's OpenJDK based systems. Although these are based on the same code base as Oracle, they put the JVMs inside SELinux sandboxes. You can then partition these as you wish for major security benefits.
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
Unfortunately this is never going to happen until the EU becomes a true federation and implements it universally - and at a universal level, independent of country GDP. Otherwise the first state to do it will see a giant influx of citizens from EU countries with lower guarantees.
"A *person* is smart. People are dumb, panicky, dangerous animals and you know it."
- 'K' in Men in Black.
No, you called him a shill because he called out Slashdot on it's hypocrisy when it comes to proprietary vs FLOSS solutions. Classic ad hominem. It may be off topic but it is still true. You mention new and immature, which is a perfect description of PHP, Ruby on Rail, and all the newer technologies. It is really amusing watching you try to counter the truth by spewing hate at MS. Not only are you proving my point, you are continuing to prove mystikkman's point. Keep digging, Skippy, I am sure you will get out of your hole any time now.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
No, you called him a shill because he called out Slashdot on it's hypocrisy.
Look; I am calling you out because you are stupid. I've already ripped you apart on this. Let me spell it out again. Web sites are not hypocritical. People are hypocritical. There are more than two people here. The fact that Alice posts "it's okay for me to steal" and Bob posts "it's not okay for you to steal" does not mean that Slashdot is hypocritical. It means that there is more than one view here.
Oh, and calling PHP new doesn't make it new. It also doesn't make it any good. That is a language which has been broken for years and I have no idea why you would want to boost it.
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
This website is full of people because it is a social/community website. It is run by people; the articles are selected by people, edited by people, and commented on by people. Have you forgotten you are person, the singular of people? When one looks at the articles selected by the editors who are PEOPLE, and the comments by the PEOPLE who make up the body of the website, one sees an obvious bias. Saying that 500,000 people shouting and moderating down 50,000 means there is more than one view is completely disingenuous. Keep digging, Skippy, I am sure you are going to bury me in that hole you are currently have to look up to see out of.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
It is run by people;
Oh my god. You don't say. Here I thought it was run by intelligent giraffes from Alpha Centuri. All these years of deception. I'll just give up now. Your insights have suddenly made me realise none of us are worthy to inhabit the same world as you.
one sees an obvious bias.
It gets even stranger. Not just a site with "people" but those "people" have viewpoints. They write as if those views are true. Probably you are implying that the actually believe those views. Really? Amazing. What insight; what brilliance; a new level for mankind. You should apply to run Harvard. I'm sure they will take you as their leader on the basis of this comment alone.
Keep digging, Skippy, I am sure you are going to bury me in that hole you are currently have to look up to see out of.
Wow; such originality; such vision. I am sure that if we searched all the sites on the entire internet it would turn out that nobody had ever previously thought of such a comment. An answer to every question for which the commenter is too stupid to come up with a witty retort. A simple way to do down every point for which the poster can't think of a response. You are a genius; so full of yourself and yet so empty. Astounding.
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
Agile or waterfall doesn't matter. Any project may fail due to https://en.m.wikipedia.org/wiki/Pareto_principle
Casteism