IT grumble thread

Printable View

November 17th, 2008, 09:41 AM
Hobson

IT grumble thread

This post was posted by me as an OT reply of another thread: http://www.codeguru.com/forum/showthread.php?t=465416

As I do not want to make CPUWizard's thread totally offtopic, I want you to complain about silly things you encounter in IT here. Any discussion (in case I rant with no reason or because of some kind of ignorance on my side) is welcome!

I think that we need to introduce new measurement of software quality: it would be expressed in percentage of cases it works correctly. Like, you know: "This Windows XP is whole heavelny 98% good! Not that [bad word] 50% Windows 98 was!" or "This new Java Enterprise Server is just lousy 70%'er, I had problems configurating it on 2 machines, and I can't get some stuff to work on remaining ones". I think you get the idea. It's just because nowadays, when silicon is cheap, mass storage is really massive, and so on, the only things that grow are system requirements and advertisement folders for new software. Quality drops dead, "brand-new, improved, easy to configure and deploy software which makes your industry running on top levels" is usually slow, unconfigurable, undeployable, expensive. Or, is that just me?
And tell me, what is the difference in FUNCTIONALITY, ERGONOMY and USABILITY between Word '97 and Word TheNewestOne, which justifies tens to hundreds times bigger minimal requirements?

Doh, I could go with this for hours...

My next post in this thread will be about XML abuse, i think :) Or, any of you may go with it.
November 17th, 2008, 10:10 AM
TheCPUWizard

Re: IT grumble thread

This is perhaps the most important topic in software development!!!!!

At the MVP [Microsoft Most Valued Processional] Summit this past April, there was a panel discussion which went into "What is Software Quality???". Many people have differing areas to focus on.

The easiest was the sub-topic:

Quote:

It's just because nowadays, when silicon is cheap, mass storage is really massive, and so on, the only things that grow are system requirements

The measure MUST be "Cost", which encompases both time and money. Even for the hobbiest, this applies (I am not going to "xxx" because I want to finish a program).

I remember well the days (early 1970's) where it was a REQUIREMENT to spend days or weeks to shrink a piece of code by a few bytes or clock cycles. [machines with clock speeds of 250Khz (yes, KiloHertz) and 4K of memory (TOTAL 4096 BYTES), that cost >$100,000 [US] in 1970's dollars].

This is obviously not worthwhile today. This does not excuse "sloppy" programming, but does mean that "hardware requirements" are fairly far down on the priority list. For example to bring in 1 consultant for 6 months to "optimize" a system may easily cost upwards of $300,000 [US]. If a $1000 hardware upgrade could achieve the same goal, and there are <300 machines which will be running the application, then it is obviously a "losing proposition". Even if the initial numbers "work", one must look at the longer range (Optimization dollars are spent and gone, but hardware upgrades are inevitable and constantly dropping in price).

The "Vista experience" illustrates this perfectly. People complain that it does not run well on older or extreme low end machines. Well, neither did XP, 98, 95, 3.1, or 2.0!!!! A program must be developed based on the expected capabilities over the life of a product. Now, nearly two years after Vista's release [1/25/2007], the majority of "off-the-shelf" machines are fully capable, and we are less than two years into the 5+ year lifespan [ending 4/10/2012].

....to be continued....
November 17th, 2008, 10:29 AM
TheCPUWizard

Re: IT grumble thread

Quote:

Originally Posted by Hobson

Quality drops dead, "brand-new, improved, easy to configure and deploy software which makes your industry running on top levels" is usually slow, unconfigurable, undeployable, expensive. Or, is that just me?

A "Dip" in quality is expected for anything "new" versus something "proven". This is not unique to software/computers.

The first cars where much less reliable than a trusty horse, and the analogy could be repeated with thousands of similar cases.

The "trick" is to choos the proper time to "embrace" a new technology, and to understand the ramifications.

I would much rather install a new device on a Windows Vista machine, than on a DEC PDP-11 (which required an 18+ hour rebuild of the operating system).

