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.
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.
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.
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.]
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.
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.
And yet, those same people keep paying for the next release, and the next, and the next...
Re:Biggest Gripe about coding .. shouldn't be code
on
Coders At Work
·
· Score: 1
Put another way, the programmer's time finally became more valuable than the machine's time. Once that happened, the rules changed - something which those some of those people with "no background in IT" figured out years ago (I hear it's because they had a background in some dark discipline called "accounting") and which a lot of IT people still can't wrap their minds around.
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.
The problem is, it's much harder to recognize quality, especially in modern products, thus there is no market pressure for it. But there is a market pressure from the investor's end to produce as much things as possible.
Ultimately, it's an issue of asymmetric information and trust.
What I find offensive are the complaints from people who voluntarily go the cheaper route, then complain that the cheaper product [doesn't perform as well | isn't as reliable | doesn't recover from errors as well | etc.] as the product created by idealistic engineers.
Remember the old days, when the browser was superior because it was a thin client? Maybe we need a term for the thickening of clients... Americanisation?
Re:A better book would be "How New Systems Succeed
on
Why New Systems Fail
·
· Score: 1
A project specified mostly by people who don't know what the system is supposed to do, implemented by people who don't understand the business, replacing a legacy system containing within its labyrinthine bowels the combined knowledge of tens or hundreds of expert users past and present. What could possibly go wrong?
You do realize you've just described most reengineering efforts, right?
So why has nobody bootstrapped themselves a bit by writing some libraries or extending/improving the language?
On IBM mainframes, there are the Language Environment (LE) callable services that provide a bit more functionality than native COBOL. Otherwise, most corporations write their own.
Or at least written a good editor. It's been around for a long time. Hasn't some bored guru written his own vi/emacs clone for it in the last 40 years?
Or improved the compiler to make the errors easier to understand?
IBM reportedly asserts that the error messages from their Enterprise COBOL product are all self-explanatory. IBM's customers have varying opinions of that assertion.
Or addressed any of the other complaints I've seen upthread?
Seriously... Is there something about cobol that makes that effectively impossible?
Like what?
"no pointer/references" - COBOL has had pointers since the 1985 standard.
"low functionality" - What does that mean, specifically?
"[...] not only is all of your data global to your program, in a typical batch cycle all of the data is global to ALL of the programs" - The first part is as true as your application design makes it (you can have more than one program in a source code member (read: file) and it's your choice whether or not the data in the enclosing program is visible to the nested program(s). The second part is true in the same sense that all data in the database is global to an application. Again, if you design something badly, don't blame your tools.
Really, COBOL has its faults, but these aren't them.
"peculiar" "awful" "miserable" "weak" "arcane" - these are just people exhibiting a personal preference. No doubt there is (or was) a problem they needed to solve and COBOL was a bad fit. Or maybe they're just parroting what some instructor or TA told them.
Over the last couple of decades I've been paid to write code in a baker's dozen programming languages on a half-dozen operating systems. No matter which language I'm using, I always get to a point where I wish I could add in just a bit of another's features. I find the most important thing to remember is that different languages have different problem spaces in which they're appropriate.
Slashdot Mirror
One doesn't the word "plus" instead of the symbol "+" in COBOL. So, no, I don't believe you've written "tons of Cobol [sic]."
That's 1968, duh.
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.
The NSF wants to know something about the computer industry and they ask Gartner? Gartner, the company that advocated OS/2 and I-CASE?
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.
Today, a pithy aphorism was found to be not literally true. Film at 11.
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.
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:
...etc.
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.
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.
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.
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...
Put another way, the programmer's time finally became more valuable than the machine's time. Once that happened, the rules changed - something which those some of those people with "no background in IT" figured out years ago (I hear it's because they had a background in some dark discipline called "accounting") and which a lot of IT people still can't wrap their minds around.
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.
This just in: Short term thinking leads to long term problems.
The problem is, it's much harder to recognize quality, especially in modern products, thus there is no market pressure for it. But there is a market pressure from the investor's end to produce as much things as possible.
Ultimately, it's an issue of asymmetric information and trust.
Bruce Schneier wrote about a similar concept, itself written by American economist George Akerlof.
What I find offensive are the complaints from people who voluntarily go the cheaper route, then complain that the cheaper product [doesn't perform as well | isn't as reliable | doesn't recover from errors as well | etc.] as the product created by idealistic engineers.
It's good for the economy to produce stuff that people have to replace regularly. We should produce crap that breaks every few months.
A novel observation.
Remember the old days, when the browser was superior because it was a thin client? Maybe we need a term for the thickening of clients... Americanisation?
My confidence brimmeth over.
A project specified mostly by people who don't know what the system is supposed to do, implemented by people who don't understand the business, replacing a legacy system containing within its labyrinthine bowels the combined knowledge of tens or hundreds of expert users past and present. What could possibly go wrong?
You do realize you've just described most reengineering efforts, right?
So why has nobody bootstrapped themselves a bit by writing some libraries or extending/improving the language?
On IBM mainframes, there are the Language Environment (LE) callable services that provide a bit more functionality than native COBOL. Otherwise, most corporations write their own.
Or at least written a good editor. It's been around for a long time. Hasn't some bored guru written his own vi/emacs clone for it in the last 40 years?
There is an Eclipse-based product.
Or improved the compiler to make the errors easier to understand?
IBM reportedly asserts that the error messages from their Enterprise COBOL product are all self-explanatory. IBM's customers have varying opinions of that assertion.
Or addressed any of the other complaints I've seen upthread?
Seriously... Is there something about cobol that makes that effectively impossible?
Like what?
"no pointer/references" - COBOL has had pointers since the 1985 standard.
"low functionality" - What does that mean, specifically?
"[...] not only is all of your data global to your program, in a typical batch cycle all of the data is global to ALL of the programs" - The first part is as true as your application design makes it (you can have more than one program in a source code member (read: file) and it's your choice whether or not the data in the enclosing program is visible to the nested program(s). The second part is true in the same sense that all data in the database is global to an application. Again, if you design something badly, don't blame your tools.
Really, COBOL has its faults, but these aren't them.
"peculiar" "awful" "miserable" "weak" "arcane" - these are just people exhibiting a personal preference. No doubt there is (or was) a problem they needed to solve and COBOL was a bad fit. Or maybe they're just parroting what some instructor or TA told them.
Over the last couple of decades I've been paid to write code in a baker's dozen programming languages on a half-dozen operating systems. No matter which language I'm using, I always get to a point where I wish I could add in just a bit of another's features. I find the most important thing to remember is that different languages have different problem spaces in which they're appropriate.