Short-term profitability at the expense of long-term growth

October 30th, 2013

There's a BBS I visit where they have a thread "Bump this up every time a game developer cuts staff after a release." So I decided to add my own take on the subject of companies cutting staff even when they've had a good year. So here it goes:

In this article it mentions that Thompson Reuters reported stronger-than-expected financial results for the third quarter of 2013, but it's going to spend about $350 million in severance and other costs to lay off about 5% of its workforce, or about 3,500 people in its risk and finance divisions because those are weak performing sectors of the company.

What I find interesting is too many companies, when they have what they deem to be "surplus" people, are, instead of looking at new potential markets and products and services they could be offering, and using those people to develop those new products and services, immediately go for the fast buck by layoffs and staff cuts. I notice it's always the "little" people who get cut, the people who make around $20-$50,000 who are given severance packages or just simply dumped en masse, but it's almost never the executives with multi-million dollar compensation packages that these companies try to reduce.

This goes right along with companies that have decided that if you've been out of work for six months they will not hire you, and they won't hire people who have credit problems because they had large medical bills. Which really makes a lot of sense, don't hire someone who has no job because that allows them to get out of their problem and gives them the ability to do productive work, and don't hire someone who was out of work and has credit problems because they couldn't pay their medical bills, hiring them might allow them to actually now have an income and pay their bills!

Farmers have an expression for the exclusive focus on short-term income increases being done at the expense of long-term profitability and potential long-term growth: "eating the seed corn." If you don't save for investment and invest in the long term, eventually you'll have nothing. And do we wonder why people steal from cheap-jack employers like Walmart? (Not that that is a good idea either, because now you're having to spend more money on security and loss-prevention, plus if you start to get dishonest employees then the culture of dishonesty tarnishes the whole enterprise. The presence of rotten apples does spoil the whole bunch. Then the others either resent that they've been suckers by being honest and not getting their "fair share" of "honest graft," or they despise themselves for being dishonest. Or worse, they don't even care that they're dishonest and the corruption is so bad the company rots from the inside out. Requiem en Pace, Enron.)

You compare a company like Walmart to a place like Costco, which pays better than average wages, has better treatment of employees, has discovered they have lower turnover, less employee theft and their profitability can often be equal to or greater than that of much larger competitors. You can't fake this stuff, when the company cares about its people, it shows, and people respond when they see that their employer does care. The Hawthorne Experiments conducted by Western Electric back in the 1920s confirmed this. Management concern for employees increases employee efficiency and makes them better workers.

Ford Motor Company decided to try something. It used to be that the emergency stop button for the assembly line for cars was placed about every 20 stations, and woe to you if you shut down the line for anything short of someone about to lose their arm or get beheaded. So Ford did something unheard of. They put the stop and start button at every workstation! And the employees use them! Hundreds of times a day, workers stop and start the line, and what is it for, usually for a second or two, maybe 3 or 4 seconds, because they need just a tiny amount of extra time to tighten a bolt or to get a piece inserted correctly. The company "loses" about 5 minutes of production time a day. But the quality of the product went up dramatically and worker complaints and grievances dropped.

I wish companies like Walmart would stop lying in their advertisements and trying to make themselves look like they care about employees. Their practices put paid to these claims. They're interested in just two things, how much in short-term revenue increases they can generate and how they can get away with paying people as little as possible, up to and including breaking the law to do it by hiding what they're up to or intentionally underpaying people in any way they can, legal or otherwise. Plus their employees are starting to realize the employer doesn't care about them at all and if it could run the place with 100% automation and unceremoniously jettison every employee, they would.

I read requests for bids from various public agencies because the stuff they're looking for tells me what buyers actually want in software packages, not what I think they want but the features they need to do what they need to do, or to convert what are excessively manual-based systems over to computerized ones. This allows them to get more done and allows them to scale up operations. When a bus company can implement a voice-activated or touch-tone controlled system for schedule information, this doesn't mean they cut all the information operators, it means they can have them do other things, and chances are, now, if you need a live operator you can get one in less than a minute instead of sitting on hold for 20 minutes waiting for an operator to get free. And often the automated system gives you faster results for routine queries.

Discovering what potential customers really want means you have the capacity to solve their needs, and when you can do that, you can make a lot of money. But you have to have good, motivated people to implement these solutions. And in some cases the ideas can come out of the strangest places.

