HomeGeneral ChatNovell’s Response to “Quality” Concerns

Comments

Novell’s Response to “Quality” Concerns — 7 Comments

  1. Here is my response to Mr. Jaffe:

    If there is such a focus on quality, how do you explain the perceived
    reduced quality of Novell’s products when compared to the quality of
    Novell’s products five or ten years ago? For instance, ZCM is widely
    known to be full of problems and not a worthy successor to ZDM. OES2 to date does not match up with NetWare. Even the latest GroupWise service pack, GW8SP1, introduced regressions and exacerbated problems which previously existed in GroupWise 8 rather than fixing them.

    Everything you’ve said makes sense in theory, but in practice Novell’s
    current products do not seem to fall in line with the theories.

  2. Jeff,

    You state: “By far, the major obsession of Novell’s engineering team is to deliver products with the enterprise level quality that customers demand and deserve for mission-critical usage.”

    Does that still stand with the number of Enhancement Requests and Bug Reports that have been filed in the last two years, is compared to the number of Enhancement Requests and Bug Reports filed in the years before those two years?

    Can you please comment on that and get those numbers out?

    Best regards,

    Gert
    http://www.GWCheck.com – the best GW site (Tay Kratzer)

  3. This all sounds great. I only wish that it matched the real world
    experience of your customers.

    As a software developer myself, I well know the fact that no program is bug free. Over time we find, and fix, bugs but there is always one more. What matters to me, as a customer, is not that bugs exist, but how Novell works to minimize them, and how Novell reacts to them when they are found.

    I agree with the first half of your Philosphy point #1. You are in the business of providing enterprise software. I cannot agree that you strive to correct defects once found. I’m also not able to agree that your initial product quality is what it once was.

    I have almost 100 entries in bugzilla.novell.com with my name on them. Some are for feature requests, but many are not. I have several dozen more than I am on the CC list for, either because they impact me, or because I am interested in seeing them resolved. Many of these entries are for problems *introduced* by Novell engineers in recent updates. Many more are for problems reported months or even years ago. My oldest reported, confirmed, and *unresolved*, problem dates back to 2001.

    As a customer, I don’t care what methodology you use for software development. I do care that when mistakes happen, and they are reported, that they get resolved and a patch issued in a timely manner.

    If you were a customer, with a reported, confirmed, and acknowledged problem that was over eight years old, would you agree that Novell’s software quality was good? If you were a customer with dozens of bugs found and entered in bugzilla that were for new problems introduced by Novell engineers who clearly do not have to support these products in the real world, would you agree with your own claim that Novell’s quality was “improving”?

  4. Picking up on David’s comment above

    “As a customer, I don’t care what methodology you use for software development. I do care that when mistakes happen, and they are reported, that they get resolved and a patch issued in a timely manner.”

    and referencing the recent discussions in the Novell Community Chat Forum, in particular http://forums.novell.com/novell-community-forums-stuff/community-chat/389355-novell-support-update.html

    As a customer I don’t want to then be charged to get hold of a patch that fixes a non-security issue – I’ve already paid for that software so if there is a bug, security or otherwise, I expect to get the patch(es) for free since I’ve already paid for them, in advance!

  5. I’ll post my comments here as well:
    I see “initial quality” referred to a lot in that list, but over the past five years I have seen that concept all but disappear; Instead I have seen the industry standard concept of “release it, we’ll patch it later” creep into the Novell methodology. I want stable x.0 releases again.

    Also, Product quality is not only about software quality. Part of Product Quality is the support received with that product. If there is a drive to make quality an important factor, then a serious look at NTS support is in order. A Novell Customer should not talk to 5 “Engineers” that know less about the product than themselves before getting help.

    With that rant out of the way, I’m glad to see that you have an outline and that initial quality is prevalent on it. I hope that you can use these guidelines to turn these recent negative perceptions about Novell’s product quality around.

  6. As Novell has seemed to given up releasing comments on Jeff’s blog, let me repost one of my unpublished messages here:

    Mr. Jaffe,

    What I considered the key reason for the drop of quality over the past few years is the layoff of highly qualified developers and back end support people with many years of deep knowledge and replacing them with new offshore people that have almost no experience with Novell products.
    Unfortunately, instead of improvements, the bad news keeps coming. During your latest round of layoffs, you laid off some *key* people for some products, and the result of this will be a severe bleeding of knowledge and competence on these products which will surely go together with a severe drop in quality on those products. So all I see is you speaking with double tongue. You promise great things to improve quality but at the same time you perform actions that go exactly against this goal. Honestly, I’m glad that a couple of weeks ago, I made the decision to start the migration away from Novell products because certainly this sounds like Novell is a sinking ship.

Leave a Reply

HTML tags allowed in your comment: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>