The Pentagon's Seven Million Lines of Cobol

MrMetlHed writes "A portion of this Reuters article about the Pentagon's inability to manage paying soldiers properly mentions that their payroll program has 'seven million lines of Cobol code that hasn't been updated.' It goes on to mention that the documentation has been lost, and no one really knows how to update it well. In trying to replace the program, the Pentagon spent a billion dollars and wasn't successful."

Comments

Cobol is self-documenting

[mveloso]

But - but - cobol is supposed to be self-documenting!

Re:Cobol is self-documenting

[Anonymous Coward]

But - but - cobol is supposed to be self-documenting!

TL;DR

Re:Cobol is self-documenting

[Avidiax]

The claim that the documentation "vanished" seems bogus. Far more likely in my opinion that it never existed in the first place, or that at some point they fired everyone, and thus broke the chain of custody.

Re:Cobol is self-documenting

[cold fjord]

Maybe at the level of modules or minor subsystems, but with software systems that large you would still want architecture documents and data definitions as a minimum.

Re:Cobol is self-documenting

[cold fjord]

Normal staff turnover and one building move would probably stand a good chance of taking care of it.

Re:Cobol is self-documenting

[TheCaptain]

Eh...there probably was some half baked documentation at some point, but I doubt it was maintained very well by the people who edited that codebase over the decades.

I also doubt they fired any of them unless they were contractors...you have no idea how ugly the federal workers union is about things like this. They almost can't lose their jobs through incompetence or anything else. Which brings me to the problem...the people who wrote it probably wrote half-assed spaghetti code, didn't document it well, and then died off or retired. No one is learning cobol anymore, so you get what we've got right here.

Plus...trying to replace any system in the government or military is an extremely painful exercise that probably fails more often than it succeeds. Between the people you need to deal with, and the policies you need to dance around...it's almost impossible to stand a new system up. (Unless you have someone in a high place that really gets it, and champions the hell out of it...and even then, it's iffy.)

I was a defense contractor for 4 or 5 years. It was quite a few years ago now. Left that behind, and I don't miss it.

Re:Cobol is self-documenting

[interval1066]

Far more likely in my opinion that it never existed in the first place, or that at some point they fired everyone, and thus broke the chain of custody.

Being the spouse of some one who works for a Gov. entity (her) AND being in IT (me), its far more likely that the the engineers who created the system(s) have long since retired. Fed workers rarely get 'fired'. And interestingly its more likely that the system was documented to a much higher degree than you would think; there are entire fed. departments devoted to documenting things and creating requirements documents. The problem is once the process is documented and archived, those same sad COBOL systems are used to process the records that describe the location of the documentation

Re:Cobol is self-documenting

[plover]

The claim that the documentation "vanished" seems bogus. Far more likely in my opinion that it never existed in the first place, or that at some point they fired everyone, and thus broke the chain of custody.

I think the truth is probably much simpler than that. Someone dropped the card deck containing the documentation, and they never managed to sort it back into the right order.

Re:Cobol is self-documenting

[Anonymous Coward]

Cobol is self-documenting, for anyone who can read the language. All it takes is a certain amount of computer-math skills and familiarity with an ASCI teletype letter/symbol set. That said, though, there may be circumstances where, to go back in on really old systems, to reconstruct after an old computer has scripted, you might have to dust off some punch-card and punch-tape reading skills. For a lot of what Cobol was used for there was no need for GUIs, or even CRTs, and modern scripting, that makes any kiddie who can link libraries a 'computer prorammer' was unheard of back then.
I suppose that giving a modern programmer a program in Cobol can be compared to giving a modern driver a car with a crank-starter and a throttle and spark-advance on the steering wheel. Watch out, kids, the learning curve could break your elbow...

Re:Cobol is self-documenting

[Jane Q. Public]

"The claim that the documentation "vanished" seems bogus. Far more likely in my opinion that it never existed in the first place, or that at some point they fired everyone, and thus broke the chain of custody."

I agree with the latter, but that still means the documentation did "vanish". It just doesn't address why.

I think the money would have been better spent simply replacing the Pentagon and all its staff. The new one can be 5-sided, too. But they should build it in Montana and staff it with locals. It's cheaper. They'd probably win more wars for us too.

Re:Cobol is self-documenting

[Anonymous Coward]

there's machines for that

Re:Cobol is self-documenting

[BrokenHalo]

Eh...there probably was some half baked documentation at some point, but I doubt it was maintained very well

That may well be because any decent COBOL programmer knows (or knew) that the code itself is indeed self-documenting. COBOL code may be tedious to write (actually, it certainly is) but it has the advantage of being quite easily maintained.

So, no excuses. It's more likely the US Govt is too cheap to hire anyone with the appropriate skills. It's also quite possible that an age bias has been applied by their HR bozos, thus excluding that generation most likely to be good at this work.

Re:COBOL is self-documenting

[ebno-10db]

Yes, but every line is documented the same way, "don't touch this because I don't know what it does but sometimes it works".

Re:Cobol is self-documenting

[Em Adespoton]

"The claim that the documentation "vanished" seems bogus. Far more likely in my opinion that it never existed in the first place, or that at some point they fired everyone, and thus broke the chain of custody."

I agree with the latter, but that still means the documentation did "vanish". It just doesn't address why.

I think the money would have been better spent simply replacing the Pentagon and all its staff. The new one can be 5-sided, too. But they should build it in Montana and staff it with locals. It's cheaper. They'd probably win more wars for us too.

They'd have to deal with the Zombie Apocalypse then though....

Re:Cobol is self-documenting

[budgenator]

Well the source code is usually fairly legible, but at 7 million lines the spaghetti factor is likely pretty high.

Re:Cobol is self-documenting

[Ashenkase]

In trying to replace the program, the Pentagon spent a billion dollars and wasn't successful.

Translation: the pimps deployed highly effective counter measures to shock and awe the client, the result was a resounding victory of "extended" contracts!

Re:Cobol is self-documenting

[mrmeval]

Hughes would compartmentalize documentation on how to manufacture everything. There software had similar fragmentation in the source code. To collect all the documents would require having access to the root document which would then lead to the first level. Then would come tertiary and quaternary levels. There is NO centralized list of all the documents needed, you MUST parse every sheet of paper.

I recall one gasket for a keyboard for some aircraft system they'd installed in the mesozoic era. When Raytheon absorbed and gagged on them they'd done an incredible job of digitizing and indexing all of that documentation. Even with that Herculean effort the drawing on how to make the gasket which had dimensions and the material was completely lost. The government did not afai could find out had never gotten complete plans for that system. They had to recreate that piece of paper at a cost of 55,000 dollars.

Nah, don't think Raytheon is all puppies and kittens, they're just more efficient at sucking money out of government.

Re:Cobol is self-documenting

[mrmeval]

to clarify Raytheon did the digitizing and had a high dollar 'librarian' with several masters degrees oversee the library system. Hughes was a geriatric Alzheimer's patient in comparison.

Re:Cobol is self-documenting

[MobSwatter]

In trying to replace the program, the Pentagon spent a billion dollars and wasn't successful.

Translation: the pimps deployed highly effective counter measures to shock and awe the client, the result was a resounding victory of "extended" contracts!

Either that or they started development long before anyone knew what a flowchart was. As for the 7 million lines of code, exactly how much of it is actually active? Or is this just the pentagon getting ready to ask for money again?

Re:Cobol is self-documenting

[Anonymous Coward]

That what you get when assembler programmers have to use a Cobol compiler while dreaming of becoming a Java programmer.

Re:Cobol is self-documenting

[Anonymous Coward]

Seven million lines of COBOL might only be a short sorting routine.

Re:Cobol is self-documenting

[Chris Mattern]

but it has the advantage of being quite easily maintained.

Ahhhhh...no. COBOL has a GOTO. Legacy COBOL has a tendency to use the GOTO a lot. In legacy COBOL, all the variables are global (although you did at least have to declare them all). These things do not make for easily maintained code.

Re:Cobol is self-documenting

[PPH]

those same sad COBOL systems are used to process the records that describe the location of the documentation

Its in Hangar 51, crate number 9906754.

Re: Cobol is self-documenting

[NemoinSpace]

No, vanished in this case means destroyed. Before a bureaucrat can set up his own empire, he must incapcitate the former. If he can get paid a billion dollars without actually going through the trouble of setting up his empire, than so much the better.

Re:Cobol is self-documenting

[budgenator]

We did flowcharts in Basic and Fortran, but COBOL was IPO charts (Input, Process, Output) and module diagrams for us; oh we did psudeocode of the modules, psuedocoding COBOL is really tough because cobol is so wordy.

Re:Cobol is self-documenting

[__aaltlg1547]

Normal staff turnover in the military is 2 years on an assignment. People come in knowing next to nothing, spend two years learning 80% of what the previous incument knew and then move on. It doesn't take many cycles of that before all useful knowledge is lost.

Re:Cobol is self-documenting

[Ian A. Shill]

So, then he says to me, "Which is the way he wants it. Well, he gets it. I don't like it any more than you men."

Eh...there probably was some half baked documentation at some point, but I doubt it was maintained very well by the people who edited that codebase over the decades.

I also doubt they fired any of them unless they were contractors...you have no idea how ugly the federal workers union is about things like this. They almost can't lose their jobs through incompetence or anything else. Which brings me to the problem...the people who wrote it probably wrote half-assed spaghetti code, didn't document it well, and then died off or retired. No one is learning cobol anymore, so you get what we've got right here.

Plus...trying to replace any system in the government or military is an extremely painful exercise that probably fails more often than it succeeds. Between the people you need to deal with, and the policies you need to dance around...it's almost impossible to stand a new system up. (Unless you have someone in a high place that really gets it, and champions the hell out of it...and even then, it's iffy.)

I was a defense contractor for 4 or 5 years. It was quite a few years ago now. Left that behind, and I don't miss it.

Re:Cobol is self-documenting

[plopez]

" As for the 7 million lines of code, exactly how much of it is actually active?"

That's the multi-billion dollar question, now isn't it?

Re: Cobol is self-documenting

[Anonymous Coward]

I know that guy that worked for a government contractor during the Y2K remediation days. The government, in an attempt to quantify the value of programmers, paid per line for programming. There ya go

Re:Cobol is self-documenting

[Anonymous Coward]

Perhaps the Department of Defense should re-classify all their software documentation and source code as artillery munitions and the act of developing software as a combat operation. There shall never again be a software project failure or missing documentation after that.

Re:Cobol is self-documenting

[jbohumil]

I work on Cobol systems where the documentation has literally yellowed and begun to disintegrate.

Re:Cobol is self-documenting

[jbohumil]

It depends. I've seen some Cobol systems where programmers created truly unreadable layers of code with all kinds of convoluted methods. IN some cases it almost looks like they tried to make it impossible to read the code. I once saw a simple date routine that for some reason was running forever, only to crack it open and find out that the program proceeded to build through the most complex and inefficient ways an actual calendar of every possible date within several decades - perhaps even the whole century, I can't remember, only to subtract one date from the next. It took forever. Another implementation of this might have been done in 20 lines of code. But because of really really bad programming, it took a thousand lines of really messy hard to maintain code.

Re:Cobol is self-documenting

[RoknrolZombie]

I will say that I was pleased to discover that my old software (my very first program, written with one of my NCO's - and it's not clear from the comment, but that wasn't anywhere close to my job...it just happened for convenience) was still being used more than 10 years after the fact, although I do admit that I was a bit dismayed as well...in retrospect it wasn't all that impressive :p

Re:Cobol is self-documenting

[Anonymous Coward]

Mod parent up (way up) its not just funny, its also one of the "BIG" features of COBOL! One of the really super big reasons why the management weenies keep trying to shove it down our throats. Sure, they don't have to code this crap! I remember reading a partial history of COBOL for a programming languages class, and Grace Hopper said that they got together to create it, and never expected it to still be in use 3 months later. They fixed it a bit after 9 months or so, but never expected it to last even that long. She stated "If we had thought it would be around more than 5 or 6 months, we would have (and certainly could have) done a MUCH better job of it. Its not self documenting, its not efficient as a language goes, its utterly verbose to code (a meta-carpal tunnel syndrome starter kit), and should have died when Grace and Co. expected it to. Last I looked (and thank God thats a while ago), you still couldn't have any characters in columns 1-12, and couldn't have any characters past column 80 (you know, just like a punched card). Fscking cobol!

Re: Cobol is self-documenting

[Mabhatter]

Projects like this are something that rare 20-something's can handle. It takes "grey hairs" with experience in putting all the parts together because they have done boring payroll apps for 20 years. Even if you DNT know THIS app, you know what pieces have to be there because of precedent, legal, or historical standards so mentally filling in the flow chart is easier.

Re:Cobol is self-documenting

[Anonymous Coward]

Not to mention that being readable and being *readable* are different things. Which is quicker and easier to understand?
Eleven plus one-hundred and seventy-eight,
or,
11+178?

A common and shortened nomenclature specifically designed for a problem can, unsurprisingly, be better than plain English.

Re: Cobol is self-documenting

[Mabhatter]

Those tapes got wiped when the magnetic alien was stored too close.

Re:Cobol is self-documenting

[Anne Thwacks]

Have you seen Cobol? It takes several hundred lines to write a "Hello World" program. 7 million lines of Cobol can probably be replaced by 70 lines of Perl (at the expense of any possibility of anyone ever reading it).

Re:Cobol is self-documenting

[SuricouRaven]

They probably had it classified so high only two people were allowed to read it, and they both retired or died.

Re:Cobol is self-documenting

[BrokenHalo]

Sure, COBOL has a GOTO. But if you're old enough to have programmed in COBOL (i.e. when you didn't get the projects involving Fortran and assembler), you should be old enough to know that Real Programmers aren't afraid to use GOTO.

Now excuse me a moment while I just go shoot this velociraptor... ;-)

Re:Cobol is self-documenting

[neonsignal]

I'm no fan of COBOL (and enjoyed Dijkstra's criticism), but its main flaws are not to do with being verbose. "Hello World" is longer than it would be in most languages, though a lot of that is just overhead; in general the line count in COBOL is not massively bigger than in other languages. Of course, the syntax in each line can be a mouthful, with an excessive use of keywords obscuring the structure, but in coding business logic this is not always a disadvantage (business logic is often convoluted anyway, and at least the code fragments are a little more readable to a layperson).

My point is, although you are probably correct that there is very likely a better choice of a modern language to replace this code, it is going to be a lot more than 70 lines worth. The real saving in code is most likely to come through the refactoring process, whatever language is chosen.

Re:Cobol is self-documenting

[BrokenHalo]

IN some cases it almost looks like they tried to make it impossible to read the code.

Why "almost"? Inside every COBOL programmer, there's a frustrated Fortran programmer struggling to get out. (I have been both, for more years than I care to remember.)

COBOL obfuscation can be as much fun as similar work in C, ALGOL or ADA. You lose points for inefficient code, though. And, of course, one big drawback of COBOL is that it is usually impossible to generate self-modifying code.

Re:Cobol is self-documenting

[Anonymous Coward]

When I worked on the SDS project, we had to document things with "Chapin Charts", which were good for system overviews, but not for the detail documentation we had to use them for. They were poorly maintained, but even if they had been maintained, would have retained their uselessness. I don't believe any SDS code is still running (the majority of it was written in COBOL), but I don't think the sorry documentation issues were unique to the Navy.

Re:Cobol is self-documenting

[oh_my_080980980]