On the specific points:
a) Slow - Are you using the appropriate hardware?
b) Unconfigurable - actually most programs today are HIGHLY configurable.
c) Undeployable - I have not experinced this?
d) Expensive - Based on WHAT? One of the items I love to point out is that [based on numbers in the US], Gasoline prices at the $2.50 level in 2008 are the less expensive than prices were 35 years ago [calculate how many hours you had to work in order to pay for fuel for a 1,000 mile trip...]

Quote:

And tell me, what is the difference in FUNCTIONALITY, ERGONOMY and USABILITY between Word '97 and Word TheNewestOne, which justifies tens to hundreds times bigger minimal requirements?

Hopefully this is somewhat "tongue-in cheek".

On the "system requirements" front, the Office suite has actually decreased with viewed as a percentage of typical system resources, and also in terms of $$$ required to purchase an adequate system.

On the Functionallity, items such as VSTO would have been impossible with Office 97 or even Office 2000.

Even more important (and requiring a lot of new code inside the applications) is th transition of a "Open Specification" for the file formats (e.g. docx). For the first time a developer has a means of creating, modifying, or just reading information stored in Office Documents that is both supported, and does not require Office to be installed. Until this was available [new in '07], it was impossible to create a server application which manipluated office documents in a legal and supported fashion without a MAJOR investment. (The only supported way was to use the Office Object Model, requiring Office to be installed, and the EULA specifically prohibited installing Office in a server environment.)

On ergonomics and usability (definately the most subjective of the items mentioned), studies have repeatly shown that (neglecting the "dip" of experienced people transitioning) the '07 UI is more efficient. To measure this, one needs to give a complex document requirement to two people neither of whom have ever seen/used Office, then compare the results between '07 and '97....
November 17th, 2008, 12:18 PM
Hobson

Re: IT grumble thread

First of all, I want to point out that I am young person, with 4 year experience in software development as a code monkey and about 12 years of total computer usage (home + games + shool + work), so there is fair chance that my points are way off, but still I would appreciate you to improve my understanding about some things I have no idea about.

Quote:

Originally Posted by TheCPUWizard

The "trick" is to choose the proper time to "embrace" a new technology, and to understand the ramifications.

Yes, of course. As a software user, I would be really very glad if I could CHOOSE the time when I want to embrace to new technology, when I feel I am ready.

The problem is, that because of things which are not directly related to technology, I just can't. Yes, first car created by Henry Ford could be really much

worse than a good horse. But he did not tell: "People, for ten years I have been selling horses, and you were buying them. Now I got another idea, I will sell cars. In six months I will stop selling horse food, and your horses will die. Then, get a car, or have nothing". Please, tell me that you see analogy :)
New usually means better for newcomers, but not always better for me.

My example with MS Office was a bit exaggerated, mostly because I used name "Office" as a general name for a well-known product which a lot of people uses. But still, point is the same. I did not say that new versions of software are not better than old ones. I just mean that they are not THAT MUCH better as they are more resource hungry. In most cases adding new functionality to some office software is to add more menus and command buttons. New version of software has much more buttons than previous one, true. It is much more functional, yes. But does this justify significant increase of systm requirements?
To be fair, I admit that most of MS software I used in ~2005 and today went the good way in terms of performance.

Quote:

Originally Posted by TheCPUWizard

actually most programs today are HIGHLY configurable.

If by "configurable" you mean "possible to tune and precisely set each possible value" then you are right. What I meant that it is difficult to set it up to work as I want. How many times happened that anyone of you wanted to change some setting on server, configure web service, set appropriate compiler flags, and just could not, it did not work, or could not find out how/where do this? Or maybe I am just lame? (which I do not tell is impossible :) )

Quote:

Originally Posted by TheCPUWizard

Undeployable - I have not experinced this?

You are a lucky man then. If I just could count the hours I spent wondering why fully portable portlet (as manufacturer claims) portlet would work correctly on Server 8.0.1 but not on Server 8.1.5 or AnotherServer.

