Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
How often do you see boondoggles like this when two private sector companies write contracts with each other?
I wasn't aware the private sector was subject to the scrutiny that the public sector is.
The outsourcing model doesn't work for us.
And the antiquated payroll system is evidence that the government can get it done itself?
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.
And let's get real. It's not like there isn't any backroom dealing going on here.
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.
Those people you describe -can't- form a team.
Ah, you actually do get my point.
The question asked was how to form a team. Taking people that are incapable of forming a team and trying to use them as a reason not to bother trying is silly, at best.
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.
They need to work together and discuss things constantly if you want them to feel like a team.
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.
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.]
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
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.
Computerized systems are not designed for the benefit of users. They are designed for the benefit of entrepreneurs.
Fixed that for you.
A good architect is someone with the experience to know when to cut corners and when to enforce rigid discipline.
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.