And writing an accounting program in another language, would take exponentially more lines of code....there's a reason why the financial services industry still uses COBOL...it works. There has not been a language to date that can handle business needs.

If you bothered to research COBOL and not talk out of you ass, you would know this.

Re:Cobol is self-documenting

[oh_my_080980980]

That is the likely scenario. As the workforce ages and decisions where made to outsource more IT functions, eventually you end up with pool of people who do not understand the technology you are using and can't maintain it. This is not unusual. This happens in large corporations.

Re:Cobol is self-documenting

[xalorous]

Don't forget "Job Security". For government produced software means obfuscated code with absolutely no written documentation. Whether created by federal service employee or contractor.

Re:Cobol is self-documenting

[Cro Magnon]

I work on Cobol systems where the documentation has literally yellowed and begun to disintegrate.

I have too. And that was in 1986!

Re:Cobol is self-documenting

[Anonymous Coward]

The fact that they are still doing their own payroll and not using companies that specialize in that area is proof enough of incompetency. They appear to outsource those things that any sane person would not, such as soldiers in the guise of mercenaries, but those areas that most large corporations have outsourced or are using industry accepted standard, they insist on doing it their own way.

The military has not changes, in this respect, since I left almost 30 years ago.

Re:Cobol is self-documenting

[Anonymous Coward]

Or you could just use the built-in SORT verb in one line of COBOL I suppose.

Re:Cobol is self-documenting

[Anonymous Coward]

Id Division.
    Program-id. Hello.
Procedure Division.
    main.
        Display "Hello World" upon sysout.

Yep, several hundred lines there. Almost as long as a Java class to do the same.

Re:COBOL is self-documenting

[davidwr]

Yes, but every line is documented the same way, "don't touch this because I don't know what it does but sometimes it works".

Um, so, DON'T TOUCH IT already.

Re:Cobol is self-documenting

[S1ngularity]

exactly how much of it is actually active?

For every line of active duty Cobol code, there are seven support lines behind the front.

Re:Cobol is self-documenting

[Anonymous Coward]

It wasn't THAT wordy - I seem to recall that a properly written "Hello World" in COBOL only required about 2 pages code when printed on greenbar paper......

Re:Cobol is self-documenting

[DanielMartin01]

Of course it is -- to at least the same degree that anything written in C is portable.

Re:Cobol is self-documenting

[kmoser]

Well the source code is usually fairly legible, but at 7 million lines the spaghetti factor is likely pretty high.

You assume the source code was still available.

Re:Cobol is self-documenting

[Hognoxious]

That may well be because any decent COBOL programmer knows (or knew) that the code itself is indeed self-documenting.

All code[1] is self documenting, if you mean that it documents what it does.

In practice the problem is often related to what it was intended to do, and why.

[1] arcane compiler switches & directives aside

Re:Cobol is self-documenting

[Anonymous Coward]

this is just one tip of the iceberg. the world network runs on software that is eating itself alive. have you noticed that just over the past year, there is an increase in the 'anomalies' that spew from the bureaucracies? follow one of them up by talking to a worker in the system. if yr patient with the person and listen, there is a very good chance that they will convey that they have no idea of how to make the system behave and give you whatever you didn't get.

Re: Cobol is self-documenting

[Flere Imsaho]

It's alright. We have top men working on it now.

Re:Cobol is self-documenting

[budgenator]

Have you seen Cobol? It takes several hundred lines to write a "Hello World" program. 7 million lines of Cobol can probably be replaced by 70 lines of Perl (at the expense of any possibility of anyone ever reading it).

Hello World isn't so bad

  IDENTIFICATION DIVISION.
            PROGRAM-ID. HELLO-WORLD.
            PROCEDURE DIVISION.
                    DISPLAY 'Hello, world'.
                    STOP RUN.

Even Hello, OS/360 circa 1972 is

    001 IDENTIFICATION DIVISION.
    002 PROGRAM-ID. 'HELLO'.
    003 ENVIRONMENT DIVISION.
    004 CONFIGURATION SECTION.
    005 SOURCE-COMPUTER. IBM-360.
    006 OBJECT-COMPUTER. IBM-360.
    0065 SPECIAL-NAMES.
    0066 CONSOLE IS CNSL.
    007 DATA DIVISION.
    008 WORKING-STORAGE SECTION.
    009 77 HELLO-CONST PIC X(12) VALUE 'HELLO, WORLD'.
    075 PROCEDURE DIVISION.
    090 000-DISPLAY.
    100 DISPLAY HELLO-CONST UPON CNSL.
    110 STOP RUN.

Re:Cobol is self-documenting

[Anonymous Coward]

It was normal to draw a diagonal lines across the edges of the deck to help with manually putting a deck back together. Plus it was common to punch a sequence number onto each card in the deck.

Re:Cobol is self-documenting

[plover]

I used to do both those things with my schoolwork. But I never had a 7 million card deck, either.

Re:Cobol is self-documenting

[krept]

Not to mention when it's contractors coming and going, new contractor has to seek out previous incumbent for source. The guy who had those files doesn't work for that company anymore.

Re:COBOL is self-documenting

[stevenddeacon]

Six times nine is fifty-four ... learn your times tables for god's sake! Six times seven is forty-two.

COBOL is self-documenting

[davidwr]

At least that's what my old B-school roommate told me.

Typical government efficiency...

[intermodal]

a billion dollars to replace an antiquated program and the project fails. This is why our military is the most expensive in the world, and why I've argued for years that comparing military spending between nations is only apples to apples if each nation is competently spending what they are given.

Re:Typical government efficiency...

[Anonymous Coward]

I've seen this happen with lots of "let's replace this antiquated software" projects. There's alot of trust put into hiring someone to do this properly. Usually the people writing the check don't know enough about software architecture or requirements gathering to foresee that the contractor is going about it the wrong way and dooming the project to failure. Or administration that isn't open to the concepts that must be embraced to move from paperless to electronic, etc. So many ways for something like this to fail terribly. Only time I've seen it succeed is a combination of competent leadership of the software development combined with the administration trusting the judgement of the software developer when it advises on process changes that will need to be implemented. Rarely do you get both of these things together, and when you are missing one then it's a disaster.

Re:Typical government efficiency...

[intermodal]

Quite so. It's necessary to understand that to accomplish what you want, you have to involve the right people and give them what they need, and take their word for it when they tell you what they need.

Re:Typical government efficiency...

[cold fjord]

I think that is correct. There is also the fact that until very recently many of the major powers, and major regional powers, were still mainly using conscription to fill their armies. It makes a bit of a difference when you are paying your soldiers market rates for their labors instead of what you would pay conscripts. You also have the factor of first world cost structures versus third world costs. Last time I look at some data within the last few years, an American corporal (1 step above the highest private) was paid about what a Chinese junior general was paid. Same thing goes for supplies, expenses, and systems.
 

Re:Typical government efficiency...

[Anonymous Coward]

But it is apples to apples...it's the rare military that spends money effectively. The only ones that do are the ones that don't have any money. I remember reading an article on China's military spending. IIRC, it was the equivalent of $110b US with the estimate that over 90% of that was being lost to graft.

Our military is the most expensive in the world because we give it more money. We can spend less by simply spending less. The military is being run by what amounts to shopaholics who have a credit card with an absurdly large limit...it's no wonder that they blow large amounts on useless crap. Lower the credit card limit and they'll start putting more thought into each purchase.

Re:Typical government efficiency...

[cold fjord]

I think your understanding is flawed. They already have competing priorities and don't get enough money to fund them all. In comparing the US and China, remember that the US pays everybody a lot more than China does. An American corporal is paid about as much as what a Chinese is paid. You may also want to keep in mind that defense spending as a portion of GDP has fallen from about 38% of GDP in 1945 to about 4-5% today. Spending for social welfare programs is about 2x what is spent on defense.

   

Re:Typical government efficiency...

[peragrin]

I don't give a rats ass comparing anything to GDP. the Gross Domestic Profit has absolutely nothing to do with the Government, and anyone who says other wise is a fucking idiot.

Definition of 'Gross Domestic Product - GDP'
The monetary value of all the finished goods and services produced within a country's borders in a specific time period,

Where does that definition say anything about Government income(taxes)? Why do people think that just because you and me run a million dollar business that we are worth a Million dollars? So why is the government worth the GDP, when it only worth the tax dollars paid into it?

Sorry I didn't mean to go off on you personally. I just get annoyed when people think the GDP is some how related government, and government spending. Taxes are the sole income of government.

Re:Typical government efficiency...

[ebno-10db]

defense spending as a portion of GDP has fallen from about 38% of GDP in 1945 to about 4-5% today

Comparing current spending to WWII spending is either disingenuous or just plain silly.

Re:Typical government efficiency...

[tnk1]

Apples to apples is always a good comparison, but exactly what military are you saying is more efficiently run? The US military may waste more money per year than the GDP of some small countries, but it is probably not the most proportionally wasteful military out there.

It's also important to note that as the mission of the military becomes more expansive, there is a lot more room for waste. If you're running the military of say, Luxembourg, you might be able to keep a tighter leash on it, not just because it is smaller, but also because I doubt it leaves Luxembourg much, and when it does, it probably doesn't go farther than next-door for training exercises.

If you're talking about the military that has the most missions of any military on Earth, it's really, really difficult to find someone who has a comparable profile. Only the USSR's armed forces really ever came close, and China isn't there yet. The other NATO countries just don't have the same mission and only the UK and France have any pretensions towards serious power projection.

Re:Typical government efficiency...

[Anonymous Coward]

as far as I can tell the reason you military is so expensive is that there is a whole lot of the stuff on the military budget that other countries put on other budgets,
i.e. D wants to spend on some government project, R wants too but to make it edible for their voters they paint it camo and call it military

Re:Typical government efficiency...

[BrokenHalo]

Our military is the most expensive in the world because we give it more money. We can spend less by simply spending less.

You can also spend less by not treating every other nation on the planet as an enemy.

Re:Typical government efficiency...

[NatasRevol]

Considering our GDP is about $15T, I'm calling complete bullshit on your 4-5%. That would mean spending is $600-700B. It's actually twice that.

Not that the government *has* $15T to spend. They have about $5T in taxes, roughly 25% of which is spent on military.

Re:Typical government efficiency...

[Em Adespoton]

Added to this, people often have the misconception that just because something is "old" it is less complex than the current requirements. In reality, all that COBOL was written to perform the same function on severely limited hardware that they now want to accomplish on a simple server system -- and I bet the data and processing requirements both then and now are astronomical. The end result is that whoever is doing the new system is likely pitting themselves against whatever the brightest minds of yesteryear were able to produce, and it won't be simple. That old system had time to be fine tuned, and the protocol built up over the years is designed around the precise quirks created by the system. Thus, the entire architecture and ALL related protocol has to be re-examined prior to architecting a replacement system -- and I doubt the winning bidder was even asked to bid on that, especially in a military organization.

Re:Typical government efficiency...

[sneakyimp]

Somebody got fleeced. $1B to translate 7M lines of code comes out to about $142.86 per line of code. As a taxpayer, I want my share of that money back.

Re: Typical government efficiency...

[Anonymous Coward]

Is it government inefficiency or robbery by private contractor?

Re:Typical government efficiency...

[pwizard2]

If we didn't interfere in other countries' business, so many people around the world wouldn't hate us and we would have no use for such a large military.

Re:Typical government efficiency...

[cold fjord]

I'm not sure where you got your numbers from, but you may have a couple of items swapped.

In 2012, the US federal government spent $3.56 trillion dollars, with revenues of $2.44 trillion, and a deficit of $1.12 trillion.

Entitlement spending was 61.9%, and defense spending was 18.7% (~ $677 billion).

You can find that data here: Federal Spending by the Numbers - 2012

You can see the long term trend of defense versus entitlement spending here.

Re:Typical government efficiency...

[dan_barrett]

I've maintained legacy payroll software (Oracle RPT, predates PL/SQL) and have been marginally involved in migrating clients to the new shiny payroll system. Generally it fails where the client wants the new system to behave exactly like the old system.

The new system usually can handle the required business rules (or it's not too much work to make this happen) but all the processes around those rules are different. eg the new system needs to generate report RW200 to lineprinter 6, daily at 6PM and must be formatted just so (no one reads the first 1000 pages, but the summary page is critical to some obscure business process.)

So, the new system has to print unformatted ASCII to a serial line printer, in an obscure way, on nonstandard paper, that's hard to replicate in a modern report writer. Never mind the already written, laser printed, on-demand reports (or emailed, or exported to excel or whatever) have the same information - it's NOT THE SAME - our users will be confused so it MUST BE CHANGED!.

Rinse and repeat for basically everything else in your system and you've heavily modified your new system to behave just like your old payroll system (and killed any performance improvements, worked out all the bugs etc again). because it's so heavily modified you're basically on a unique version of the new system that only certain programmers really understand. Ant they're going to retire / leave because the project was so shit to work on.

Add the usual government oversight/waste and you've blown a billion dollars. (that's impressive though, I have to say.)

Re:Typical government efficiency...

[cold fjord]

The government doesn't create the GDP, but it does tax economic activity reflected in the GDP and various types of wealth. The government uses taxes to get the money it spends. The tax burden imposed by the government on the economy may be represented as a percentage of the GDP. Maybe you've seen some faulty discussions of the issue in the past, but it is a fairly common way of describing the burden of government and taxes on an economy, and on society. That isn't a claim that the government creates the GDP.

Re:Typical government efficiency...

[cold fjord]

That depends on the purpose of the comparison, doesn't it? Defense spending has been tending to decline since WW2. You can see that here. Noting that fact is neither disingenuous nor silly. But thanks for your unserious and gratuitous comment.

Re:Typical government efficiency...

[gmueckl]

This reminds me of the odd undocumented workaround processes that always seem to creep into the work habits of the users of some complex systems. It is almost impossible to catch those when gathering requirements because they never formally exist.

Re:Typical government efficiency...

[AndrewLarge]

This is less of a "government efficiency" issue than it is a "contracting" issue.

Imagine you have a gigantic system like this that you need to replace. So you want to hire someone to build the replacement. You can't just go give $1B to company X and say "I'll see you in five years when you've built me a new pay system" - the taxpayers (and their representatives) would never go for that. Instead, you first go build a set of requirements that such a system must meet and then you award the contract to build the system to the company that convinces you that (a) they'll build the system that best meets those requirements and (b) they'll do so in a cost-competitive way (if not cheapest, then close to cheapest).

Therein lies the crux of the problem - building large complex software systems over multiple years "to spec". In short, it can't really be done:

• 1. You won't get the requirements right. At best, if you spend a ton of money, you'll get a decent set of requirements, for some narrow segment of your user base, that is appropriate for the state of the world at contract award. But they'll be woefully out of date by the time the system is actually built. More often, you won't pay enough money and you'll get an RFP that is 50%+ "cut and paste" from previous RFPs, and has only a passing resemblance to what is really needed.
• 2. Managing a multi-year software development project is tough enough when you're the one building it. It is many times more difficult to try and look over a contractor's shoulder and make sure that they are (a) meeting requirements, (b) meeting schedule, and (c) not wasting (or stealing) money. This is even more difficult when you have thousands of crappy nonsensical or ambiguous requirements (the norm for such large systems).
• 3. Even if you get decent requirements and decent/lucky contract management, you still have huge product and engineering hurdles that don't often show themselves until you get the software in the hands of real users. And (more often as not) find out that it doesn't work for them.

I've only ever seen one model work successfully (in my time in the USAF and as a contractor):

