The NSF wants to know something about the computer industry and they ask Gartner? Gartner, the company that advocated OS/2 and I-CASE?

I wasn't aware the private sector was subject to the scrutiny that the public sector is.

No, the antiquated payroll system is evidence that the government did get it done itself at one time.

Your solution is... what? Keeping in mind that Scott Adams' Dilbert comic strip is a documentary about the private sector.

You're right about corruption, it's usually taking place at a much higher level than the IT project though. Someone fairly highly placed has a relationship (familial or otherwise) with someone fairly highly placed at the outsourcing firm.

Today, a pithy aphorism was found to be not literally true. Film at 11.

Ah, you actually do get my point.

If someone asks how to get blood out of a stone by squeezing it, the correct answer is "You can't."

My point, which you get but apparently want to argue about anyway, is that you can't always make a team out of a group of people. The OP is trying to do just that, make a team out of a group of 100 people that have nothing much in common except they all work for the same company. How do I know they have nothing except their workplace in common? Easy, there's 100 of them.

If you work in an organization that size and you're all pulling together, you've discovered paradise/nirvana/heaven. Don't quit for anything.

Or want them to hate each other passionately.

Many people attempt to illustrate their point with analogies. Those analogies come from their personal philosophy, politics, belief system, etc. So, when someone who believes in intelligent design, that the current POTUS was born in Kenya, and that the globalists are planning to kill off 20% of the world population with fatal injections masquerading as H1N1 vaccinations attempts to illustrate their technical point with something from their personal zeitgeist, those in the room who don't share those deeply held beliefs get kind of turned off.

It's usually better to not know your coworkers too well.

The Milwaukee Journal-Sentinel has done any number of stories over the past couple of years that indicate IT contractors are significantly more expensive than Wisconsin state employees. The problem (in WI) is that you can find money to hire contract staff build your application; you can't get additional positions to build it. Getting additional positions is almost impossible.

So you pony up money, hire contract staff, and build the application for some factor N greater cost, but you do get your application. Project is completed, contractors go off to their next project in another organization. Then there's no one to maintain the thing. Also remember it was built by people who knew they wouldn't have to maintain it, so it might be crap. It might also be wonderful because taking pride in your work isn't a trait that's confined to permanent staff. I've seen both, but more often the former.

Having state staff build the system means they know they have to maintain it. Usually that results in better quality, but not always. Again, I've seen both, more often than not the staff create something maintainable (if not elegant) because they have to live with the consequences.

[Cue a whole bunch of twits with variations on "but that doesn't make sense" because they think bureaucracies are supposed to make sense.]

Presuming facts not in evidence:

1. There is a process to present a "legitimate business need"
2. The process does not consist of a rubber stamp reading "NO!"
3. Management actually has a clue about what would constitute a "legitimate business need"
4. Management actually has a clue, period
...etc.

First, I suggest a perusal of Capers Jones' book Software Assessments, Benchmarks, and Best Practices, from which we learn that most of the cost of internally developed systems (the sort TFA is talking about) is in maintenance. So there should be no argument that making the code maintainable is of some high priority.

[f/x: get off my lawn] Sadly, there are many programmers who don't understand that maintenance is not the act of rewriting the system in a language they would like on their resume. That might be adaptive maintenance, but the lion's share of maintenance actually involves fixing that which is broken (this would be corrective, perfective, and preventive maintenance).

Sadly (again) we already know the answer to the OP's question. You need an enforcement mechanism. The cheap and easy way to implement that is via code reviews. And we know that isn't going to happen.

Why? Because too many people who get to make decisions don't want to believe that first item from Jones' book. Making an innovative change to a UI is sexy, makes it obvious that some work has been done. Bullet-proofing user input edits is mundane, and smacks of cubicality.

You are unlikely to get a commitment from management to let you do things "the right way." If you did, you would have no way of knowing that it won't be rescinded when the boss' kid gets a job programming in the cubicle next to you.

The only way I know of to make this work is peer pressure. And that is unreliable. Thus maintenance will always have at least some aspect of the "fix what the clever kid did" to it.

Fixed that for you.

None of that makes up for the fact that roundabouts are stupid.

I don't remember which columnist in the 1980s said that, if you need to write user exits for the business package, don't buy it.

And a good manager can tell the difference between a good architect and bad one just as easily as they can between a good programmer and bad one, which is to say not at all. And so we end up with good architects being outnumbered by bad ones, and a broad brush being used to paint them all.

Unfortunately the current strategy seems to be "don't maintain, rewrite." Regardless of the quality of the original code.

And yet, those same people keep paying for the next release, and the next, and the next...

Unfortunately "those people" appear to have a background in accounting and nothing else. Believe it or not, squeezing the last precious, tasty drop of profit from an endeavor is not the ultimate goal.