Forgot your password?
typodupeerror

Comment: Re:Apples, oranges, confusion, and enlightenment (Score 1) 89

by some-old-geek (#36785292) Attached to: Banks' Big Upgrade: Meet Real-Time Processing
CICS dates back to 1998, see the recently produced history of CICS page. CICS does POX, REST, and SOAP, in addition to MQ, so integration with the tried and true can be done and you can migrate to whatever you want on either side of the interface. Boring, I know. We are talking about banking, remember, not Facebook or Twitter.

Comment: Re:Corruption (Score 1) 306

by some-old-geek (#31647128) Attached to: NYC Drops $722M On CityTime Attendance System

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.

Comment: Re:You're solving the wrong problem (Score 1) 205

by some-old-geek (#30975160) Attached to: Solutions For More Community At Work?

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.

Comment: Re:You're solving the wrong problem (Score 1) 205

by some-old-geek (#30970744) Attached to: Solutions For More Community At Work?

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.

Comment: Re:Trend will continue... (Score 3, Informative) 116

by some-old-geek (#30870044) Attached to: Who's Controlling Our Vital Information Systems?
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.]

Comment: Re:Do power users abuse their IT knowledge? (Score 1) 460

by some-old-geek (#30632796) Attached to: Do IT Pros Abuse Their Power?
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.

Comment: I may have to give up (Score 1) 477

by some-old-geek (#30343816) Attached to: Defining Useful Coding Practices?

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.

Comment: Re:Bad Mischaracterization (Score 1) 551

by some-old-geek (#29548057) Attached to: The Duct Tape Programmer

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.

The universe is all a spin-off of the Big Bang.

Working...