• 1. Put organic (e.g., military or civil service, not contractor) resources in charge of the system development.
• 2. Don't try to spec and build the system as a whole unit. Instead, start with something small and easily defined and then work *directly* with end users to evolve and enhance the system over multiple years. At some point in the evolution of the system (neither the beginning nor the end), you make the call that the system is functional and stable enough to deploy.
• 3. Use contractors as labor, project-managed by your organic resources. This tends to mean fairly integrated teams (organic and contractor) and a different sort of contract vehicle. It also means that swapping contractors out is actually feasible and doesn't cause the failure of the entire project.

The above system works beautifully. And Congress, contractors, and contracting agencies within the military hate it. Which is probably why it isn't done more often.

Re:Typical government efficiency...

[Antique Geekmeister]

I've been technical lead and technical contributor on numerous such projects, it's an absolutely core part of my work. And it is incredibly difficult in large environments, where numerous groups have evolved distinct usage and workflows and are often very resistant to change. Coupled with the amount of money being managed in this project, and the military and security requirements, such a project is well beyond the capabilities of any group I've ever met.

Trust is not a sufficient factor, I'm afraid. Competence, and communications among the groups, is critical. That requires corporate buyin, and ledership and technical and business acumen that are extremely rare and will not be found by a "lowest bid" process.

Re:Typical government efficiency...

[Anonymous Coward]

Pretty sure that comparing current peace-time* defense spending to World War II defense spending is like saying it is colder in January than it was in July.

* https://en.wikipedia.org/wiki/Declaration_of_war_by_the_United_States - See, peace-time, we have officially been at peace since WWII.

Re:Typical government efficiency...

[mrmeval]

Our government is the most expensive in the world. Do not make the mistake of separating the military from government. The waste inherent in it is a symptom not of the military but excessive government.

Re:Typical government efficiency...

[cold fjord]

Then you don't understand the situation. The US is at war with the perpetrators of 9/11. Congress passed the Authorization for Use of Military Force in 2001. It is well settled law that such authorizations are legally equivalent to a declaration of war. You may not like that, but that doesn't change the legal situation.

How many times to we have to revisit this issue?

Re:Typical government efficiency...

[Macgrrl]

Your math is off. The $1B was for a replacement system which failed to deploy, the 7M lines of code were probably written for well less than $1B. There is a high probability that the new system had a smaller number of lines of code - therefore a higher cost per line.

Re:Typical government efficiency...

[fredprado]

Please, don't compare fictitious "wars" with the real thing. It is beyond silly.

Re:Typical government efficiency...

[budgenator]

COBOL is a high-level language that had the first compilers in 1960 running essentially the same program on both RCA and UNIVAC computers. Usualy some changes may have to be made in the CONFIGURATION SECTION. but other than that the compiler and the Operating system takes care of it. The problems I'd imagine happening is some of it is written in pre-ANSI COBOL 68, most in ANSI COBOL 68, a fair amount in COBOL 1974 and a smattering of COBOL 1985; so a lot can depend on how strict the compiler is. I imagine every time Congress changes the tax code, the military gets a pay raise or contributory entitlement change; some COBOL programers develope PTSD and the program gets an orphaned module or two. After several decade on maintence and changes it probably a nightmare figuring out what gets used and whats never called.

Re:Typical government efficiency...

[cold fjord]

I see you are a fan of pulp quality fiction. Well, I can provide you with a general guide to help separate fiction from reality when it comes to war, we'll leave your other fiction for another time. Real war tends to fill these things. There have been thousands of them filled since it started. Many of them are being filled due to bombs, bullets, and rockets used by the enemy to kill American and allied service members. That is a pretty reliable way to separate "fictitious wars" from real wars. Another strong indicator is the use of 500 pound and 2,000 pound bombs being dropped on the enemy to kill them. That also doesn't happen in "fictitious wars." The war against al Qaida is real. Anything you are reading that calls it fiction is fiction or lies itself.

Re:Typical government efficiency...

[fnj]

It's not all waste. Bloat, corruption, greed and fraud are the most serious contributors to the expense of the government. Most of your tax dollars are lining the pockets of legislators and their staff, executives and their staff, courts and their staff, agency bureacracies, tax collectors and enforcers, vast networks of "authorities" accountable to no one, public worker union management, contractor management, contractor shareholders, lobbyists, assorted fat pigs who hire lobbyists to get their own pockets lined, and finally, yes, public union employees.

Re:Typical government efficiency...

[Anonymous Coward]

Entitlement spending was 61.9%, and defense spending was 18.7% (~ $677 billion).

False statistics alert. There is an awful lot of defense spending outside of the defense budget.
For example, 140 billion on Veterans, 15 billion on foreign military aid, the NNSA (the guys which
maintain the nuclear arsenal) is part of the Department of Energy, etc.

Actual US military spending is approximately 900 to 950 billion/year.

Re: Typical government efficiency...

[Anonymous Coward]

You sound like a bullshit artist.

Re:Typical government efficiency...

[dcollins]

Comparing the world-beating Nazi military & engineering structure to some guys in caves who arguably aren't even an actual organization is lunacy.

But fine, let's use your "real war" coffins as a metric. U.S. military deaths in WWII: 416,800. U.S. military deaths in Iraq & Afghanistan combined: 4,409+2,200 = 6,609 (source: Wikipedia). Using the military GDP numbers from upthread, we have GDP-Percent-Per-Coffin values:

WWII -- 38/416800 = 0.00009
Post 9/11 -- 4.5/6609 = 0.00068

So by your "real war" measure, the GDP-Percent-Per-Coffin expenditure has risen over 7-fold since WWII. The post-9/11 military situation is like about 1/60th as significant as WWII by the coffins metric, and your equating of the two is comically outlandish.

Re:Typical government efficiency...

[dcollins]

Sorry, I was too generous. I see elsewhere I shouldn't have trusted the 4-5% number; it's actually over 18%, so multiply by 4. The GDP-Percent-Per-Coffin expense has increased by over 28 times WWII values.

Re:Typical government efficiency...

[fredprado]

Sorry, but car accidents generate an order of magnitude more coffins per year than the "war against terror" in which you choose to believe. By any definition it is silly to define this farce as a war, including by your own.

Re:Typical government efficiency...

[cold fjord]

Comparing random accidents with willful human planned violence is a farce. If you want to do that, they why not stop all law enforcement except drunk driving and cut the speed limit by 30%? It would drive the death rate down, and you seem to think that is the only measure that counts, right? You are quite uninformed if you believe that every war must be a large effort straining the resources of the nation. A low level war like the one against al Qaida is hardly a strain, but it still consumes lives. There are still acts of planned violence abroad, and many arrests and convictions domestically . There is no question of existence, the war against al Qaida exists independent of your whimsy. There is an act of Congress, expended munitions, and filled coffins to prove it. To deny it is an act of fantasy.

Re:Typical government efficiency...

[fredprado]

It is a very reasonable comparison when you decide to be very very silly and define what a war is by the number of coffins, my friend. Our discussion is about resources, and this "low level war" which isn't a war at all costs less in resources and lives than traffic accidents. There is no question about what you call "war"against terrorism not being a war at all, no matter how much you delude yourself.

Re:Typical government efficiency...

[cold fjord]

You've engaged in a pointless exercise. All you've done is demonstrate something that is already known - the two conflicts involve different levels of effort for the US. From the US perspective the war against al Qaida is on the level of limited war - Low Intensity Conflict - Counterinsurgency - Counterterrorism, but it is still a war. It isn't comical, it still produces dead people. If this is all new to you, it's unfortunate that you are so uninformed, but that doesn't alter the facts.

Re: Typical government efficiency...

[Anonymous Coward]

you're basically on a unique version of the new system that only certain programmers really understand.

I think i see the problem.

Re:Typical government efficiency...

[fredprado]

It is comical, because the likelihood of being killed in a terrorist attack, which generated this witch hunt you have the indecency of calling a "war", is orders of magnitude lower than the likelihood of being killed car accidents, heart attacks or even of being shot accidentally by a cop. Still the misused term "war" is used by you and by our dear politicians to justify ridiculous expenses with defense, absurd restrictions of personal freedoms as in no-fly lists and other abuses.

Using the US military forces to hunt terrorist groups is not a war at all, just a tremendous waste of resources in a futile game of Whac-A-Mole.

Re:Typical government efficiency...

[AHuxley]

Yes fred it is getting 1984 "We've always been at war with Eastasia" silly :)
A database of skilled individuals to take on the Soviets in Afghanistan.
A database of skilled individuals to take on Serbia in what was left of ~Yugoslavia.
A database of skilled individuals to take on Russia in ~Chechnya.
A database of skilled individuals to take on Iran via covert actions.
Then you have evil doers in Iraq, Afghanistan...great for contractors and a few political/mil careers.
Who in a few years become democratic freedom fighters in Libya, Syria.
All needing black budgets, arms, banking support for drug sales and other expert help.
Funny how people get so lost in the Iraq, Afghanistan aspect. Syria is where the freedom fighter cash is now :)
Cobol seems to be doing its job just fine, all the freedom fighters seem to be getting their funds as always.

Re:Typical government efficiency...

[bored]

You are quoting the heritage foundation, which has a specific agenda. If you don't know what it is then that is your problem.

How about I quote the war resisters league, where they claim 47% of the government spending is military related.

The difference between the two numbers is, what one considers military spending, and what considers government spending in general. For example, is the NSA's gigantic surveillance military spending (it is after all part of the "defense department")? How about the pension program for veterans?

A rational mind would say they both are part of the military, the second is simply part of the benefits program we give to our soldiers who risk their lives. A built in cost because at some point, someone said it was a damn good idea to take care of soldiers when they come home lest they become the troops for the next revolution.

