BLASTED E-Tools! I wasted money on THIS!?

[MeepoTheMighty]

Its other gaping problem is NO DOCUMENTATION. None. PGen at least has a set of documents that works. E-Tools doesn't have anything, not even buttons that explain themselves when the mouse glides over them. In many ways it seems like an in-house editor, more beta than finished product. In fact I gather that the 'patch' includes more new features than it does fixes, possibly because they were in the pipe when the program went gold.

Huh? I thought it had help files written by our own Eric Noah. Then again, I don't have the program, so I'm just going on hearsay here...

 

[AegisEversoaring]

From someone who helps develop software...

The software development cycle may be the problem, not the Quality Control process. Many times retailers are promised products many months in advance so deadlines can be met, advertising can be put into place, etc. When a product runs into problems during its development, the schedule does not change. The delivery dates to retailers stay the same, the ads still get printed, etc. Almost all of the major retailers penalize software makers for delivering products late, with the penalties cutting huge chunks out of projected revenue.
To compensate for slipping schedules and delays, features get cut from the product, and quality control is often pushed to the side. The most important issue for many software developers is to develop software on time, so they can get the payments they are due. The successful companies get their titles on the shelf, fairly clean, and on time. Other companies fail miserably at doing so.
I tend to think that quality control noticed the same issues that everyone else has. I spent close to eight years assisting in the development of entertainment software titles, and many times we had to ship products that weren't clean and bug free because there was a deadline involving a retailer. If Wal-Mart or a major toy retailer calls the software publisher and says, "If we don't get product XYZ by the 21st, we will cut your payment by 20%." What do you think will happen next?
The product gets shipped, with bugs and missing features.

Aegis

 

[Hollywood]

Re: From someone who helps develop software...

While I agree with you for the most part, its not the software development cycle that causes the problems, its the project management. And part of project management is managing scope and scope creap and to make sure a project gets out the door with all phases of software development cycle covered. Unfortunately, as you note, it doesn't happen very often because publishers generally overstate what the product will do, make ridiculous commitments that can't be kept and then also expect to scope to expand, never to contract.

The software development cycle may be the problem, not the Quality Control process. Many times retailers are promised products many months in advance so deadlines can be met, advertising can be put into place, etc. When a product runs into problems during its development, the schedule does not change. The delivery dates to retailers stay the same, the ads still get printed, etc. Almost all of the major retailers penalize software makers for delivering products late, with the penalties cutting huge chunks out of projected revenue.

 

[Fast Learner]

I suggest that bugs are, in fact, the fault of poor QA, every single time.

Lack of time to implement good QA, however, is a problem with either:

(a) project management (day to day task management and scheduling), or

(b) program management (overall schedules, scope creep issues, etc.), or possibly

(c) bad programming practices/methodology (QA isn't part of a daily build and smoke test, but is instead performed long after the bugs appear, for example).

Still comes down to bad QA, but yeah, the reason for bad QA could be several things.

 

[Malhavoc]

Does anyone else keep thinking of Dilbert whenever this stuff comes up?


I know I do.


And I laugh.


Haha, silly Wally.


........I'll go now.

 

[Hollywood]

Originally posted by Fast Learner It's software. Currently the creation of software is an immature science, aka the effort currently required to release a perfect, 100% bug-free application is far, far too high to be able to charge a reasonable price.

Gotta disagree with you there FL. The "science" of software engineering is not all that immature. At its roots can be applied the same engineering principles as all other engineering disciplines. Since engineering, like software engineering, is a constantly evolving process, it will never be mature and therefore it really can't be considered immature since it can't mature. Schemanics aside, nothing is prefect and no software or engineering feat will ever be 100% bug-free. And this will only become more true as the complexity of engineering increases far into the future.

Its not out of the realm of reasonable price to produce software that is relatively bug free. Especially at the level of complexity of say eTools, which in comparison with the breadth of consumer software, is a fairly uncomplex piece of software.

 

[Hollywood]

Part of the problem was the changes of directions while the program was being written, part of the problem was time wasted on bells and whistles that ended up being discarded. I was on the Mastertools mailing list and kept cringing when I saw things like sounds and 3-D monster pictures were being added.

Yes, I did too... to me they were literally trying to produce their own version of NWN which took a lot more man-hours to produce than Fluid was going to be able to provide.

 

[AegisEversoaring]

I suggest that bugs are, in fact, the fault of poor QA, every single time.

Lack of time to implement good QA, however, is a problem with either:

(a) project management (day to day task management and scheduling), or

(b) program management (overall schedules, scope creep issues, etc.), or possibly

(c) bad programming practices/methodology (QA isn't part of a daily build and smoke test, but is instead performed long after the bugs appear, for example).

Still comes down to bad QA, but yeah, the reason for bad QA could be several things.

QA is seldom factored into the process at an early level where they can affect changes on the product. Typically a QA department (or external test house, or beta test group) will see a build of the product very late in the development process. Their goal is to catch bugs mainly, the obvious ones primarily, and provide data for the technical support teams. The other factor is testing software is not the highest-paying position on the development team. One prominent firm used to invite the local high school computer club over to their labs, and pay them in pizza and a copy of the game as payment for testing their products!
Entertainment software is a multi-billion dollar business. Most of the revenue comes from products that are sitting on the shelves when the holiday season starts. The goal of just about every entertainment software company is to get their products on the shelf in that four month holiday window. The difference in sales for missing that window is staggering. The companies will do whatever it takes, quality be damned, to get their products on the shelf before November.
The mission becomes clear, get something on the shelf before November, or you will lose a large amount of revenue. The consumer is the one who suffers most, as we wind up with substandard products every time.
This seems to be the case with e-Tools, it has all the classic earmarks of a product rushed out the door to meet a deadline.

Aegis

 

[Fast Learner]

OT Software Maturity Continued

Gotta disagree with you there FL. The "science" of software engineering is not all that immature. At its roots can be applied the same engineering principles as all other engineering disciplines. Since engineering, like software engineering, is a constantly evolving process, it will never be mature and therefore it really can't be considered immature since it can't mature. Schemanics aside, nothing is prefect and no software or engineering feat will ever be 100% bug-free. And this will only become more true as the complexity of engineering increases far into the future.

Its not out of the realm of reasonable price to produce software that is relatively bug free. Especially at the level of complexity of say eTools, which in comparison with the breadth of consumer software, is a fairly uncomplex piece of software.

We may have to agree to disagree. Software development has matured enormously in the time I've been programming (the last 25 years), and it continues to mature. When I first started programming there were no APIs so everything you wrote was from scratch. As a result there were huge opportunities for bugs at every level. Today when you program you can easily create windows, controls, etc. and have them work intelligently with almost no effort, and none of those contain bugs (to speak of). Your data is automatically indexed, and your garbage is beginning to be automatically cleaned up for you. With the advent of object-oriented programming came the beginnings of being able to mimic business logic (the real world) in code without the opportunity to introduce nearly as many bugs as if you had to write all of your object orientation from scratch.

Along with improved tools have come improved design techniques, better ways to express requirements and match application logic to them, and dramatically improved methods of working in teams on code, maintaining versions, etc.

It's not stone knives and bearskins anymore, and this improved maturity allows programs to much more easily be much less bug prone, dramatically reducing the amount of QA required to produce a given function, and fantastically reducing maintenance costs and effort.

The software development field has matured dramatically in the last 25 years, and it gets better all the time.

Structural engineering is a mature engineering field. Certainly things change, but a new way to build the structure of a bridge doesn't appear every 18 months the way entirely new paradigms still appear in software.

I think we must simply disagree.