An undertaker by the name of Strowger was unhappy because he felt that his business was suffering because when people called the operator asking for his mortuary that the operators might be taking bribes to divert his calls to other funeral homes. So Strowger, who had no experience in telephony, sat down and figured out how to build an automated switch that allowed people to dial their own phone calls directly. Strowger's invention came at just the right time, because in the early 1930s, phone companies were having problems scaling up as more customers were making more phone calls and it was getting harder to hire more and more operators, eventually you'd have to hire almost everyone to handle the call volumes. And in a way, that's what they did. Now, we all make our calls self-service by dialing them ourselves, we get better performance (because we can have things like memory dialing where you can program the number into the phone) and the results are faster.

With automatic dialing it's made phone service much cheaper since they have lower labor costs. And those people that don't have to be phone operators are doing other things. Possibly providing new products and services that are more valuable. Strowger was a special case of someone not in the industry inventing something desperately needed at just the right time; one of the biggest wins at 3M was the guy who invented Post-it notes.

But the excessive focus on short-term profitability at the expense of long-term growth means we'll never know what could have been. We'll never see the new software applications that weren't developed and we'll never know about what doesn't exist. The large amounts of money made long term from new revenue streams and new development will never appear when we don't think long term, but only go for short-term increases in profitability and what are essentially quick-buck schemes.

The Business of Software: U.S. v. Oracle

October 21st, 2013

Anyone who cares to discover how the software industry sells high-end software, should read the appellate transcript in the Antitrust case of United States of America, et. al. v. Oracle Corporation, which, in plain language, explains in great detail about software sales in general and about those made to large companies.

This was an antitrust case where Oracle wanted to purchase PeopleSoft Corporation in order to get its eponymous software code base (and customers) and integrate it into its own offerings. The U.S. Government and some states sued Oracle to stop the sale. The district court found at trial in favor of Oracle, since, in an antitrust case, the burden falls on the plaintiff - the Government, in this case - to prove the sale is injurious to competition. The government appealed the decision. The Appeals court upheld the trial court's decision that the U.S. Government had failed to meet its burden of proving that Oracle's attempt to buy PeopleSoft would be injurious to competition in violation of Section 7 of the Clayton Antitrust Act.

While the full decision itself is a highly technical discussion of antitrust law and runs 75 pages, the first 8 pages discuss the software industry in general and high-value software such as the products Oracle and Peoplesoft sold in competition with each other in particular. These included products for "enterprise application software" such as Enterprise Resource Planning, And it mentions how Oracle and Peoplesoft were not the only players in that market, not only does SAP sell a product in this venue, so do Lawson, AMS and Microsoft. But even if you know software, I think the court's explanations are very interesting.

So, in the end, unlike the case of U.S. v. H&R Block, Inc., in which the court decided that it would damage competition to allow H&R Block to purchase the company that made the TaxAct program (which competes with H&R Block's offering) and denied that sale because the only other serious competitor in the tax preparation software business to the combined H&R Block/Taxact combination left would be Intuit (the owner of Quicken), which makes Turbo Tax, the court found that the government failed to prove that Oracle's purchase of PeopleSoft violates either the Sherman or Clayton antitrust acts and allowed the sale to be completed.

Why would you need to know if you're on 64-bit Windows in a 32-bit application?

April 10th, 2013

I was doing a lookup on-line to find out if there's a programmable way to determine if the version of Windows the program is running on is 32-bit (Win 95, 98, NT, XP, Possibly Vista and higher, I'm not sure) or 64-bit (XP, Vista, 7, 8). Now, you can do a hardware test to determine if the processor is 32- or 64-bit, it takes a half-dozen instructions in x86 Assembler, but you have to find a way to query the operating system to determine if it supports 64-bit applications.

On one forum, someone asked a simple question, "Why would you want to know if you're on 64-bit windows if you're a 32-bit application?" Someone compared it to wanting to know if the computer was running, or the power was on, or some other facetious explanation. Well, if your application is 64-bit, you would know, because it has to be on a 64-bit machine running a 64-bit operating system, but if your application is 32-bit, the underlying operating system, and machine, could be 32- or 64-bit. I am writing this message on a 64-bit machine running 64-bit Windows 7, but my other machine is a 64-bit machine running 32-bit Windows XP professional. I have a computer in the closet that I bought probably more than ten years ago, to see if there was a difference, it's a 64-bit machine running Windows 98. (At the time, I think I was considering running a 64-bit version of Linux.)