So, the truth is probably somewhere in the middle, although aside from the removal of the social security program (which isn't directly part of your income taxes) which I think is a little disingenuous, I think the war resisters league gets it a little more accurate because they count things like the portion of NASA's budget used to launch military devices and similar things.

Re:Typical government efficiency...

[Anonymous Coward]

Sorry, AC to not undo mods.

Nightmare? Maybe, but certainly tedious.
Run a test case, step through.
Automate process to record what gets called.
Run a normal payroll run.
What doesn't get called gets culled.
Write new code.
If someone says they haven't been paid, steal code from leftovers to write him in.
Hmm. So, yeah, a nightmare, but at least there's a way to go about it.

Re:Typical government efficiency...

[cold fjord]

You are trying to pull a fast one. I'm not the one trying to define a war by the number of coffins, you are. You want to deny the fact that there is more than one level of war. You are pretending that the fact that the US is engaged in fighting a limited war instead of a general war or total war means that there is no war at all. You are suggesting that a conflict that generates a number of coffins below that of one of the largest conflicts fought by the US means that there is no war. You are attempting to obscure that Congress has the power to declare war. The Congress has authorized the US to go to war against al Qaida, and the military is fighting it. The US is at war, period. This is a fact, and it is not altered by your disbelief, whimsy, mockery or ridicule.

Re:Typical government efficiency...

[jbohumil]

Amen to this. Automating a system from scratch is much harder than tweaking an existing work flow. It is not at all unusual to see entire departments built around the failures of the automated system. In other words, lets say there is some inefficiency in an implementation. Because it is difficult to get the IT prioritized and modified to address it, another option is to hire someone to fill the gap and do the work that you might have been able to automate, but would require reworking the system. Now try to totally overhaul the work flow from top to bottom when jobs and departments on the line.

Re:Typical government efficiency...

[cold fjord]

The true indecency was the attacks against innocent people by al Qaida - they killed and wounded thousands of people before the US became truly committed to fighting them. There is no shame in calling the war what it is. It isn't a witch hunt. There have been hundreds of arrests and convictions for terrorism related offenses in the US. There have been thousands and thousands of terrorists killed or captured abroad. The reason the day to day threat to American lives appears to be low is due to the effectiveness of the military, intelligence, and police efforts. Don't kid yourself - al Qaida and its affiliates were responsible for killing tens of thousands of people in Iraq, and many more around the world. They would do it in the US if they could figure out how. And do note that there are al Qaida affiliated groups fighting in Syria. Both the rebels and the Syrian government have used chemical weapons. If al Qaida manages to get their hands on those and smuggles them out of Syria, they might very well try to use them in the US. That could easily kill hundreds, or thousands of people in a single attack.

Re:Typical government efficiency...

[jbohumil]

You totally get it. It takes strong leadership to tell the business units that they must conform their procedures to the new system and it will be installed as is. That is the way to succeed. Then once it's in you can start opening it up.

Re:Typical government efficiency...

[Cramer]

The entire problem here is the people writing the checks are ".gov". Government contractors are there to cash checks first, if there's time left over, they may give you something useful. (It usually falls to sub or sub-sub contractors to get to where any real work is done.)

The sad thing is, anyone in the payroll office could walk to their local Office Max, and there on the shelf (for mac or windows) find software that can do much more than the 60 year old COBOL system they've been using. For a few $$$ even. The real work comes from getting all the records from the old system into the new system.

(been there, project abandoned instead of handling the conflicts in merging systems)

Re:Typical government efficiency...

[AF_Cheddar_Head]

Yep, and in the military no one seems to have the balls to make the user learn and use the new shiny. Speaking from experience, the AF in my username stands for Air Force

Re:Typical government efficiency...

[fredprado]

The true indecency was the attacks against innocent people by al Qaida.

Terrorism is indeed indecent and a huge waste of lives, but that does not justify inflicting considerably more damage to US citizens than the trouble one intends to prevent could possibly provoke, even because attempts to suppress terrorism by blunt force are utterly ineffective. Either way these attempts at suppression cannot by any stretch of logic be called a war.

The reason the day to day threat to American lives appears to be low.

You do know that terrorism existed long before 9/11, don't you? And weirdly US was doing just right and the threat was exactly as small without sending armed interventions to the Middle East, without arresting people without warranties, without preventing people from flying without motive, without violating human rights at will and other absurd actions like these. If you think the threat of terrorism is this low because any hugely disproportional effort is being made to prevent what is not there you are a fool, a big damn fool.

Sorry, but your delusions about the magnitude of the threat and the effectivity of US military efforts to prevent it are severely removed from reality. Leaving the Middle East alone would probably minimize the threat far more than any effort the armed forces can make in this direction, considering most terrorist supportive leaders were placed in power directly or indirectly by CIA meddling in this region.

Re:Typical government efficiency...

[nbauman]

I'd rather get my data from somebody more objective and without the political agenda of the Heritage Foundation.

I used to get the Statistical Abstract of the United States every year but our federal budget-cutters stopped publishing it.

(I don't know if this applies to the Heritage Foundation specifically, but I've seen people in the Wall Street Journal claim that payroll taxes aren't taxes, therefore half the population is moochers who don't pay taxes.)

Re:Typical government efficiency...

[nbauman]

The government creates a lot of the GDP.

If Commonwealth Edison is contributing to the GDP, why isn't the Tennessee Valley Authority?

The government It creates federal highways, and a lot of bridges and infrastructure. There are federal hospitals. When the VA hospital gives you a hip replacement so that you can get out of a wheelchair, that contributes to the GDP. There are government-run power plants which are just as efficient as any private power plants. When the FDA inspects a pharmaceutical plant so we don't get another outbreak of contaminated drugs, that contributes to the GDP. The federal government is investigating that air crash. Doesn't accident investigation contribute to the GDP?

Re: Typical government efficiency...

[Mabhatter]

There is no "off the shelf" product that is going to handle payments to Civil War survivors and the 160 years of federal laws passed since then for paying soldiers/survivors their wages in every war since.

Re: Typical government efficiency...

[Mabhatter]

GDP is a good way to gage what is a "fair" amount if taxes to be takin from the system when comparing countries. Our federal budgets are huge, but when taken versus GDP of other countries they are not out of line because our GDP is so much bigger. Consider it "management fees" based on a percentage of the assets managed. For society to function properly the percentage comes out pretty close for most first world countries... And the US shifts to the bottom of the list and spends more of its money on prisons and guns than anybody else ... Like 10:1.

Re: Typical government efficiency...

[Cramer]

Bullshit. At the simplest, one need know only who to pay, how much, and how often. Information any accounting package can handle with ease. The problem is not finding a system -- tho they'll happily burn through millions over many years "looking at options"; the problem is getting from the old system to the new system, without making an even bigger mess.

There are private firms with more complex payroll systems than the US Military. Yet, they aren't running century old software on systems no one understands. It's not cost them billions totaled over the entire life of the company. EDS and ADP run payroll for *THOUSANDS* of companies, and they turn a huge profit on it.

Re:Typical government efficiency...

[gweihir]

Given that I have heard a number of 1 LOC per developer per day when McKinsey rewrites Code, I think that is very, very cheap.

Re: Typical government efficiency...

[peragrin]

The problem is GDP doesn't reflect government income in any way shape or form.

even in a pure Communist society the GDP will never equal 100% of government income.

What is needed is GTR Government Tax Revenue. That way we can compare how much money is going into and out of the government.

Re:Typical government efficiency...

[Anonymous Coward]

yes... the number is:

13 trillion GDP
677b defence spending

=~5%

Re:Typical government efficiency...

[Anonymous Coward]

Interesting how the figures you provide (and the data in the links) do not match at all those provided here, which are also based on government data (see footnote links to excel documents of the White House).

I guess it always depends on how you look at it...

Re: Typical government efficiency...

[Anonymous Coward]

Have you ever had to make sure that your financial routines could handle transactions in the BILLIONS? If not, STFU. DoD is probably the second-largest, second-most most complex organization in the world (behind the PLA); believe me, their payroll requirements (and auditing requirements) cannot be handled by COTS software.

Re:Typical government efficiency...

[DarkOx]

Fine congress how the power to declare "war", just like they have the power to make other laws that do things like declare a pressure cooker with some explosives is a Weapon of Mass Destruction. Words have meanings independent of how congress abuses them.

Our society needs to stop letting people have it both ways. If a pressure cooker with some explosives not powerful enough to bring down a structure is a WMD, than what the military is firing from the drones every day are WMDs, and Iraq was full of WMDs before the invasion and after, and still is. Wars are organized conflicts between nation states. What we are doing about Al Qaida is not a war. Its a police action, no matter what anybody in Washington trys to call it.

Now Libya that was a war. That was us flying planes and dropping bombs on the oranaized air defenses of another nation state. What does our president call it, "A Kinetic Military Action", more bullshit.

We need to call a spade a spade so that our laws and contracts can have meaning. I am sick of all the BS

Re:Typical government efficiency...

[khallow]

No, his fundamental point remains. The original comparison was terrible because one would expect the US to spend less now on the military than in the Second World War precisely due to the degree of effort.

As to your yacking about a US "declared" or "authorized" war on al Qaida, what is al Qaida? At least the Taliban is a definable enemy.

Re:Typical government efficiency...

[khallow]

For example, 140 billion on Veterans

That is entitlement spending which is also inflated by the numerous poor US policies inflating health care costs.

Actual US military spending is approximately 900 to 950 billion/year.

You speak of "false statistics", but all you were able to do was come up with was at best an aditional 7% of the US budget for the US military - more than half of which is itself entitlement spending. It still remains that entitlement spending is more than double military spending by your measure.

Re:Typical government efficiency...

[Lord Lemur]

Your right, in many situations genocide would have solved their domestic issues for them.

Re:Typical government efficiency...

[khallow]

A rational mind would say they both are part of the military

No, that isn't true. The NSA doesn't actually do military activities. And intelligence gathering has considerable application beyond that of military activities.

I note also that the War Resisters' League also discounts Social Security. Those sort of accounting gimmicks have long been discredited. That shrinks the entitlement side of their pie charts.

Re:Typical government efficiency...

[khallow]

If Commonwealth Edison is contributing to the GDP, why isn't the Tennessee Valley Authority?

Well, one obvious reason is that the TVA may actually be destroying economic value. That incidentally wouldn't be going into GDP calculations.

Re:Typical government efficiency...

[intermodal]

Percentagewise, that's still a ridiculous amount of waste.

Re:Typical government efficiency...

[intermodal]

I'm not saying that you're wrong in spirit, but I don't know that in practice there are many other agencies that can get away with the procurement policies that lead to spending hundreds or thousands of dollars on a simple hammer or toilet seat. And that's not even counting the other policies that force their contractors to inflate prices just to comply with policy. Someone once told me about a bad policy that mandated a specific and subpar method for applying a decal which resulted in something like an 80% failure rate for the application of said decal. There's a reason that such situations inflate the charges given to military contracts compared to what anyone else would be charged.

Re:Typical government efficiency...

[NatasRevol]

LOL.

The 2012 military budget is ~$1.25T

https://en.wikipedia.org/wiki/Military_budget_of_the_United_States#Budget_breakdown_for_2012

Re:Typical government efficiency...

[intermodal]

In all likelihood, the old system is primarily suffering from the complexity of many thousands of modifications that make it hard to maintain with current changes needed, as the original coders have (I'm sure) long since retired. The COBOL is not bad in and of itself, but code maintenance in the face of new requirements is probably a pretty big issue.

Re: Typical government efficiency...

[intermodal]

Given the way military contracts work, I think it's largely the government doing it to themselves.

Re:Typical government efficiency...

[cold fjord]

Apparently not enough money is being provided to the literacy programs. What a waste.

Re:Typical government efficiency...

[Anonymous Coward]

This is like saying the cook at the mess hall is not part of the defense budget because he doesn't actually do military activities. The NSA is part of the defense security apparatus and should be counted as such.

Re:Typical government efficiency...

[Anonymous Coward]

It's not just government though. I've seen a corporate inventory system where the conversion from an old system to a new one took a couple decades and due to various things happening while trying to ensure that the new system matched what the old system was before transmitting then correcting any issues, lather, rinse repeat, meant that a 60 car train could travel completely up the east coast of the US before the inventory could be transmitted to the receiving end electronically.......
Interestingly enough I ran a few reports off that system that required going into a terminal session to emulate building a card set to generate the report... WHEEEEEE!!!!!! And that was in the mid '90s and I'd missed out on punch cards in college in the early '80s because "nobody was really using punchcards anymore"

Hah. captcha said "preserve"

Re:Typical government efficiency...

[nbauman]

What evidence do you have that the TVA destroyed economic value (in ways that Commonwealth Edison did not)?

Re:Typical government efficiency...

[khallow]

This is like saying the cook at the mess hall is not part of the defense budget because he doesn't actually do military activities.

Does the cook serve mostly to civilians? if so, then he shouldn't be counted. That's what the NSA does.

Re:Typical government efficiency...

[khallow]

Well, it still exists and it still has a monopoly on power production in much of its service area. It doesn't have to comply with a lot of environmental and worker safety regulations (at the state and local levels), so it can generate externalities that other utilities can't. It has the power of eminent domain, that is, it can legally seize property. And consider this quote (from here):

To the degree that the TVA had any impact, it appears to be negative. The most important study of the effects of the TVA, conducted by energy economist William Chandler, estimated that in the half-century after the TVA was launched, economic growth in the Tennessee Valley increasingly lagged behind non-TVA southern markets. Chandler concluded, "Among the nine states of the southeastern U.S., there has been an inverse relationship between income per capita and the extent to which the state was served by the TVA...Watershed counties in the seven TVA states, moreover, are poorer than the non-TVA counties in these states."

In the non-TVA southern markets, there was a greater exodus of people out of subsistence farming into manufacturing and services, which offered higher incomes. Ironically, electricity consumption has grown faster in the non-TVA southern markets, because it tends to correlate with income. Subsistence farmers might be able to afford light bulbs, but they could not afford the electrical appliances that people in non-TVA southern markets were buying. Furthermore, despite the vast sums spent building TVA dams, water usage grew faster in the non-TVA southern markets.

Places served by TVA did worse than those in the same states which weren't served by the TVA.

Re:Typical government efficiency...

[nbauman]

I would look for a more objective source of information than Reason. After all, if one of their writers researched a story and it turned out that the government was actually doing a good job, they wouldn't print it, would they?

I'll look for something in Science magazine. I don't get Nucleonics Week, Nucleonics and Electrical World any more, and I don't talk to people in the energy industry any more. I'll take this article in Reason under advisement if I ever return to the subject.

When I asked people in the industry to name the best-run nuclear power plants in the U.S., they named the TVA (and Commonwealth Edison Chicago). There are standard metrics, particularly down time, for nuclear power plants and conventional plants, so you can judge them with reasonable objectivity.

I'll have to disagree with Ralph Nader on this one.

Re: Typical government efficiency...

[Hognoxious]

At the simplest, one need know only who to pay, how much, and how often.

Well said.

Likewise, to fly a 747 one need only push and pull the stick a bit, to perform a heart transplant one need only know what to cut and what to stitch, and to cure cancer one need only know what atoms to stick together.

Re:Typical government efficiency...

[Hognoxious]

Where does that definition say anything about Government income(taxes)?

Where does he claim it does?

GDP is crude measure of how rich a country is, and stating a country's expenditure on X as a percentage of it says something about its policies and priorities. It's also more informative than a straight amount as countries' costs vary somewhat.

Re:Typical government efficiency...

[khallow]

When I asked people in the industry to name the best-run nuclear power plants in the U.S., they named the TVA (and Commonwealth Edison Chicago). There are standard metrics, particularly down time, for nuclear power plants and conventional plants, so you can judge them with reasonable objectivity.

You mean like the Bellefonte nuclear plant? $6 billion dollars sunk cost and the TVA gave up on it until recently.

Re: Typical government efficiency...

[Hognoxious]

The problem is GDP doesn't reflect government income in any way shape or form.

It's not a problem because nobody said it does, apart from you and the other idiot I replied to above.

GDP is the cake (and this is not a lie). It says nothing about how it's sliced.

Re:Typical government efficiency...

[Anonymous Coward]

If we do that they'll think we're a bunch of woofters. They all hate us, because they're godless communists.

Re:Typical government efficiency...

[nbauman]

There was a lot of enthusiasm for nuclear power construction in the 1970s, in private and government facilities. After Three Mile Island and Chernobyl, it became much more difficult to build plants, private or public.

Cherry-picked facts aren't too useful.

Re:Typical government efficiency...

[Anonymous Coward]

Bingo! Which points to the deeper problem, which is that strong personalities are doomed to pain and misery in government bureaucracies (any bureaucracy?), because everyone is so habituated to covering their own and their friends butts that anyone who comes along and starts calling a spade a spade is an object of terror for them. But only honest people can build good systems.

Re:Typical government efficiency...

[tom arnall]

Bingo! Which points to the deeper problem, which is that strong personalities are doomed to pain and misery in government bureaucracies (any bureaucracy?), because everyone is so habituated to covering their own and their friends butts that anyone who comes along and starts calling a spade a spade is an object of terror for them. But only honest people can build good systems. I totally agree that heuristic development is the only way that any good and long-lived tool has every been built. MY QUESTION: why do you think that congress and the contracting folk hate the method? The main problem which I have encountered in its application is that users think they already know what they need, and the idea of a procedure which implies that they don't pisses them off. "We don't need a damn programmer telling us how to do our work!" and the like. If ever I decide to go back to doing systems, my first move will be to write a piece which lays out how I do my work and which makes clear that if you don't like it you will have to find yr help elsewhere. Looking back on thirty years of work in the industry, the only thing I regret is that I compromised on this. "Wait yr pitch!" How true, in play and in work. The great irony of the situation is that for the first time in human history, it is easy to keep remaking our tools. How long will it take before the suits get that one?

Re:Typical government efficiency...

[tom arnall]

you seem not to understand that we're talking about a method of software development. ignore it and your project dies, whatever excuses you choose to make for yourself.

Re:Typical government efficiency...

[khallow]

Cherry-picked facts aren't too useful.

There aren't that many nuclear plants owned by TVA. You were heralding the allegedly remarkable competency of the TVA with respect to nuclear plants. Where does that appear in the construction of the two nuclear reactors of the Bellefonte plant, both which were well over halfway completed (88% and 58% complete)? It doesn't.

A valid counterexample to a claim is a legitimate cherry-picked fact.

Re:Typical government efficiency...

[nbauman]

I'm saying that the government does create GDP. If you look at a Leontief input/output matrix, which summarizes the entire economy by sector, there is a sector for the contribution of government services.

One example is the TVA. The TVA is definitely generating electricity, much of it through hydropower and some of it through nuclear power.

Whatever TVA's efficiency is, and whatever their wisdom in ordering new nuclear plants, when they generate electric power, they're definitely contributing to the GDP. During WWII, they were manufacturing aluminum, which was a critically-needed weapons component.

You may be able to come up with an economist who believes the government is inherently inefficient, who can create an argument that the economy would have grown faster if the TVA had never been built. That's definitely a contrarian view. If I saw that argument in a less ideological publication, like Science, I would take it seriously. The Wall Street Journal news section used to cover the electric power generating industry, and I don't remember them saying anything like that.

But right now the TVA is generating electricity and contributing to the GDP.

Re:Typical government efficiency...

[khallow]

Whatever TVA's efficiency is, and whatever their wisdom in ordering new nuclear plants, when they generate electric power, they're definitely contributing to the GDP.

No, because there are costs associated with those services. Those also have to taken into account.

Re:Typical government efficiency...

[Anonymous Coward]

What a bold statement to make, especially when even the most cursory of Google searches and even the official numbers from the US government proves you very, very, VERY Wrong.

Re:Typical government efficiency...

[Anonymous Coward]

People would take you much more seriously if you didn't parrot your data directly from a known-to-not-be-trustworthy source that has been shown to lie about published numbers on a regular basis.

Re:Typical government efficiency...

[nbauman]

You're just assuming that the costs associated with those services are greater than the power they generate.

The only evidence you have to support that is a study by a contrarian economist whose views are not widely accepted.

It's interesting to be a conservative economist. You start out by saying, "Assume the government is less efficient than private enterprise. Now go out and find some facts to prove it."

I would start out by saying, "Is the government more efficient, less efficient or as efficient as private enterprise? What are the facts?"

Re:Typical government efficiency...

[khallow]

You're just assuming that the costs associated with those services are greater than the power they generate.

I don't know really, but TVA apparently is losing money (compensated for by taxpayer money). That when combined with the somewhat increased externalities it enjoys indicates possible negative GDP.

I would start out by saying, "Is the government more efficient, less efficient or as efficient as private enterprise? What are the facts?"

Then when you're given multiple examples of the inefficiency of government you would conclude what? That you even are talking about this as a question seems to indicate to me that you are already ignoring facts.

For example, I have some experience with aerospace related R&D with respect to the US. My experience has been that US government funded R&D is so inefficient that you start estimating government costs by increasing the private equivalent by an order of magnitude. It's that bad IMHO. European and Japanese govermment aerospace isn't quite as bad, but I'd still start with considerable cost multipliers.

Similar cost multipliers seem to hold for construction projects and IT infrastructure. For example, there was a failed billion dollar IT project that was intended to provide various logistics and payroll support for the entire US armed forces. In the private world, that could have gotten you a lot more than just a payroll system.

About the only thing that government seems really efficient at is signing checks. And there, I think it's because they don't really care who cashes them, as long as someone does.

So how does this inefficiency manifest? One way is ridiculously difficult and changing specifications. Such things provide plenty of opportunity for corruption since the contractor has some degree of influence over the specifications (either through legal contributions to the specs or bribing the government side into changing the specs). The more often this stuff changes, the more money they can milk from the contract without appearing to default on things.

Second, is the prevalence of "cost plus" contracts for many government services. These are particularly open to abuse since they allow politicians to tout the smaller base number rather than the base + cost number which is usually the actual cost. It also provides considerable incentive to the contractor to not actually complete the job (in hopes that more money is tossed on the contract).

Very few bureaucrats in the developed world have any real accountability. They're mostly invisible unless a particularly scandal happens to unearth them. And there are dynamics like regulatory capture that can suborn the bureaucracies in favor of those with money.

Ultimately, there's no real incentive to be efficient or accountable. There's no profit motive. Few care whether you even get in an order of magnitude of an efficient solution. And modern governments are so large and opaque that it's easy to hide mistakes and misdoings. For me, hypothesizing an efficient government is like hypothesizing a talking dog. It's pretty mythical, but it could happen at some point to someone.

Re:Typical government efficiency...

[jwhitener]

The size of our armed forces is not a response to threats around the world. It is more a jobs and contract program for the various districts of congress.

ca hit something like this

[Joe_Dragon]

http://articles.latimes.com/2012/dec/21/local/la-me-state-computers-20121222

Everyone's pay get screwed up

[alen]

Army in the 90's
Everyone's pay gets screwed up at least once, then. Uncle Sam takes it back

Mostly minor things like an allowance like jump pay being paid while not on jump status

Re:Everyone's pay get screwed up

[budgenator]

Army in the 70's, advance pay between basic and AIT, resulting in 3 months without a pay check and another 3 months for all of the corrections, re-corrections and over-corrections to stablize.

Re:Everyone's pay get screwed up

[Anonymous Coward]

Lol, it still was happening when I got out in 2011, and I talked to a soldier in 2012, when it happened to him.

Re:Everyone's pay get screwed up

[droptone]

Coming from friends in the Army, that's still happening regularly. My good friend is currently dealing with being incorrectly docked jump pay.

Re:Everyone's pay get screwed up

[Anonymous Coward]

Not just over-payments. When I transitioned from AIT to Fort Bragg in 2000, my paycheck didn't transition with me. Four months of nothing. Not even No Pay Due statements, just nothing. But that fifth month I got an LES with 5 digits in it...

Corruption

[Anonymous Coward]

the Pentagon spent a billion dollars and wasn't successful

Sounds like corruption. If you can't wrangle up a team of coders and project managers with a billion dollar carrot, then there is something terribly internally wrong with your process.

Re:Corruption

[Anonymous Coward]

Come on up to Quebec, we can teach the world a thing or two about corruption and billion dollar software boondoggles.

Re:Corruption

[Anonymous Coward]

The problem is that with a billion dollar carrot, you wrangle up 1000 coders and 2000 management level personnel for a 10 year hitch. Then you pair this unwieldy development juggernaut with government security requirements and design guides that are poorly defined and change weekly and you see how a billion dollars can fail to do what 5 million could.

Let me have a go at it....

[Anonymous Coward]

Give me a billion dollars and I am sure I could hire (and be part of) a team that can do more than just port old code.

Re:Let me have a go at it....

[CrzyP]

Give me a billion dollars and I can learn the process, learn TO code, code it, test it, and implement and support it myself.

Re:Let me have a go at it....

[youngatheart]

Give me a billion dollars.

What, you want more? If you give me a billion dollars I will take it and make a very convinicing show of working hard to deliver whatever you want while I build up my "disappear and retire accounts" with only a small percentage of the money.

Silver Lining

[Anonymous Coward]

Hopefully the soldiers will be on our side in the forthcoming revolution.

Re:Silver Lining

[ebno-10db]

Hopefully the soldiers will be on our side in the forthcoming revolution.

Funny you should mention that. Pay in arrears is much of what fomented the Newburgh Conspiracy, and this time we don't have a George Washington to defuse the situation.

Re:Silver Lining

[cold fjord]

We also don't have a Congress organized under the Articles of Confederation and lacking meaningful authority to levy taxes to cause such a situation.

How did the military pay during WW2?

[Spy Handler]

They had way more soldiers back then today, and payroll did not seem to be a problem. Maybe the Pentagon should go back to using whatever system they had back then.

Re:How did the military pay during WW2?

[Anonymous Coward]

Higher taxes. But that is evil toward muh gold, therefore evil toward muh freedoms.

Re:How did the military pay during WW2?

[Anonymous Coward]

They had way more soldiers back then today, and payroll did not seem to be a problem. Maybe the Pentagon should go back to using whatever system they had back then.

Maybe they should hire someone who's not retarded, one billion fucking dollars of tax money and can't make payroll software. A fucking middle schooler could make it for free using excel.

Re: How did the military pay during WW2?

[alen]

Ww2 they didn't have all the allowances they have today. That's where the screw ups come in. Not base pay

Re:How did the military pay during WW2?

[Princeofcups]

They had way more soldiers back then today, and payroll did not seem to be a problem. Maybe the Pentagon should go back to using whatever system they had back then.

A ton of staff, all drawing paychecks. Back then employees were assets. Now they are expenses to be avoided.

Re:How did the military pay during WW2?

[unamanic]

So you think it would be better for us to line everyone up on payday and hand out stacks of cash (like they did in World War 2)? What could possibly go wrong? As someone who is serving and has server for the last 15 years, I can tell you the only times my pay has been screwed up it has been my fault. This is true for everyone of my troops who has had over/under payment issues. Usually it's because a form did not get turned in that starts or stops an allowance, then the member does not notice the discrepancy for some time. The guy in this article was the exception and apparently has shitty leadership. His First Sergeant or Commander should have been able to get this sorted in under a month, or at least get the "overpayment" collected over a year or two so it didn't effect him while they tracked down the source of the error.

Re:How did the military pay during WW2?

[Darinbob]

Hard tack and a ration of rum?

Re:How did the military pay during WW2?

[Anonymous Coward]

They payed them after the war. Much cheaper.

Re:How did the military pay during WW2?

[Darinbob]

Not true. Payroll software is amazingly complicated. And every year all the laws change so that you have to update it. It's constantly in flux. Federal, state, county, and sometimes even city laws to cover all the employees you have, plus of course foreign laws if you want to incorporate that into a single payroll department. That's why most places outsource this stuff. It's a huge expense to do it yourself and economies of scale make sense to have entire companies devoted to just that one job.

Re:How did the military pay during WW2?

[Anonymous Coward]

None of those things matter to military payroll systems as very few rules and complications apply relative to any random civilian.

Re:How did the military pay during WW2?

[Mr. McGibby]

That's why most places outsource this stuff. It's a huge expense to do it yourself and economies of scale make sense to have entire companies devoted to just that one job.

Maybe the Pentagon should outsource to them then.

Re:How did the military pay during WW2?

[Anonymous Coward]

They didn't have the necessary software to blame for not paying soldiers. I'm only halfway joking...if the out-dated system were double paying soldiers, it would have been fixed by now. But since soldiers are the ones feeling the pain, the urgency is less and the replacements end up being boondoggle failures.

Re:How did the military pay during WW2?

[ducomputergeek]

My dad was in charge of Payroll at Ft. Hood during the late 1960's while he was drafted. (he was a private with BA in Accounting and ran the department because the LT screwed up the Col's pay one too many times). They figured pay vouchers a lot by hand, but processed even back then via a Mainframe, usually at night. Then they would dispense the pay in cash those days. It was a nightmare even back then, often times requiring a lot of manual calculations.

Re: How did the military pay during WW2?

[jfdavis668]

The used 100 to 1000 times as many people. Working in un-air conditioned building doing routine work over and over. Then it was all double and triple checked. When they screwed up, you could yell at them. There is no way we could afford to recreate that system with today's pay scales. Also, these were sharp people. No one like that would even apply for the job. Welcome to the post industrial society.

Re:How did the military pay during WW2?

[Anonymous Coward]

of course they do, a soldier is a resident of a state, and in the military, that may not even be the state that they are based at.

I can see this costing a billion dollars quite easily, and it isn't that difficult to fathom it if you have ever worked on legacy systems (the person that posted above that stated he/she had 16 years of experience writing enterprise systems, and therefore could do this with just 12 people, if that is true, they have NEVER worked on a legacy system).

The problem here ISN'T the payroll, which they could probably actually buy off the shelf from one of the ERP vendors, and are generally very flexible rules based payroll systems.

The problem here is all of the other systems that are either upstream or downstream of the payroll system, and this necessitates a big bang approach (replace the entire system). As part of that, the development team will need to essentially rebuild the entire process into the payroll system. Considering that the military more than likely has many payroll systems, not just one (they have hundreds of accounting systems, which is at the root of the 'missing money' problem), so it isn't just a matter of replacing just one payroll system, but them all.

Without looking into it further though, it would be difficult to state with absolute certainty, but spending a billion (the success or failure is not relevant, money isn't unspent because a project fails) isn't out of the realm of impossibility. Now integrating thousands of systems into a few 'cloud' or 'data center' based applications is probably a longer term way to go, but that is definitely going to cost billions, and very little of it would be off the shelf, as the military DOES have unique needs.

Re:How did the military pay during WW2?

[ebno-10db]

Wrong navy, but ask the British how they handle their payroll.

Re:How did the military pay during WW2?

[tqk]

Higher taxes. But that is evil toward muh gold, therefore evil toward muh freedoms.

No, you idiot. Warbonds and "deficit spending", or "cooking the books" as it was known back then. Those guys who raised the flag on Iwo Jima spent the rest of the war begging for war bonds sales.

Re:How did the military pay during WW2?

[fnj]

They had way more soldiers back then today, and payroll did not seem to be a problem. Maybe the Pentagon should go back to using whatever system they had back then.

What the army used then, I believe you will find, was cheap uncomplaining labor (bitching is not really balking), much of it conscripted, something which has been so far gone for so long now that it is difficult to even imagine (outside of taking merciless advantage of undocumented immigrants).

The army peaked at 8.3 million in 1945, on a population of 140 million. The number of those actually fighting at any given time were much, much smaller. The others were hauling supplies, building bridges, digging latrines, doing KP, staff work, and yes, handling payroll. It worked because pay was almost nothing. Following figures are for 1942. A private with less than three years service was paid 50 bucks a month. Tech sergeant with 5 years, $120. Captain with over 10 years, $230. General with over 30 years, $667.

Yeah, median household income in 1945 was only $2400, but a private with a pay of $600 was a hell of a lot cheaper than a business worker even after adding the expense of housing, clothing, and feeding the private.

Re:How did the military pay during WW2?

[Anonymous Coward]

Administaff can hire all the military folks who will no longer work for the US Government. Brilliant!

it's the old data and all the linked systems

[Joe_Dragon]

it's the old data and all the linked systems and with 40 year old systems just importing data is not easy.

And even if are able to import that can be loads of work around / place holder names / fake names (uses for workarounds or even temp holding of data) and so on.

Some stores do use names like MR cash for cash sales so there may all kinds of fake names in the system as well.

Re:it's the old data and all the linked systems

[Anonymous Coward]

I am not debating the complexity of the project but it is nowhere near impossible.

They would only need a tightly-knit all-star team of 12 to pull it off. The problem is government and corporate overhead; management wants the largest cut of the pie. All the while, liability is tossed around like it's a hot potato.

Re:it's the old data and all the linked systems

[cheater512]

I do data processing from rubbish sources (people who can't follow specs) every day.

Its a pain yes but not actually that difficult. Everything you just described takes time but it certainly isn't impossible to do.
Import data, find differences, fix mistake and repeat until it is working well.

Re:it's the old data and all the linked systems

[Anonymous Coward]

You don't sound like an experienced programmer.

Re:it's the old data and all the linked systems

[Anonymous Coward]

More experience than the majority of /.ers. I have sixteen years of experience in the industry, six years managing and delivering enterprise-level projects. That's ten years of coding in the trenches, friend.

Re:it's the old data and all the linked systems

[Areyoukiddingme]

You make two mistaken assumptions. One, that the bureaucracy wants the problem fixed and will cooperate. (Neither is true). And two, that the requirements are even possible to gather all in one place, and aren't already self-contradictory. (They haven't been and they are.) Without those two little problems, it doesn't even take a team of all stars. A merely reasonably competent team could do it, especially in the time the failure took. With those problems? No amount of all-stars could pull it off. No software can help an organization that views the software as the enemy, to be fought at every turn.

Re:it's the old data and all the linked systems

[Anonymous Coward]

You're dead on. The issues are internal. I cannot think of anyone, of the brightest and best of us, who would turn down $100 million to make this go within one year. Wheels greased and all.

There is no excuse; the responsibility does not lie in not having capable developers and even project managers. The U.S.A. has a pool of the best and most experienced developers in the world. I have no doubt that there are capable PMs and developers who infinitely exceed my capabilities. I alone have met a handful of them; 3 Americans, 1 German, 1 Swede. They have, however, transcended society. That is the best of the brightest of our hacker and programming friends. They are not in the spotlight, they exists on another plane. They need only to come down to make a few thousand grand.

Along with the Northern Europeans, we American assholes built this. I'm not getting nationalist on you; on the contrary, we are more like brothers. It's what the poets shared; a connection that is global and universal.

There is no excuse. I would do it; we owe it to satisfy our social contract to those who have risked their lives, regardless if the war is initiated on [proven] deceit and against the will of the people.

*respectful hat-tip and a graceful exit*

Re: it's the old data and all the linked systems

[Anonymous Coward]

Lol newbie.

now there are multitude of pay levels.

[Joe_Dragon]

There is basic pay, plus “entitlements” for everything from serving in a combat zone to housing allowances to re-enlistment bonuses. An individual’s pay can change several times in a day.

likely the old software can't deal with all of that to well.

http://www.informationweek.com/government/state-local/outdated-it-blocks-california-payroll-or/225702383

Re:now there are multitude of pay levels.

[OrangeTide]

Sounds like software can't cope with a bad process. Maybe we should throw out the process instead of trying to improve the software?

Re:now there are multitude of pay levels.

[ebno-10db]

There is basic pay, plus “entitlements” for everything from serving in a combat zone to housing allowances to re-enlistment bonuses.

Was it that different in WWII? I don't know the details, but there were definitely things like combat pay. Yet they handled it all with paper (and maybe some punch card machines). As the old line goes "to err is human, but to really screw things up requires a computer".

Re:now there are multitude of pay levels.

[Nerdfest]

They should optimize their process and then rewrite their software to match it, using modern languages with proper decoupling of all the various calculations. Replacing the old system will only be difficult if they base it on the existing software, which is most likely the usual tangles mess of poorly written COBOL. The sad part is that defining the full requirements is actually pretty difficult in itself.

Re:now there are multitude of pay levels.

[nurb432]

Pay changes/enrollments should just be data, not lines of code. Can't imagine even the most green of developer would screw up that bad.

It really does not take 7M lines of code to do this. ( will be a huge database, but not code base )

Re:now there are multitude of pay levels.

[cold fjord]

Comparing computer based pay methods to manual WWII methods is either disingenuous or just plain silly.

Computers screw things up? That is a rare insight you have there. Another way of describing it is trite.

Re:now there are multitude of pay levels.

[youngatheart]

I was thinking pretty much the same thing. The right approach for this is to figure out how to answer these questions:

• Who gets paid?
• When?
• For what?
• How should they be paid? (not how they are paid)
• How do you maintain it?

The questions are simple. The process of answering them is hard. Building the software to handle the result is moderately complex but not nearly as hard as getting the answers.

The question of "how did the old software do it" should be irrevelant and it shouldn't matter that it was written in COBOL or how it worked. Fixing the software is the wrong approach and I suspect a doomed attempt from the beginning. They should have been working on how to build the right system instead.

Re:now there are multitude of pay levels.

[AF_Cheddar_Head]

And when you have it figured out Congress decides to tweak something just for fun.

Re:now there are multitude of pay levels.

[Anonymous Coward]

Soldiers have entitlements? Who do they think they are? Corporate CEOs or something?

Re:now there are multitude of pay levels.

[OrangeTide]

Well once example I'd like to cite on what happens when Congress runs things, is that there are over 70,000 pages in the federal tax code. As far as the President and I can tell, it's mostly loopholes or special exceptions for special interests, which is the same thing in my opinion.

But in this case, I don't think Congress gets to define the details of the pay structure at the Pentagon. So hopefully all the of the complexity in there is due to general beaucractic mismanagement rather than our unsolvablely broken political process.

Outraged!

[Anonymous Coward]

Why the fuck don't they do what any reasonable company does... contract out that stuff to someone who is good at it... like ADP.

As a taxpayer, I am outraged.

Re:Outraged!

[plover]

contract out that stuff to someone who is good at it... like ADP.

They did! That billion dollars wasn't to rewrite it -- that was just to buy and integrate a PeopleSoft package! Supposedly, PeopleSoft is good at that kind of thing, since that's what they sell to other big companies too stupid to write and maintain a simple payroll system.

They don't need to try integrating to someone else's package again, unless they want to shovel another billion dollars into some other undeserving contractor's hands.

Re:Outraged!

[besalope]

Why the fuck don't they do what any reasonable company does... contract out that stuff to someone who is good at it... like ADP.

As a taxpayer, I am outraged.

I really hope that was sarcasm... ADP is one of the most incompetent companies I have ever had the displeasure of working with.

Re:Outraged!

[Anonymous Coward]

PeopleSoft is not ADP. PeopleSoft is Oracle. If you use PeopleSoft, then you're only using ADP to cut checks. ADP also sells competing solutions with varying degrees of success, mostly at the lower end.

But the reason why corporations should just use these solutions is because they're cookie-cutter. When your needs are different than what the stock implementation provides, you end up spending a ton of money on consultation with Oracle, PeopleSoft, ADP, etc. In fact, this is how PeopleSoft and Oracle make most of their money--on consulting time to implement customizations. However, for most medium and some large commercial entities, on balance it mostly works out to just pay for the customization work.

However, if you're the size of the DoD, with the unique requirements of the DoD, then you'd be absolutely stupid to pay any of these people money. You'd be much better off just hiring away their best engineers and consultants. The overlap between what you need and what these products provide out-of-the-box is too small, and the premium on customization is too steep given the customization required. Starting from scratch--but building on the lessons learned--you could build a leaner system that more closely meets your needs, more cheaply.

Re:Outraged!

[Anonymous Coward]

Payroll systems deal with tax laws. Anything dealing with tax laws isn't simple.

Re:Outraged!

[AF_Cheddar_Head]

Except ever since the Reagan era we have to outsource everything. Can't let the military do stuff when we can pay a contractor twice as much to do it.

Re:Outraged!

[Anonymous Coward]

Clearly you have never worked on a payroll system before. If all you are doing is paying flat rates with no overtime then yes, your payroll 'system' will be simple. Start throwing in sliding scales, overtime, incentive bonuses, Tax, unemployment fund, medical aid, garnishing, petrol allowance, per diem, etc. etc. and things get slightly more complicated. 7 millions lines of code is not a 'simple' system, even if it is suffering from software entropy.

Re:Outraged!

[plover]

By simple, I mean it's obvious that seven million lines of code doesn't translate into seven million business rules. Yes, they likely have a couple thousand weird rules and conditions, and "simple" is a gross understatement. But it's not like it's a billion dollars worth of complexity; each rule certainly won't take half a million dollars to understand, explain, and implement. The rest of the problem is keeping it all in a big database, and letting the right people access the right data, and that's something Oracle does very well.

6,500 per soldier???

[Anonymous Coward]

According to an info-box, $17.3 dollars is spent per year on computer systems to manage "finances, payroll, and more," and there are 2.7 million soldiers. "And more" must encompass a whole hell of a lot, because otherwise that's $6,500 per soldier, per year, in pure bureaucracy.

Re:6,500 per soldier???

[Anonymous Coward]

$6500 per year isn't bad for 2.7 million employees. You would spend that every year for just a couple of SAP seats!

Re:6,500 per soldier???

[plover]

that's $6,500 per soldier, per year, in pure bureaucracy.

When you contrast that number to the old $900 toilet seats and $450 hammers, $6,500 for corrupt bureaucracies to maintain their computer systems almost sounds like a bargain.

Re:6,500 per soldier???

[sjames]

That was $6.5K PER EMPLOYEE.

Can't read the article

[Anonymous Coward]

I tried to read the article, but it was written in English - a decades-old language.

Re:Can't read the article

[ebno-10db]

Centuries, but it is being continuously updated.

Re:Can't read the article

[LoRdTAW]

They do have documentation though. Kids are also forced to RTFM while in school. It kinda helps.

Re:Can't read the article

[Anonymous Coward]

Indeed - can I haz won billion cheezedollaz to rerites in lolcateze???

Re:Can't read the article

[clem.dickey]

COBOL too is being updated. It is on its fourth ANSI/ISO standard, most recently in 2002. Compare with ANSI C, still stuck in 1999.

Re:Can't read the article

[clem.dickey]

... and I apologize to C (and Slashdot), there is a C11!.

Re:Can't read the article

[T.E.D.]

The big problem with C11 is that is it no longer "backwards"-compatible with C++, so many will ignore it. For a large number of people "C" is going to remain defined as "the subset of C++ that I can get a C-only compiler to compile".

Re:Can't read the article

[samwichse]

He didn't say _how many_ decades!

By that measure, I'm days old, but already using the computer. Precocious little scamp, ain't I?

Sam

Re:Can't read the article

[Anonymous Coward]

The big problem with C11 is that every single modification to the C standard since C89 has been shortsighted, out of touch with real C implementations, aiming to gain popularity among FORTRAN programmers(all three of them) or just plain stupid.
You know your standards body is crippled when Microsoft gets to decide on C when they haven't ever written a conforming compiler.
As someone who gets to decide which language to use for new projects, I see little reason to abandon the known lesser evil of C89 and then a restricted subset of that. The only feature that isn't a FORTRAN killer or a Microsoft BASIC/C++ hybridization is C threads. C11 doesn't give you portable threading. It gives you
a solution which only works as intended some of the time, given enough cargo cult modifiers, and that will only ever be available in a future GPL 4.0 version of GCC. I'll take duplicated platform dependent code over nonworking shit any day.
C++ doesn't even come into the question. Abandoning a mess for a mess a few orders of magnitude larger is not within my immediate plans.

Quick Books MIL

[xdor]

I wouldn't mind taking this one on. Sure it's already been done, but I'm sure they'd pay to have it done again.

My only stipulation is that I'd want to do it all myself with just one business analyst and one quality control tester.

I think I could manage it in 3 years at 3 million dollars. However I'd probably cause the loss of 10,000 jobs so its probably not going to happen :)

Problem is only partly technological

[Anonymous Coward]

A government payroll is the result of so many laws, regulations, union contracts, executive orders, reorganizations, back room deals, court-ordered adjustments, sacred cows, implied understandings, top officials' nieces and nephews, government shutdowns and budget freezes, that it's impossible for any small army of people to get a mental grasp of what it's supposed to look like and how it's supposed to work.

So you get chaos.

Re:Problem is only partly technological

[Anonymous Coward]

Meh...You've basically just described the prototypical use case for a rules engine. The payroll engine shouldn't have any of this stuff baked in. If you externalize it, congress can change it in response to campaign contributions and you can justify your multi-million dollar maintenance contract in just a few lines of code.

Expecting too much

[whizbang77045]

Aww, come on, fellas and gals: this IS the five sided puzzle palace we're talking about. You're expecting too much of them.

Redundant

[neoshroom]

"seven million lines of Cobol code that hasn't been updated" is redundant.

If they were updated, they wouldn't be in Cobol.

Re:Redundant

[Nerdfest]

Also, seven million lines of COBOL is about what it takes to write a Sudoku solver in COBOL.

Re:Redundant

[jc42]

Yeah; I was thinking that seven million lines of COBOL is what? Maybe 5 lines of perl? 8 lines of python?

Someone was right about COBOL variable names often being all the documentation you need. That may be right, considering that your typical COBOL variable name pretty much qualifies as a line of code all by itself. Of course, most of each name is assorted illegible acronyms and "Hungarian" style attribute indicators that are different for every program, and thus meaningless to anyone other than the original coders.

Re:Redundant

[budgenator]

I thought they was porting it to Ada.

Re:Redundant

[MrCreosote]

I once wrote a COBOL code generator, in COBOL

Re:Redundant

[Duhavid]

I wrote a program for scheduling classes in COBOL once.

It was that, or take basic yet again ( I had had it in high school ).

ADP

[Anonymous Coward]

i'm pretty sure they could just pay ADP to do it like everyone else with tens of thousands of employees.

4.8 LOC per person

[Anonymous Coward]

The code base is so large that its ~4.8 lines per active duty US military person. The code would be shorter if it was nothing but one line per person that prints how much to pay. You might argue that this would have maintenance issues, but automated porting of it would be trivial, and for the $billion they spent try to replace it, you could pay almost $1000 per print statement to keep it updated.

Re:4.8 LOC per person

[PRMan]

Now that is funny. A completely manual system with thousands of employees would be cheaper to run (but MUCH more prone to fraud, of course).

Re:4.8 LOC per person

[Anonymous Coward]

That's a hilarious and incredibly sad way of looking at it.

Deviously convoluted by design

[Anonymous Coward]

Of course any attempt to redo/rewrite it would be a failure, declared so without any contractor ever getting a good look at the complete code. Why... because otherwise all the little electronic fund transfers, loopholes and fake employees would start showing up and I bet that would put an end to someones very lucrative little black book program and god knows what else! I mean what else could be in there? Seven million lines of code sounds like an awful lot even with the diverse nature and considerations of military payroll and the gross incompetence of government contracted work!

Re:Deviously convoluted by design

[ebno-10db]

Never ascribe to conspiracy what can be explained by mere incompetence.

Not to shocked

[Sollord]

The DoD is well known for changing the specs of a project constantly through out the life time of a program so I'm not surprised the update in the 90s failed it probably had 5,000+ changes from it's initial concept and then you add in the required corruption and incompetence needed to be a government employee or contractor and it makes perfect sense it failed.

Re:Not to shocked

[Anonymous Coward]

I have worked on several large project in private companies and have seen my share of failures. Assuming new code would have a similar level of complexity, doing something like COCOMO would yield about that cost and at high risk.

Re:Not to shocked

[Areyoukiddingme]

It wasn't new code. They started with PeopleSoft.

I don't have to say any more, do I...

Re:Not to shocked

[Areyoukiddingme]

You are correct. And wrong. According to the Reuters article, there were more than 15,000 requirements changes during the lifetime of the project. So you had precisely the right idea. You just underestimated the ability of a bureaucracy to fight back. By an order of magnitude.

And that's what it was, too. Make no mistake, the project failed because a successful software system would reduce the headcount of the DFAS dramatically. That couldn't be allowed to happen, so it was sabotaged by eternal feature creep.

And of course, they started with PeopleSoft, and there's no organization better at absorbing all available money for no return besides the DOD itself. Talk about a match made in hell...

Re:Not to shocked

[Anonymous Coward]

SAP?

Re:Not to shocked

[JakartaDean]

The DoD is well known for changing the specs of a project constantly through out the life time of a program so I'm not surprised the update in the 90s failed it probably had 5,000+ changes from it's initial concept and then you add in the required corruption and incompetence needed to be a government employee or contractor and it makes perfect sense it failed.

I'm sure you're right, as somebody else pointed out if even a little low, due to common feature creep. I suspect though that many of these were because the original RFP described all the users and uses of the system the RFP authors knew about. When people were given the opportunity to explain who actually used the system, and how, the system design had to be continually reinvented.

Re:Not to shocked

[khallow]

A factor of three is half an order of magnitude roughly. I'd give him credit for getting within an order of magnitude.

Re:Not to shocked

[real-modo]

Yah. Last time I was involved (about 2001), PeopleSoft's payroll system was so crude it couldn't be tweaked, adapted, or otherwise modified to run the payroll for a small-to-middling hospital. If the Pentagon started with Peoplesoft, it was always going to end up here.

a billion dollars

[bertomatic]

for a billion dollars, could we not just higher a bunch of accountants and have them hand write and sign the payroll checks. really! a BILLION dollars, and still broke? geeze

Is this overly centralized?

[ebno-10db]

I wonder if part of the problem is that this is overly centralized. Someone above mentioned how they did this all with paper in WWII. I can't imagine the pay for millions of service personnel being calculated by an army of clerks based in Indianapolis. The actual calculations must have been more distributed, with perhaps pay records following a soldier along with his other records.

Decentralizing it should make the bureaucracy more flexible too. Especially in hardship cases like the one described in the story, there should be a way for some local officer to say "give him his regular pay until this is sorted out". Being in the military is no way to get rich, so these people usually don't have a big cushion to live off of. If it turns out the soldier wasn't entitled to the pay, then except in cases of obvious fraud (which I'd think would be a court martial offense) they can give them time to pay it back, maybe with some minimal interest. Come on, the IRS can track anybody and everybody if it really comes to that. At worst, if some guy gets paid a few bucks that technically he wasn't entitled to, I'm not going to get too upset about it. We're definitely not talking CEO bonuses here.

Big disclaimer: I'm not a vet. I suspect someone will say "that's not how the military works", which may well be true. I suspect it was something closer to a decentralized system in WWII though. I doubt some guy in Pearl Harbor coming back from a sub patrol had to wait for a piece of paper from Indianapolis to get paid. If someone in congress was serious about fixing this they could too. I would hope this kind of thing would get sympathy from everyone. Then again there's a federal law that says you can't foreclose on someone's house while they're serving overseas. You don't think that stopped the banks, do you? Or that they received any serious punishment because of it.

Re:Is this overly centralized?

[Areyoukiddingme]

You're right about how it was handled during World War II. Current conditions are deplorable, but WWII vets can tell you it was as bad or worse, as far as paper chasing. However, one thing is very very different. During WWII, patriotism and national fervor was at a high second only to the American Revolution itself. Our troops were going to and then had stopped the Nazis. Nothing was too good for our boys in uniform. If a soldier got a little extra pay he wasn't entitled to, Uncle Sam didn't worry too much about getting it back.

Not so today. Today, every nickel is jealously guarded by downright mean spirited bean counters whipped along by delusional political asshats who think you can fight two wars on another continent while reducing taxes. Between the two of them, they've constructed an ass-covering vicious bureaucracy that errs on the side of underpaying troops, by policy, no matter what hardships it creates, under the assumption they're all thieves and criminals, trying to steal money from the gubber'mint. Between that and a dysfunctional organization that could only have been constructed by the Five Sided Funny Farm, with the laughing assistance of Dick Cheney (yes, dear old Dickie compounded the problem with a half-assed attempt to fix it, back when he was Secretary of Defense), it's a wonder any of our troops get paid at all, never mind paid correctly or on time.

No, there's no room even for reasonable humanity in that environment. If the DFAS decides a trooper* has been overpaid, they take it ALL back, all at once, by withholding it from the next paycheck, no matter what it does to the trooper's family. The Reuters article makes excessive use of the phrase "claws it back" to refer to that process, but the way it's implemented, without reasonable pay pack periods and without reasonable attempts to discover all of the circumstances surrounding an overpayment, it's an appropriate phrase.

* I say trooper because it's less cumbersome than saying soldier, airman, sailor, and/or marine, and because "war fighter" is a fucking stupid-ass phrase.

lowest bidders don't document

[jehan60188]

when you give work to the lowest bidder, you're bound to pay for inept programmers instead of computer scientists

Cobol really is self-documenting

[techno-vampire]

Eh...there probably was some half baked documentation at some point,

Yes, there was and there is. It's called "source code." One of the reasons that COBOL is such a verbose language is that it was designed so that bean counters with no programming experience could audit the source code and understand it well enough to make sure that nobody was stealing anything. Not only that, it's rare that COBOL code actually needs any comments because the variable names are long enough that you shouldn't ever have to guess what any of them are used for or what's being done with/to them.

As far as spaghetti code goes, that can be a problem, especially in very old code, from before such things as structured programming were conceived. And, there's even a statement, "ALTER," which allows you to create self-modifying code, although even back in the '80s when I learned it in school, we were warned never to use it.

Re:Cobol really is self-documenting

[Capsaicin]

Yes, there was and there is. It's called "source code."

While it's true that COBOL is meant to be self documenting, there is, in a 7 million line project, a difference between understanding any particular section of code and being able to comprehend the entire structure of the project. If that structure is undocumented, you will have a lot of reading before you grasp the program globally. Apparently the "failures" that were being experienced were not leading the maintainers to the appropriate sections of code and such a global understanding had become necessary.

I know it breaks one of the cardinal rules of software development, but if you have a cool billion to throw at the problem and the existing mess cannot be fathomed, perhaps starting afresh is an idea ...

Re:Cobol really is self-documenting

[wallsg]

Eh...there probably was some half baked documentation at some point,

Yes, there was and there is. It's called "source code." One of the reasons that COBOL is such a verbose language is that it was designed so that bean counters with no programming experience could audit the source code and understand it well enough to make sure that nobody was stealing anything. Not only that, it's rare that COBOL code actually needs any comments because the variable names are long enough that you shouldn't ever have to guess what any of them are used for or what's being done with/to them.

If I recall correctly from the CSC351 COBOL class I had as an undergrad in 1982 or 1983...

COMPUTE t1(i1) = (t2(i2) ** 3) / (t3(i1) * 2 + 1);

Completely made up, of course, but you can make "self-documenting" COBOL look nearly as bad as Perl if you want to.

Re:Cobol really is self-documenting

[techno-vampire]

I'm not disputing the fact that understanding the underlying structure of such a project is going to be a major project in itself. I'm only pointing out that the code itself is documented. Possibly, what needs to be done is to split the package up into separate programs (which it probably already is) and have teams go through the code program by program (Using multiple teams to get the advantage of doing the different jobs in parallel.) creating whatever design documents are needed to understand the various modules, then putting those together to create, eventually, an overall design document. Not easy, but probably easier than doing the same thing on packages that old written in languages that don't have COBOL's built-in documentation.

Re:Cobol really is self-documenting

[techno-vampire]

COMPUTE t1(i1) = (t2(i2) ** 3) / (t3(i1) * 2 + 1);

Yes, except that you'd have a period at the end, not a semicolon. (This is why statements in COBOL are referred to as "sentences.") However, if you did try something like that in a shop where the bean counters were auditing your code, they'd probably reject it for lack of clarity and insist that you gave that variable a more meaningful name. If you really want to, you can obfuscate code written in any language, but it's probably harder to get away with in COBOL than in most other languages.

Re:Cobol really is self-documenting

[Anonymous Coward]

I know it breaks one of the cardinal rules of software development, but if you have a cool billion to throw at the problem and the existing mess cannot be fathomed, perhaps starting afresh is an idea ...

That sounds good, and they tried just that, in a project called DIMHRS. But unfortunately it didn't work. From the article, "The consensus, according to participants, was that the only way to make it work would be to pull a four-star general from the wars in Iraq and Afghanistan to manage what they saw as a bookkeeping project. England pulled the plug. After more than a decade of development and more than $1 billion of taxpayer money spent, DIMHRS was dead."

Also from the article, "This way of doing business has also proved resistant to change. A recalcitrant bureaucracy, competing priorities - war, among others - and until recently, congressional indifference have stymied any efforts to impose order." Who the heck is in charge? I really wish the military would assign someone who cared about the problem to fix it. Some no-nonsense person with authority, who would keep working until the problem was fixed.

Re:Cobol really is self-documenting

[Capsaicin]

That sounds good, and they tried just that, in a project called DIMHRS.

Yup sorry, my bad, realised this later. Hard to comprehend that 10 yrs of development time and $1bill won't get you a decent pay-roll system these days.

Re:Cobol really is self-documenting

[oh_my_080980980]

What the hell are you talking about? COBOL wasn't designed so bean counters can audit code. Where the hell did you get that. The problem is not COBOL. Blaming COBOL misses the point completely.

Re:Cobol really is self-documenting

[Anonymous Coward]

Who says the source code is still available?

Re:Cobol really is self-documenting

[carys689]

"...it was designed so that bean counters with no programming experience could audit the source code and understand it well enough..." Sorry to be stating the obvious, but verbose or not, you can still write bad code (in ANY programming language, for that matter). Long, descriptive variable and paragraph names are the choice of the programmer (or perhaps whatever coding guidelines that should've been followed) and not the constraint imposed by the language.

Re:Cobol really is self-documenting

[techno-vampire]

Back when I had to learn it, in about '82, that's what we were told as an explanation of why it was so verbose. And, if you think I'm blaming COBOL for the issue, you're wrong. If you'll go back to the beginning of this thread, you'll see that the OP claimed that the code wasn't documented and I pointed out that because it was written in COBOL, the source code itself acted as documentation because of how the language was designed.

Re:Cobol really is self-documenting

[techno-vampire]

Of course you can; I never said you couldn't. However, with COBOL, the bean counters can audit your code and reject it either because they can't follow it (and hence don't trust it) or simply because you didn't follow their naming conventions. Remember, they're being paid, in part, to be suspicious; if they can't understand what it does they're not going to trust it.

Re:Cobol really is self-documenting

[jeremyp]

But you need to realise that the man competition for Cobol at the time when it was invented was assembler. Cobol is only as self documenting as any other high level language.

Re:Cobol really is self-documenting

[Hognoxious]

Back when I had to learn it, in about '82, that's what we were told as an explanation of why it was so verbose.

A little later, but I was told the same thing.

Still, it's bullshit. Even if that was the goal it doesn't work, because the stumbling point isn't the language itself, it's thinking the right way. If you could program by gurning or waving your arms around that would amount to naught if you can't precisely and unambiguously define what you're trying to do. And 99% of people can't, even in the language they've been speaking since they were toddlers.

Re:Cobol really is self-documenting

[techno-vampire]

There are very few non-programmers who can follow most source code and have the slightest idea of what's going on. In many cases, such as Perl, it's often not enough to be a programmer, you need to understand the specific language. COBOL is the only computer language I know of that can be followed by somebody with no programming experience at all.

Re:Cobol really is self-documenting

[techno-vampire]

I think that right now, you and I are arguing two different points. I'm not saying that COBOL was designed to let bean counters write programs, I'm saying that it was designed to let them follow the logic of an already-written program well enough to spot any attempts at theft. As an analogy, you don't have to know how to write a murder mystery to be able to read one and (sometimes) figure things out before the protagonist does.

Re:Cobol really is self-documenting

[Reziac]

Pascal can be fairly self-documenting too. If you have half a clue what it's supposed to do, you can puzzle it out.

Re:Cobol really is self-documenting

[Hognoxious]

With complicated control flow & the sheer length of programs I don't think using ADD foo TO blah GIVING ... rather than foo + blah = ... makes it much easier to find any shenanigans. As long as they don't call variables something like. WS-01-MY-SECRET-SLUSH-FUND.

I can only go on what I was told, but let's face it both of heard it third hand. Anybody who really knew is pushing up daisies or completely doolally by now. Even if they could tell us, it'd be in Sanskrit.

they had punched card IBM systems

[Anonymous Coward]

probably, they had punched card ibm systems.

if you think there were 'no problems', im not sure i agree with that. im sure there were problems.

the main difference between WWII and now is that the US did not have a massive, bloated, standing army taking up hundreds of billions of taxpayer dollars every year before around 1940. before around 1917 there wasnt even a federal income tax from which they could draw all this money to waste (funnel to awful private contractors)

but that old code had to fit into 80 columns and

[Joe_Dragon]

but that old code had to fit into 80 columns and other really limits

use paycor\adp

[Twillerror]

Regardless of your political leanings this is a job that the private sector could handle way way better. It is super hard to create a good software shop...let alone being the military.

We use paycor and we have good to great IT in general. We could program a pay app, but why the hell would we? Is pay schedule really that complicated....if it is why not simplify it...a great opportunity for reform.

How much?

[rickb928]

Seriously, a Billion Dollars?

Incompetence. This sounds like explaining to the boss how you can't write a program to pay 3.25 million employees accurately and on time.

Then explaining how you can't write a program that pays 325,000 employees accurately and on time.

Then explaining how you can't write a program that pays 32,500 employees accurately and on time.

But they did in the 60s.

Just as the FAA has sunk $ into new air traffic controls software with nothing to show for it, and New York City ditto with payroll software, incompetence. But I was watching the NMCI grind its way towards me a few years ago, and that was disaster on afterburners. I should know by now the Government is probably not the model of competence in many areas.

I wonder, though if they might ask Social Security how they get checks out every month. Maybe that is the software model they should look at, or *gasp*, consider that they cannot use a better tool then COBOL. So stop looking.

call it what it is: fraud

[markhahn]

when the mil/gov spend a billion on some software project and it fails, we need to start calling it what it is: fraud perpetrated by consultant/contractors.

it's bad enough when the industry burns 10-50M on an ERP project for a company (or university!), but pretty soon those tens of millions add up to real money. spending a billion should be HARD!

ADP? Paychex?

[Anonymous Coward]

For $1B I'm sure either one of them could have done the job.

Either run payroll for a while, or delivered a turnkey system that worked.

Sheesh.

only 7 million

[confused one]

Only 7 million lines? That doesn't seem right for a government project at all... Way too small.

Re:only 7 million

[LeadSongDog]

That's 7 million lines of COBOL. Barely enough for a hello world....

I think they had good docs once

[ralphaostrander]

I worked in NOC at DOW and we had very good documentation. Including the documentation on making documentation. For that kind of money you could have brought back the same people who documented it in the first place. If you want good documentation today or dont have any. I know what your problem is, you need to hire more females on. They nag the guys into doing better sucks for the guys until those docs save the company millions. Say a router is down and the printer cant print bills of lading so the trucks are backing up. But you put the router number in and the docs come up showing a dsl back up. boom the printer is printing and money is being made. Because the last time it went down they documented even what commands they used to bring up that link to the dsl. Just an example but works everywhere. Everyone should be updating those doc like if equipment has moved to a new location. I hope there is down time and not putting out fires all the time. If so you really need good docs. You need to assign one person on each of your teams to hold the hand of new people and have everyone document everything. Example I left my station to fart did 60 second turnover before handing off the station to J Wilks Booth. Why I wrote all that bored.

Re:I think they had good docs once

[tqk]

Why I wrote all that bored.

Next time, find something else to do.

Typical Government Efficiency

[kartaron]

For 33 years the government has been trying to replace the 60 year old air traffic control systems. Three different systems have been tried. The first was a complete write off, meant to be an IBM designed Unix based system, it went overdue by years and billions and was killed off in 1994. http://www.baselinemag.com/c/a/Projects-Processes/The-Ugly-History-of-Tool-Development-at-the-FAA/ The Second named CARTS began in 1996, meant to be a replacement for the aging radar systems the program did replace the older systems in some airports, but again the program was killed for cost overruns and stalled production. http://www.fiercegovernmentit.com/story/tracon-air-traffic-control-modernization-faces-prospect-more-schedule-cost/2013-06-02 http://www.bloomberg.com/news/2013-05-31/air-traffic-upgrade-over-budget-facing-delays-report.html In 2003 they revived the project with compartmentalized implementations of an integrated system in order to see short term improvements. The first system, a replacement for CARTS renamed STARS) went in in 2012 and it is costing 60% more than expected, with the remaining systems set to be developed and implemented over the next 13 years. The next system to be implemented, ERAM, is already overdue by 4 years, over budget, and according to FAA reports, subject to critical failures and instability. http://www.airtrafficmanagement.net/2013/06/nextgen-over-budget-delays-certain-report/http://www.fiercegovernmentit.com/story/eram-continues-undergo-critical-failures/2012-10-02 http://en.wikipedia.org/wiki/Next_Generation_Air_Transportation_System

Re:Typical Government Efficiency

[Anonymous Coward]

That's because the current system is impemented in lisp. I imagine that java, pascal, COBOL, or whatever (I suspect Visual Basic, Excel sheets, and MS Server) they are trying to replace it with isn't as stable and is subject to Greenspuns Tenth Rule. Additionally, if air traffic control is hiring lisp programmers, they probably aren't getting the dregs you get when you put out a sign asking for Java or C# programmers to work on a government project.

unsalvageable

[shentino]

Write a new system from scratch, and transfer payroll from the old one to the new one.

Once everyone's migrated, chuck the old system in the bitbucket.

Re:unsalvageable

[Areyoukiddingme]

That's what they tried to do, more or less. And that's how the failure was engineered. The laws, rules, regulations, executive orders, exceptions, and mandates have been accumulating in layers of bureaucratic sludge, like sediment, for decades. No one person even knows them all. It's questionable whether any one person even could know them all, and it's guaranteed that at least some of them are self-contradictory.

While it might be possible to whip that mess into a functional single system, it isn't worth the expense. Even an attempt that wasn't run by the flaming incompetents at PeopleSoft would still have very tough going to finish. The only reasonable way to fix the problem is Congressional action, to eradicate all of the endless bits of folderol, folding all the bonuses and debits into the base salary, cut 10% off of that, and call it a day. Pay everybody on that scale.

Which of course will never happen. Not with this Congress, or any subsequent one.

Re:unsalvageable

[Anonymous Coward]

Thanks, Captain Obvious. What would we do without you?

They might have lost the source

[Trip6]

Very common in older mainframe shops. Poor source control. You can reverse engineer it but good luck.

Re:They might have lost the source

[Anonymous Coward]

But they know that they have seven million lines of code. So that means they should have the source code at hand, no?

I wouldn't bet on this "problem" getting fixed:

[mechtech256]

"The department’s authorized 2013 budget, after sequester, totals $565.8 billion - by far the largest chunk of the annual federal budget approved by Congress. Yet the Pentagon is literally unable to account for itself. As proof, consider that a law in effect since 1992 requires annual audits of all federal agencies – and the Pentagon alone has never complied."

Re:but that old code had to fit into 80 columns an

[tqk]

but that old code had to fit into 80 columns and other really limits

Some of the variable names those farts chose would make a fair sized subroutine today. Back then, there was FORTRAN with one letter variable names, and COBOL in which you could fall asleep before reading to the end of one.

Re-write it in awk

[russbutton]

Cobol is based on the notion of processing what are essentially formatted text files, one line at a time. If you knew the format of a file to be read by a Cobol program, you could re-write it in awk and use about 1/50th the amount of code.

Of course what really needs to be done is to document the actual process and system requirements, and then just put up a modern payroll processing system. The biggest problem is that there are a lot of people whose job it is to take a piece of paper from one bin and put it in another. All of those jobs would be put at risk were you to actually do something substantive about this problem. They're far more concerned with their jobs than actually getting anything done.

Re:Re-write it in awk

[Areyoukiddingme]

Bingo. Got it in one. The project failed because the bureaucracy could not be allowed to be replaced. It would put too many people out of work.

There's going to be 80,000 unemployed troops flooding back into the country over the next couple years. That's going to be bad enough for the unemployment rate. Putting tens of thousands of paper pushers out of work at the same time? Unthinkable!

Re:Re-write it in awk

[Anonymous Coward]

To compare data processing in COBOL to awk shows you have not a fucking clue what you are talking about.

Re:Re-write it in awk

[DerekLyons]

The biggest problem is that there are a lot of people whose job it is to take a piece of paper from one bin and put it in another. All of those jobs would be put at risk were you to actually do something substantive about this problem. They're far more concerned with their jobs than actually getting anything done.

No, the problem is you don't understand the problem domain and thus just repeat platitudes on the assumption that doing so makes you look wise. This system has been in place for years, all the old paper movers are long gone.
 

Of course what really needs to be done is to document the actual process and system requirements, and then just put up a modern payroll processing system.

Everything *is* well documented - the problem is, the military pay system is way, way more complex than any civilian system. None of my old pay statements are handy (buried somewhere out in the garage if I still have them), but here's what went into my paycheck in the last year or so of my enlistment;

• • Base Pay: E-5 with over eight years of service.
  • Submarine pay. (But only so long as I was eligible for submarine duty - I was on shore duty, and if I'd gone under nine months with transferring to a sea command I'd no longer be eligible for that pay. This pay also varied with the number of years I'd been submarine eligible.)
  • COMRATS. Rather than issuing me a mess card to eat in the chow hall, I got cash instead.
  • BAQ - since I didn't live in the barracks, I got a cash allowance to live off base.
  • _____ I don't remember the name, but it was a differential to BAQ to account for the cost of living here. Someone in San Diego got more, someone in bumfuck Nebraska got less.
• Then there were all the deductions (not so different from civilian practice, so no need for details.)
• Then there were all the annual payouts, like my re-enlistment bonus and my uniform maintenance allowance.

 
Had I gone back to sea, I'd have gotten sea pay - which amount depends on the total number of months served at a sea command during my career to date, so those months have to be tracked and the clock started and stopped as appropriate. (The services have a whole host of incentive, qualification, and duty status pay and allowances - jump, hazardous duty, onerous duty, etc... etc...)
 
Then there's annual leave (which isn't so different from the civilian world.)
 
On top of that, the system has to manage travel pay, the civilian pay system, retirees...
 
It's a complex system, and nowhere as simple as just 'parsing a text file'.

Re:Re-write it in awk

[Anonymous Coward]

> If you knew the format of a file to be read by a Cobol program, you could re-write it in awk and use about 1/50th the amount of code.

It may be true that if one rewrote an awk script in COBOL then that would be 'processing what are essentially formatted text files' and may take more lines of code (certainly _NOT_ 50 times), but it would likely run several times faster.

However, that is a completely simplistic view about what typical COBOL programs do. Perhaps you looked in at a single class of a programming COBOL course and thought that was all there was to it.

Almost all COBOL systems use databases which may be collections of indexed and relative files or be relational databases. How does awk process those ? Large numbers of COBOL systems have interactive components, often using CICS, for maintaining those databases, processing and reporting. Try doing that with awk.

Re:Re-write it in awk

[russbutton]

Parsing a formatted text file is all that Cobol is capable of doing. That there are multiple branches of your logic tree, and thus multiple Cobol routines that get run doesn't change that.

Re:Re-write it in awk

[tom arnall]

i'm not sure you've ever designed a system. the 'algorithm' you imply is simple. but if the playing field is crowded with people whose goal in life is to be f*king up wet dreams, you've got serious problems. In the "government," CYA rules and produces the results with which we're all familiar.

What?

[Reliable Windmill]

How do you spend a billion dollars trying to wrangle legacy code? 500 programmers at $200K per year for 10 years? How is it even possible?

The Horror! The Horror!

[Tyler Durden]

Who would risk looking at seven million lines of Cobol code? I'd have better luck keeping my sanity if I looked Cthulhu square in the face.

Re:The Horror! The Horror!

[Anonymous Coward]

Who/what the fuck is a cluthulu?

Re:The Horror! The Horror!

[Areyoukiddingme]

One of the Elder Gods invented by H.P. Lovecraft for his horror stories.

i'll do it

[Anonymous Coward]

i am good in coding

What about...

[jameshofo]

I thought they had all these wiz bang cyber warriors! People so smart that they can make your head explode with their extreme cyber hacker power..... Oh right that was total bullshit.

Re:but that old code had to fit into 80 columns an

[arth1]

Back then, there was FORTRAN with one letter variable names, and COBOL in which you could fall asleep before reading to the end of one.

No, COBOL names are limited to max 30 characters.. That's nothing compared to some of the java monstrosities I've seen.

And newer Fortran, like F90, has a limit of 31 characters, i.e. longer than COBOL.

Audits

[flimflammer]

As proof, consider that a law in effect since 1992 requires annual audits of all federal agencies – and the Pentagon alone has never complied. It annually reports to Congress that its books are in such disarray that an audit is impossible.

I don't even understand how this can be a valid excuse to avoid an audit. So the books are in disarray. So what? That's never going to change unless you do something about it. Granted I'm sure it's to their benefit that they avoid an audit so unless we can actually force them to get their shit together they're just going to keep playing dumb.

Use the Proven Afghan System

[bromoseltzer]

Who needs software? Print lots of $100 bills, put into suitcases, put suitcases on pallets, and ship to Commanding Officers around the world.

Re:Use the Proven Afghan System

[Anonymous Coward]

Or use a very basic design -- one routine for each person that has to be paid. Shouldn't be more than a few lines including their date of entry into the system, pay period, pay amounts with deductions (and cumulative) and a slot for when they retire. Even with 5 lines per person, this should be smaller than the legacy system -- or are they paying over a million people?

I doubt...

[Anonymous Coward]

Whether any of their 'developers' are under 40 years of age. I remember fixing thousands of Y2K dates in working storage ...oh 15 years ago... and now I seem to be 50 years of age! How'd that happen? Crap!

Give me

[plopez]

3 decent programmers, experienced 10+ years. Business and HR programming preferred.
Military pay regulations and laws + 1 lawyer and 1 accountant (possibly on loan from GAO)
1 Documentarian
1 project manager
1 QA/tester person
COBOL licenses, microfocus or whatever
Time on a good QA instance of the system
Data. Lots and lots of data.

And about 18 months to unsnarl it. IT WILL NOT BE REPLACED IN 18 MONTHS. But it will be understood. Then we we can talk about a replacement.

Damn!

[Anonymous Coward]

i woulda fixed it for them for half a billion!

Lords of Cobol, hear our prayers...

[Anonymous Coward]

Srsly, we trust these guys to hold on to our information and they can't even get their employee payment systems right?

D'oh

[mitcheli]

Well, it's a good thing that Cobol was required training for the 3C0x2 career field in the Air Force. ... oh wait, they outsourced all of those... Ooops.

The problem isn't COBOL it is bad management

[jbohumil]

The problem isn't COBOL is is bad management. I think that really says it all. You have to manage a project and that means you have to have support at a high enough level that the impacted departments get their marching orders in agreement with the master plan. Otherwise you are doomed if you have to fit the solution to the middle management tier's "requirements" because their "requirements" are that everything stays the same so their jobs and departments are unaffected by the new solution. That's not going to happen in a ground up re-implementation.

Even more confusing...

[RoknrolZombie]

...the NSA and the military alike are full of codebreakers and analysts. 7 million lines of code should be nothing to people that translate Chinese Mandarin and pick out buzzwords.

Re:Even more confusing...

[RoknrolZombie]

Obviously the people that speak Chinese Mandarin shouldn't be expected to learn COBOL. My point is that the infrastructure is in place for them to take 5 new geeky recruits and train them in the language the same way that they would train the voice analysts. Hiring a contractor? Don't be retarded - train someone to do the important jobs that you need done. Plus, it's much much easier to keep a leash on the leaks (although you wouldn't know it in recent years) than when dealing with a civilian.

Could be worse...

[Arancaytar]

At least their nuclear missile silos aren't operated by such a program.

(... I hope.)

Re:Could be worse...

[Anonymous Coward]

Naaaah. Don' worry yerself. Those are in FORTRAN. II, probably.

Typical of all bureaucracy's

[luminousone11]

This is common to private industry as well, the only major difference being the scale of the project. The government needs to define a process that maintains the chain of custody of important software, and this should be redundant. If multiple persons or organizations are charged with this activity, it is less likely that a death or corporate bankruptcy(or simple lack of interest in continuing the contract) will create the situation where you have 7 million lines of code that nobody employed or contracted have any idea how the bollacks it works. I would suggest a few policy changes to improve the situation, 1. retain the right to directly hire or offer contract to any person employed by a contractor developing software if for any reason that contractor should cease being the contract. 2. when contracting or even writing software in house, on large projects(anything projected to have more then say a million lines of code), also hire a second development house to review and file bug reports on the software, submitting a patch history to both the primary developer and the software owner/government. 3. as relates to point 2, the second development house, as part of their contract an option to make them the primary developer in the event that the original developer can not fulfill the needs of the work, or cease being the developer for any reason.

Give me a billion. I'll make it happen.

[Anonymous Coward]

It seems to me that many private sector software companies could write a substitute program for less than a billion.

Now Reuters is broken

[Anonymous Coward]

The article links to a preview of Reuter's new broken web site. I'm as worried about the gradual breakage and uselessness of the Internet than I am some old COBOL code. "You need to have Javascript enabled in order to use Reuters.com. Here are instructions on enabling JavaScript in your web browser." The old Reuters did not require JavaScript. Content will eventually be completely inaccessible. The original web was never designed to be hidden behind a layer of obfuscation like this.

ILRT

[ThatsNotPudding]

Maybe it's based on the Frank Herbert story of the government office dedicated to slowing things down intentionally, hence their motto: In Lieu of Red Tape.

Now knowing what we do about the military-surveillance complex, any major eff ups like this may be a blessing in disguise.

Oh please

[gelfling]

Just toss it over the wall to ADP. People have been running payroll systems for 60 years.

Re:Oh please

[oh_my_080980980]

LMOL yeah on the size and scale of the US Military....*eye roll*

Re:Oh please

[gelfling]

Walmart? Kelly Temps?

Now that's what I call governance!

[sabbede]

Only the Federal Government could spend one billion dollars to make something that already exists, and fail.

But my favorite part? There are nearly 2.5 million active and reserve members of the military. Amazon sells a three license copy of Quickbooks Pro 2013 for $400. Just sayin'

Why not incremental replacement?

[fygment]

Changing out the whole darn program is pretty daunting and (it seems) impossible. But why not just incrementally replace portions? Eventually, it would all get changed out no, it would just take a while? I'm not a professional programmer so I'm genuinely curious about the challenges.

Re:Why not incremental replacement?

[Hognoxious]

Then you need to build interfaces to connect the new bits to the parts of the old system that are still in use. This is a lot of effort (and hence cost) for something that's only temporary.

Don't forget MUMPS

[Anonymous Coward]

There is nearly the same amount of code in MUMPS that manages the DoD's healthcare records back to the early 70's. It's a mess.

This is what nobody gets!

[Anonymous Coward]

Skynet was a COBOL program and these are its seeds! Be afraid.

COBOL? The horror!

[T.E.D.]

What this project clearly needs is a multi-million dollar effort to port all that COBOL code into today's hippest new language. That way any code in there that happens to actually work right through some fluke of fortune, will get new bugs inserted into it. Then we can do it all again when a new language becomes more fashionable next month.

I have to go now. They're totally rebuilding my building, now that there's been developed a snazzier way to weld joists. I'll get back to you in 9 months, if everything goes to schedule....

Thoughts

[Anonymous Coward]

1. The system has 7 million lines of code that han't been updated, how many lines have been updated? A+B just might equal something much bigger.

2. I've seen COBOL object code where the source was lost. Some poor programmer was maintining it by hex editting the object file. Only guy I ever met who could look at a hex dump and actually recognize the result of a PERFORM statement.

3. If you want a new system that does exactly what the old system does then in a lot of cases you may as well keep the old system.

4. Grokking 1,000 lines of code per hour and given a 2,000 hour work year gives an initial read through of 3.5 mythical man years for just the stuff that hasn't been changed. Good luck.

5. The actual base calculation is probably very simple ( rate of pay per unit of time times number of units of time at that rate). Its the 5 billion edge conditions and being able to record and audit them that makes things interesting. Giant bureacracies become giant beauacracies by making up and dealing with huge numbers of rules that no one department much less individual could ever know in toto.

6. Very large organizations run into problems with data management that are simply due to the amount of data being way larger than normal technology regularly handles. I attended a lecture on the Large Hadron Collider where they were talking about developing a way to record the massive amounts of raw data that was being produced. The expected solution was to have over 1,000 processors deciding what to keep and storing 3 months of selected data in one or more warehouses full of 12" tape reels. They were still trying to decide on how many warehouses. They were also modifying a Fortran compiler to translate formulae written the way high energy physists wrote equations. This was to minimize the possibility of an error creeping in from what the theorists said and what the programmers thought they said. Sort of like having accelerometers that can only be installed in one direction.

Cost Benefit Analysis

[Anonymous Coward]

$79 per month, full service (http://payroll.intuit.com/).

$1B divided by $79 per month equals 12658227 months of service.

I'm thinking he Pentagon could have *BOUGHT* Inuit outright for $1B.

And these are the people whining over the sequestration.

The end of civilization

[carys689]

7 million of undocumented COBOL code that will cost billions to update or replace with a modern language -- a harbinger, I think, of the end of civilization as we know it.

Re:Cobol literally makes my blood boil

[Hognoxious]

And If you bothered to research maths you'd know that the exponential is a function that describes the relationship between two variables, not a comparison between two values.

Is there refactoring/unit testing support 4 cobol?

[Anonymous Coward]

I've only had a little experience with COBOL but from what I've heard COBOL is still being developed. I've heard they've added OOP like support so has anyone developed any unit testing or refactoring support?

Procrustes' Fortune Cookie Say :

[Anonymous Coward]

Relying on previous cases reported elsewhere.
That's probably 20thousand to 100 thousand lines of actual logic and setup, and the rest is made up mostly of explicit print statements - for about 350-500 actual paychecks. Plus necessary page jumps, messages for operator to change tape reels, bell ringing, etc. >:p

Spirit Coders

[Anonymous Coward]

The real problem is that it was coded by personnel left over from the Code Talkers .