Data not at risk?
How the fsck would he know?
Where does he bank again?
I'll need his account numbers, PIN and a sample of his signature to verify it.
40 posts • joined 11 Mar 2017
True story. I once wrote something that had no bugs at all. But due to my assumption that it must have bugs, it took me much longer to verify it worked than if it had bugs.
The real point to all this is that I expected bugs but had I found one or two, I would have declared it a success when in reality it may have had more than that.
I'm not sure if I should always assume it's perfect or that it will never be perfect.
Sorry to go all Zen on y'all but I thought it a unique learning experience.
I worked for a vendor in the late 90s that did much the same thing only they fired the person in charge of QA as well. The speculation at the time had to do with upper damagement getting quarterly bonuses based on the software shipping. About 3 months later the vendor upper damagement was investigated and they were later successfully prosecuted for stock fraud.
Draw your own conclusions.
I know a little bit about the technical part of payroll with SAP. The payroll cycle business processes may have changed with $/4, I haven't worked on an $/4 payroll system as yet and cannot do a practical comparison.
In the past the payroll data model wasn't quite the best performing part of the system. Not having seen how they have changed it for the $/4 release, I would venture that they have replaced the clustered tables used in the payroll model with a new $/4 data model and also a columnstore technology (HANA).
Now that you can cache most, if not all the data in memory, throw a ridiculous amount of hardware and resources that you would never have done for a Unix/Windows system with a "normal" database and set it loose, I don't think it's all that it's quite surprising. You're essentially comparing a cheetah with a snail in hardware terms.
For example, SAP has redone the $/4 Financials tables with all new structures and the performance when the code takes advantage of the HANA architecture and the new structures is even more dramatic. It's a fair guess that it did the same with payroll.
Another point is that the code on one of the sites for payroll I worked on had a great deal of custom extensions (known as "enhancements" and "user exits" in SAP parlance) and they were horrid in terms of performance. That may also be the case here. So the improved payroll cycle is entirely believable. It just may not be completely true.
PS: $/4 isn't a typo. It's bloody expensive.
Their idea of making people work in the office, and the subsequent closing down and centralization of offices, was a ploy to cut expensive headcount and offshore jobs. When the older workers quit or were fired when they couldn't move, the job were offshored or opened to newbies making much less. Many of the offices were ill equipped to handle the influx of people and the facilities weren't kept up to date in some cases.
The reality was that someone with roots moving a long distance for a job that may not last anyway isn't all that appealing. They knew this.
The big selling point of working at IBM for many at one time was the ability to work from home. But it's not surprising that employees were betrayed, they only had to look at their paychecks for the first clue.
I used to have weekly meeting with many members of a certain consulting company that basically was an excuse for billing the customer for a free breakfast while trying to get the newest customer member to volunteer for things that nobody else wanted to do.
My director sent me with an express order to not volunteer for anything and to ask for anything in writing. I stopped being invited rather quickly. The food was delicious and not a scrap was ever left. Meetings lasted just long enough to polish off the fare.
A simple "create table as select" is all you need to do first. At that point truncate or drop doesn't matter unless you're in an HA/DR or replication setting. If you don't want the backup table in your database, you can use datapump to export it to a file.
Truncate is helpful is the case of a table that you don't care if you recover and is very large or allocates a lot of space. In some cases the space claimed by a table is many empty extents while the actual space used is minimal. "Drop table including contents" will allow you to recover. "Delete from table" will not reclaim the space.
All of this presupposes the table had no constraints.
How I recall this was that Accenture was spun off from Andersen Consulting, not Andersen.
Legend has it that a lot of partnerships opened up right before Andersen folded. Based on the story below, it sure seems possible.
"Former Andersen partners lost the money they had put up for their partnership -- anywhere from $50,000 to more than $1 million. Many, including Bloom, had taken out loans to cover their partnership costs. Some borrowed enough to cover their partnership contribution for future years, never guessing Andersen's future would be in doubt."
I'd heard rumors before but it's the first I thought to look it up.
"As a result, around 50 per cent of its new hires have been hired in the past five years, and now half of its total workforce are millennials, according to Big Blue’s CEO Ginni Rometty."
That's fairly confusing. If I were hired five years ago, I somehow don't think I'd be a new hire. They must have outsourced the quotes and it lost a bit in the translation.
But the real elephant in the room is where they are hiring and where they are firing. So they fired 100K people making an average of 80K and hire the same number making 20k in Malaysia, India, Costa Rica etc.
I'm sure that should the verdict go against IBM they will keep keep appealing or come to a confidential settlement.
"Outside of the UK the only other country with a large non-digital service base is the US and there engineers are working a day free to save their jobs and agreeing terms and conditions reductions," Unite added."
That's hilarious, like they think any of that will save their jobs? Unemployment is very low in the US so they're either worthless to other employers or waiting for a buyout. Given that it's the US, they'll likely offer the minimum severance, a month or less.
No idea why anyone would work for them, IBM or any of the other sweat shops from overseas.
"I would caution anyone about the Oracle DB due to some nuances of it and the company supplying it."
I'm not sure what you're saying in the first part but the second part is a valid point. Let's stick with the first point. What nuances? The major ones I've run into are because some vendor or designer has not taken the time to understand that Oracle does a number of things very well and instead undertake to reinvent a rather shoddy wheel on their end. Case in point, a vendor decided to write their own concurrency model in the application with horrid results. Much of this is either due to porting from other DB platforms or simply not having Oracle expertise but expertise in some other platform that requires such gymnastics. There's another product that insists on their own implementation of a standby database for their commercial scheduling product, that's another horror story.
"Because once you deploy it you're going to struggle to extract yourself from it. Oracle know this and they will exploit it."
A number of vendors offer migration from Oracle. Microsoft has something called SSMA which handles this fairly nicely, DB2 offers Oracle compatibility and SAP has numerous tools to switch database platforms. There are others. Those tools wouldn't be there if there were no demand.
My current client has a dwindling number of Oracle databases, most left are forced to stay on Oracle because of the underlying application requirements, some are legal requirements for already phased out systems and a few are simply legacy uses being phased out.
But struggling to extract themselves from a vendor is exactly what cloud is about. Vendor lock in extends to that service as well. This goes a long way to explain why people don't want to get involved with Oracle, IBM, CA or others like them. Any organization that does not take into account backing out from a cloud agreement from a technical perspective is signing their life away.
"Like many other big iron and big software sellers, the product doesn't meet the hype. "
I thought the discussion was their cloud product but it seems to have gone off to their flagship database....Let's start there and circle back.
The Oracle database? As hideously expensive as it is, it's still a good product. As with any database software, it depends on applications written for it.
I suspect Oracle hasn't really been selling many new licenses for the database product for the last few years. So it's down to getting as much from licensing and offering applications to sell or host.
Sun hasn't quite panned out as envisioned, so getting a market share of cloud is quite important for the future survival of the company in the long term. The problem is that, like IBM, it's not offering a compelling product. Amazon, Microsoft and Google are eating their lunch and there's foreign competitors gearing up for big pushes globally.
I've also found that like IBM, Oracle left a bad taste in the mouths of their customers. When you run a business to make Wall St. happy every quarter, it may not be all that attractive for a discerning business to want to enter any long term agreements with them.
This same tactic was allegedly used in Australia and I dropped this on the leadership at my client to warn them of this.
"But there's a dark side to how Oracle is achieving some of those cloud revenues, a consultant tells Business Insider. It involves pressuring some of its customers to add cloud to their contracts that they neither want nor plan to use by using a tactic insiders call "the nuclear option."
The above link has much to do with VMWare but you get the idea. I'm sure there's a few more stories out there.
They do have a software module (IS-Utilities) aimed specifically at the market and the HANA marketing pitch does sound great. There's a fair amount of utility companies already using SAP, so this isn't as much of a reach as you would imagine. I'm sure SAP could scrape together a fair amount of references. (Texas Utilities/TXU or whatever they're called these days), a utility company in Tacoma, WA and the NY Power Authority are three that come to mind off the top of my head.
This is a specialized field. Only a handful of firms did this, including one I worked for in the US (Axon Global now sucked up by ATOS in the US). I also worked at Wipro on a very large account so I know a bit about both.
Wipro is a cheap alternative but you get what you pay for. They do have some good staff but they don't pay very well and as it's an overseas firm, not too many US workers, at least by comparison with the more expensive consultancies. That leads to a fair bit of turnover among the US workers especially when it's discovered that raises don't exist for the most part and greener pastures beckon. Much like IBM, really...
Much of my knowledge is of Wipro/Tata/et alios ad nauseam being brought in after either a budget cut by the client or as maintenance partners after implementation, so it's not quite fair to castigate them when IBM/PW and others (Accenture!) have has massive lawsuits due to much the same claims.
I did notice that Wipro tended to try to work with clients more flexibly than the US Big 4, it seems half the reason for some of the low estimates was to bill out fully on anything not explicitly named. (change Orders = Big Bux, dammit!) But I'm having a hard time seeing how the client allowed this stuff without testing. From the sound of it, some of these should have been caught in QA. So it's far more likely that some of this goes back to the client.
Databases are a commodity. Get used to it.
Oracle, like IBM, had the idea that they had great products that stood apart from others and couldn't be replaced.
Oracle pissed off SAP. They created a new database (HANA). Amazon has their own database products. when it's cheaper to move on from Oracle, people do.
Now they want people to transfer every two years? With what foundation of training on the new accounts?
Always keep in mind that IBM is basically a sales organization, this has the stench of getting higher salaried people to quit and replacing them with "new collar" workers. Technical people are simply replaceable cogs to a sales organization like IBM, they've been doing this for well over a decade, this is just another way to transfer the jobs overseas.
"The analyst described Big Blue's growth in its SIs as "very strong" but also noted criticism from investors that the "disposition and composition" of those tech areas was "discretionary and opaque, and executives have conceded in that part of the growth in SI has been a shift in revenues from 'old IBM'."
So basically the "Strategic Imperatives" are being propped up by other departments. Why would anyone trust a company who cannot honestly describe how they make money? This is how Enron worked.
We still use Notes for internal databases that are essentially places to put documentation and attach files. I'd first run into LN at my first company. My first impression was that it's fine middleware for databases like the above but a horrible mail client. My current company finally dumped LN email altogether and went to Google Mail about a year ago.
LN mail at my current site would silently and without warning wipe out blocks of mail. An entire week would disappear and never to return. It also had weird problems with cut and paste and could hang for minutes with no warning.
Vendor support? They would blame our site after a few weeks of being glad handed and repeated running through the same help desk scripts over and over again. IBM tried to convince damagement that they were developing a new version and that prolonged the agony by a few years.
I actually loved Lotus 1-2-3 but the current damagement always went for Excel. The one good product Lotus had that I swore by was Lotus Organizer. That never got improved past 2001 and eventually got replaced by WinOrganizer which is now free and no longer supported. But it works better than Lotus Organizer ever did. I suppose once WinOrganizer/Golden Sections stops working on Windows platforms, I'll have to go to something else like CherryTree. But as of now, WinOrganizer is still my database of choice for secure notes and documentation on an individual level.
IBM, like CA and likely HCL is a place where decent software goes to die.
Don't be silly, they don't want people with a track record of being able to adapt and learn new technologies, that's expensive. They want "new collar" people who are cheap, replaceable and will spare them the trouble by leaving as soon as "IBM" is on their resumes. That way they can hire Elbonians to replace them.
It's all about head count at this point. Maybe they ran out of technical people they could off shore and they're finally going after the middle managers and what they can below that level.
The problem is that IBM cannot run low margin services due to their overhead and can't deliver on the vanishing high margin ones.
What does this amount to? Let's start a list!
1. It will stop the customer from being able to blame one or the other, now they get to blame one group that will promptly devolve into internecine fighting that allows them to bill the customer more.
IBM Marketing: Anything to obfuscate what we can't deliver.
The last time I'd talked to them, I had a contract all signed and I ready to start. They changed the terms on me a week ahead of time and sent over the paperwork to the contracting shop I went through. Needless to say, I never signed and never showed. When they called, I told them I'd already taken another contract and for more money.
The kicker was that they called me a few more times. I always quoted rates that were 30% higher because it was IBM.
That's not just IBM, it's most large consulting companies. It's not all their fault, I've dealt with government customers at the state level and they all have some basic issues that are part of their basic makeup.
1. Their systems are poorly maintained and often outsourced to the cheapest vendor.
2. While the bureaucracy is entrenched, the political climate is subject to wild changes at any time.
3. Nobody is willing to take charge in a large project.
4. They have no idea of the scope or their own systems and have no experience negotiating this type of thing.
5. These fools wanted to use *proprietary* databases? That implies choosing hardware and software that's also just as proprietary. Locking yourself into the tender mercies of IBM is a very bad idea.
6. Allowing a negotiation to go on for three years?
That said, IBM is a horrid employer and their track record on large projects and outsourcing is terrible for a number of reasons:
1. Even the slightest revision of a specification is an "opportunity" to bill extra.
2. They roll in good people at the start and they will roll out to be replaced by whatever they can get cheaply. (They always seem to be losing money on a project from day one.)
3. There's a ridiculous amount of overhead that is part of any project, these guys are more top heavy than most.
4. IBM has become an employer to avoid in the US. People are constantly being pushed out the door and replaced with inexperienced people from some other part of the planet. Imagine being billed for someone experienced at 250 an hour and having him replaced by someone in Malaysia with zero experience. It happens.
5. People to fix troubled projects are becoming fewer and fewer and they are stretched thin. They're also deployed too late. IBM has lost a lot of contracts that way. There are many documented instances of their long term contracts that never get to the end of the contract without being cancelled or penalized. (Easy enough to find.)
Biting the hand that feeds IT © 1998–2020