Quote:

Originally Posted by TheCPUWizard

On ergonomics and usability (definately the most subjective of the items mentioned), studies have repeatly shown that (neglecting the "dip" of experienced people transitioning) the '07 UI is more efficient. To measure this, one needs to give a complex document requirement to two people neither of whom have ever seen/used Office, then compare the results between '07 and '97....

You are right, but I do not think that it is due to (thanks to) requirements increased so significantly. It's just better user feedbakc, psychology research, etc. And let's just assume I do not mean speciffically Office, I am trying to describe a trend in software development I noticed.

Other thing which bugs me is that not some time ago, when progress in silicon technology was going extremally fast, noone cared about increased requirements, because it was cheaper to buy more memory than work on optimizations. Requirements were raising and raising, util progress slown down. Today we are in the point where you cannot boost up CPU clock speed anymore, because CPU will melt down, and so on. you can not increase RAM, because you cannot put more than 4GB in your desktop machine without replacing it. And what happens? All of a sudden new version of software does not need so much resources! So did it really need before?

I will post some more thoughts later. Writing in English is somewhat difficult to me when I try hard not to sound like an idiot :) I hope I succeed at least a little bit.

Cheers,
Hob
November 17th, 2008, 01:19 PM
TheCPUWizard

Re: IT grumble thread

1) There has never been an issue with your English, or sounding like an idiot :wave:

2) Regarding youth....An old song contained the Lyrics:

Quote:

In-experience it once had cursed me,
But your youth is no haqndicap, it's what makes you thirsty"

and from the same song

Quote:

Just write about YOUR "experience", not some things you never did

I started programming at the age of 13 [in 1972 when many colleges did NOT even have "Computer Programming" degrees, and the majority of degreed people had never used a computer]

3) You are correct about limits on CPU clock speed. But this is the exact reason I created the thread about designing for parallization. Since you can go to the store TODAY and buy an 8 "processor" [Quad-Core (i7) which will handle 6x 8GB DDR3 ram modules [48GB max ram - on a TRI (not dual) channel bus - WITHOUT FSB limitations] the ability to "scale-out" is of prime importance.

4) Timing of "Choosing" to upgrade/embrace. The timing is not so fast as you seem to think. The lifecycles for all Microsoft products (other major vendors have similar documents) is very public. It is all about PLANNING (which too few people do in life and instead react after the fact).

Look at the numbers for Visual Basic:

Code:

2002 Standard Edition 4/15/2002 7/10/2007 2003 Standard Edition 7/10/2003 10/14/2008 2005 Express Edition 1/14/2006 4/12/2011 2008 Express Edition 2/19/2008 (will end two years after the next version) 6.0 Enterprise Edition 1/27/1999 3/31/2005

(btw: the dates are nearly identical for VC++)
So from the time 2002 was released, 6.0 users had (almost) 3 years to prepare for the departure of 6.0. Even 2003 users had 20 months to prepare.

Now more than 3.5 years AFTER 6.0 was retired, look at how many people are still considering (almost 7+ year old) VB.NET as "new"...:rolleyes:

ps:
* Model-A 1903 through 1904 with two sequetial models (Service Packs!)
* Model B was replaced the Model A in 1904
* The Model B was replaced by the Ford Model C during 1904
* 1904-1909 saw the F,K,N,S, and R models.
* Model T stopped production in 1927

NO additional parts were manufactured for any of the models once production has ceased. The only source was unsold parts,used/salvaged parts, or homemade (I have an Uncle who has a Model-A, Model-T and a Stanley Steamer, as well as a 1909 Sears [yes the company that exists today was a mimarily hardware store originally sold cars...and...homes]

So here we have a complete evolution of models with many new/obsolete/new/obsolete cycles in 5 years, and a completion of 9 major versions of vehicle in 24 years.

"Visual" has had 10 major releases between 1992 and 2010 (18 years)....not that much faster....