Now, if the processor itself is 64-bit, you could, if you did the proper preparatory code, write an application that has 64-bit machine instructions that checks to see if the processor is 64-bit, but the application itself must be written as a 32-bit one if it's to run on both 32-bit and 64-bit Windows. And being able to have a hybrid application that is, as far as the operating system is concerned, a 32-bit application but internally it provides 64-bit instructions on a processor that can support them to improve performance, would require a really good compiler that provides both 32- and 64-bit runtime libraries to give the program the ability to take advantage of faster operations on a 64-bit machine. Most applications are not hybrid (or maybe schizophrenic is a better description), they are either a 32-bit application in all cases, or they are a 64-bit application. The 32-bit can run on any processor, the 64-bit requires both a 64-bit processor and a 64-bit operating system.

I think the answer on how to determine if you have 64-bit Windows was to see if your application is running under the WOW system - which I didn't even know existed until a few days ago and only partially - which is a shim to allow 32-bit applications to run on 64-bit windows, with some exceptions. One such exception is you can't call native 64-bit code such as DLLs which are 64-bit, and 64-bit applications or DLLs can't call code in your DLLs. I think the shim does some magic so your calls to KERNEL.DLL and other system libraries are handled, I'm not sure what.

I know that a similar practice was used to handle 16-bit applications on Windows 95 as well as native 32-bit applications, there were basically two versions of the operating system on Windows 95, the DLLs for 16-bit applications had the same names as they did under Windows 3.1, handling the functionality available for 16-bit machines. The same kind of restrictions to allow a 16-bit application to run under 32-bit windows were in effect as are being required for running 32-bit ones on 64-bit. If you had a 16-bit application you could only call it from a 32-bit application by starting it as a separate program with parameters in the command line, or if you wanted to do something while it was running, you'd send it messages via DDE; I did this with Novell Groupwise for a customer who used it as their e-mail system; my program would compose an e-mail message and "fire blind" in which it would start up Groupwise and then send DDE commands to it to compose the message and include a ZIP file in their message as an attachment.

And I can tell you exactly you'd want to know if your (32-bit) application was running on either a 32-bit version of Windows or a 64-bit vesion. For the exact same reason I wanted to know. So that you can build versions of your application to run natively as 32- or 64-bit on that particular operating system, but only have to develop a single installer, written as a 32-bit application, that will install a 32-bit only application under 32-bit Windows, and under 64-bit Windows (and possibly 128-bit, when the hardware and software become available), you can install the 64-bit version of your application (or optionally install the 32-bit one instead if there's a reason for the user to want or need to do so). But the installer itself will run on either platform, it just installs the version of the application which is aligned with the bit capacity of the machine being installed upon.

Or go further, if you can't use a 32-bit installer to install a 64-bit program, then your pre-installer can be like a self-extracting archive that contains the 32-bit installer, a 32-bit version of the application, a 64-bit installer and a 64-bit version of the installation, the pre-installer unpacks the 32-bit installer and application on a 32-bit operating system, unpacks the 64-bit one on a 64-bit operating system, then transfers control to it and quits. Or the pre-installer is a downloader that goes out to the web and downloads either the 32-bit or 64-bit version, then once it's downloaded it executes the actual installer and quits. But the pre-installer would have to be a 32-bit application no matter what machine it runs on, while the installed application would be 32-bit on 32-bit Windows, and could be a 64-bit application only on 64-bit Windows.

And that's a reason to want to know whether you're running on a 64-bit operating system or a 32-bit operating system, even when your application is 32-bit.

GM to add about 10,000 IT employees

September 23rd, 2012

An article on Dice.com notes that General Motors will add as many as 10,000 Information Technology workers over the next two or three years as it starts insourcing a lot of its technology work to gain more control, and ending a number of third-party contracts. One thing the article notes is a big loser will be EDS, which GM had a $7 billion contract it signed with them when it was acquired by HP back in 2006. What the article didn't mention was whom HP acquired EDS from. General Motors, who bought it from its founder and sole owner H. Ross Perot years earlier, for a lot of money and stock and a seat on the board of GM.

Perot started snooping around and asking questions, and so GM's president, Roger Smith, got so pissed off at Perot asking why GM was acting so stupidly, gave Perot an additional $800 million in cash to go away and leave them alone!

This changed my entire reason for being

August 6th, 2011

The following article was posted to Amazon.com back during April regarding a purchase of ink for my HP printer.

This review is from: HP 901 Officejet Ink Cartridge in Retail Packaging (CC653AN) (Electronics)

Just having bought one of the HP black ink cartridges, I now realize that I had been living a cloistered life of irrelevance. I have come out of the light of blank paper, and into the dark of true black ink. I have experienced an epiphany, a true realization of the meaning of life. Either that, or the crack I just smoked has finally kicked in.