Archives for posts with tag: Hardware

I, Cringely » Blog Archive Not your father’s IBM ~ I, Cringely – Cringely on technology:
http://www.cringely.com/2012/04/not-your-fathers-IBM/

The article covers some interesting views on IBM, and insights that extend much broader than IBM.

It’s a prediction of failure for iBM’s plans to grow earnings-per-share, and his conclusion that the result will be a failure. He make a very good case for this.

He shared a good quote from Steve Jobs about big companies that grow into a monopoly position. They can’t get more market share, and doing a better product can’t make them more profits. The people running them become sales and marketing people.

This is the first thing to understand about the IBM of today: the company is being run by executives who for the most part don’t understand the products and services they sell.  The IBM of today is a sales organization.  There is nothing wrong with sales if you can also deliver, but increasingly IBM can’t deliver.

He goes on to quote Jobs again specific about IBM:

The reason IBM can’t deliver is also explained well by Steve Jobs. It’s IBM’s maniacal fixation on process, once a strength but now a cancer.

Companies get confused,” Jobs told me.  “When they start getting bigger they want to replicate their initial success. And a lot of them think well somehow there is some magic in the process of how that success was created so they start to try to institutionalize process across the company.  And before very long people get very confused that the process is the content.  And that’s ultimately the downfall of IBM.  IBM has the best process people in the world.  They just forgot about the content.”

In this instance content means the deliverable, whether a product or service. IBM smugly thinks it knows so well how to do things that they can export their entire business model to cheaper labor forces in less expensive places to do business. While this is correct to a very limited extent it has been embraced as religion in Armonk.

Like he says, Global Services is IBM’s biggest money maker but they’re losing customers.

In another article Cringely showcased two companies in Memphis that replaced IBM’s outsourced services with its own employees and used a local company to monitor its services to prevent outages, one of those companies having had an outage that IBM discovered only when it was reported..

The read is worth it:

http://www.cringely.com/2012/04/not-your-fathers-IBM/

Advertisements
IBM i

IBM i (Photo credit: Wikipedia)

I work every day on a mixed code bag, including code written in the 1980s in one of the oldest known programming languages. Really out-dated stuff, what’s known as RPG-II. It was designed for the IBM System/34 and was the main coding language used on the IBM System/36 as well.

HP and Wang made their own RPG compilers to offer a way to pull customers away from IBM, but they apparently mostly quit trying after IBM brought out the System/38 and then the AS/400, the business system that blew DEC’s rival system and HP’s special ‘midrange’ into history. We who have worked on these IBM midrange systems -IBM now calls it “midmarket”– never could understand why everybody didn’t want to go out immediately and move their business to the most stable and secure-able system available so we always blamed IBM for hiding it and hiding their advertising budget from it, presumably to protect their lucrative mainframe business.

I”ve been through major upgrades and conversions of software from one base to another.

But at a lower level than that, I’ve considered different factors relating to program changes. The code base that’s so old for example, could benefit from a major overhaul and conversion to a more modern code base that could cut down drastically on both code change costs (in hours) and reduce the program halts that haunt ancient code bases that have gone through patches, fixes, more patches, enhancements and modifications over longer than the lifetime of the younger developers among us.

Programmers are generally attracted to “refactoring” old code, but it’s a bad word to CIO’s and managers who imagine all the kinks that occur with implementing changes and new code.

But we can minimize the pain of damages. I’ve thought of some things that make life easier to code changers and projects in general.

(1) Gosh, guys, get a good code analyzer! They’re around, and yes, the IBM i world has them too. Maybe especially. On the IBM i, for example, there are some that drill down into your code and claim to come close to extracting your business rules, identifying unused “orphan” code, and even maybe suggesting possible improvements. They exist even for COBOL code, but believe that these are not quite as thorough or detailed as the ones for RPG, understandable, but they’re more than nothing.

(2) We can minimize the disruption of changes.

We can make changes by steps, unless it’s a major difference in business rules, no way around that. But for changes that fall short of that, you don’t have to change all the menus and programs at once, change them a bit at a time. That saves money and nerves for the users and provides a proving ground for the changes, and helps dampen user complaints, which usually come from users who get comfortable, often with good reason, doing their jobs a certain way and have a hard time with the new stuff.

Y2K is an example. The best change-overs were either completely invisible, or moved smoothly into four-digit years. That project was so good the world scratched their heads and wondered what the fuss was about, and they thought maybe we had pulled a big scam on them. There was even a line on one of the Star Trek shows (or was it a movie) where an predecessor to Captain Jane wondered aloud whether there was really a problem.

Of course we coders know we saved their behinds!