Product Quality
Del.icio.usBy 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.
It is useful to review our comprehensive approach to quality. Quality is not a single process. It is baked into everything we do: before and during development; after products are shipped in the field; with maintenance provided to customers well after products have been shipped. Due to this breadth I will “fishbone” our activities and address this topic over several postings.
In this posting we define quality, provide key tenets, and outline future posts.
Quality Defined
There are numerous definitions of quality—the most general being “the degree to which the product meets customer expectations”. This can be interpreted as—choosing the right features to meet market needs—and in the past I have described our Integrated Product Development (IPD) process that has that goal. By the way, we are broadening IPD to include a new Requirements Management System which allows customers and partners to directly input their needs to Novell’s product management. But, that is a story for a different day.
Colloquially, when people talk about product quality however, they refer to product defects or bugs. We address bugs throughout the lifecycle of a product by preventing defects in the first place, testing and debugging to remove them, and patching and fixing problems in customer installations. This definition is akin to a classical Six Sigma focus on defects and this is the aspect of product quality that I will discuss.
Philosophy
Herein are basic tenets or beliefs about product quality. Many of these are common in the industry; some are unique to Novell.
- We are in business to provide mission critical software. Accordingly, we hold ourselves to high standards for initial product quality and strive to correct defects found by our customers.
- Quality must be built in prior to customer shipment. The cost for Novell and our customers alike grows exponentially the later in the deployment process one finds a bug.
- The practice of software development has not been perfected. There is no such thing as bug free software. We strive for excellence, but recognize that defects will occur.
- The response to these defects is modulated by severity. Critical defects found in a customer’s production environment get the most immediate attention.
- We make mistakes. And we fix them. If a defect occurs, we patch it. If a product has too many bugs, we redouble our efforts to restore quality to that product as soon as possible.
- Consequence of 5—we try really hard not to make the same mistake twice!
- Our employees respond to management’s attention. Hence we carefully measure our quality, review it on a regular basis, and won’t ship products that do not hit quality criteria. This ensures that we will build quality in.
- There are different methodologies for developing software including agile, waterfall, and open source (community). Our customers expect and deserve equal quality regardless of the methodology.
- Consequence of 8—although there might be different methods to develop software; the software quality metrics and release criteria must be the same.
- Quality is a continuous learning process. Time is set aside for our engineers to continue to grow and learn to improve their skills.
The Fishbone
This is a broad topic and it is already running a bit long. Let me summarize my intentions by listing the key aspects that I will discuss in future blog entries:
- Building in quality from the ground up: In the development of a product, how do we build with as few defects as possible. For agile, waterfall, and open source.
- Metrics: What are the common metrics we track to ensure that we release with quality.
- Testing tools: Methodologies, laboratories, cross-product testing, defect management process.
- Product introduction: How do we manage that very challenging time when a new product is first introduced into the field. Readiness criteria.
- Continuous improvement: Engineering Excellence Steering Committee. Learning Initiative.
- Cadence between product development and Novell services: How we work together and hold each other accountable within Novell to take care of our customers.
October 27th, 2009 at 8:11 pm
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 makes exacerbates problems which previously existed in GroupWise 8 rather than fix 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.
October 28th, 2009 at 1:19 am
I can only say one thing to this:
Stop being obsessed about quality and instead start providing it.
October 28th, 2009 at 4:37 am
I know for a fact that Novell has been able to produce excellent quality software in the past. The sad fact is that quality has been declining over the last few years. Now is the time to stop TALKING about quality and start DOING something.
October 28th, 2009 at 10:40 am
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)
October 28th, 2009 at 2:43 pm
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”?
October 28th, 2009 at 3:31 pm
Great information, looking forward to seeing more information about this in your later posts!
October 28th, 2009 at 6:43 pm
I appreciate this blog post. However, what is said and what is reality seems to be two separate things. The quality of Novell’s products has significantly decreased in the past several years. As a Novell focused consulting firm that has a vested interest in Novell’s success and longevity, we have seen a visible shift in our services. We used to rarely report a defect. Support issues were generally related to admin training, configuration problems, etc. Very rarely did we run into a defect, and when we did, Novell fixed it quickly.
Today, we run into defects on a weekly and even daily basis. We are constantly reporting defects to Novell, and when possible, we provide detailed information on how to reproduce the defects. We spend a considerable amount of time reporting, troubleshooting, and managing the status of the defects. In some cases, we get good turn around time and fixes are supplied quickly. In other cases, we are told to wait for the next Service Pack or even the next major product release. I am mainly referring to OES, GroupWise, Teaming, and ZENworks. It takes weeks sometimes to get feedback or status on certain issues. Many of the problems should have never made it to shipping product release, they should have been caught in Beta or other quality control process. The defects are generally easy to duplicate in multiple environments.
It is my opinion that Novell is simply short on resources. They have cut their budget on development and support to a bare minimum, and no longer have the manpower to provide the quality products of the past.. Much of their development has been outsourced. When defects are reported, they are so backlogged that it’s difficult to address issues in a timely manner.
I would like to believe that Novell can turn this around. Overall the products have great potential. But releasing an SP1 that seems like a beta product should not be an acceptable measure of quality.
Marvin
October 29th, 2009 at 1:48 am
Stop talking, start acting! Not sure how in touch you are with your own products but by reading the above I’d say you haven’t seen any of the Novell products lately. OES for Linux and ZCM are disasterous and a real pain to implement.
And now you want us to pay for updates for products that are broken in the first place. And then you wonder why everyone starts using Microsoft’s stuff…..gee….hard choice
October 29th, 2009 at 5:48 am
Mr. Jaffe, as I have been a avid supporter of Novell since the early 90’s I find myself having a hard time doing this in this day and age. Having a SR open for 6 months, having to try and deal and understand with support reps, because there english is so poor (not there knowledge but the ability to understand them). Novell not fixing issues like sntp on OES 2 64 bit, because it would be difficult. These things concern me as a supporter and user of Novell’s products and when your first line of the definition of Quality states There are numerous definitions of quality—the most general being “the degree to which the product meets customer expectations”.
October 29th, 2009 at 7:25 am
Really? Is that why I’ve filed more bug reports in the last three years than I did in the previous thirteen?
Move product development and tech support back from Mumbai, and maybe I’d be able to read the above statement without choking on my coffee.
October 29th, 2009 at 9:50 am
Anders and Marcel: I appreciate your interest and passion on the topic. Clearly, I agree that we need to provide quality. Please bear with me over this blog series as I map out our processes, metrics, and results.
October 29th, 2009 at 10:42 am
Alan, appreciate the support. Stay tuned as we go through our metrics on achieving quality. I hope you will agree when you see our approach that overall we have a good story.
October 29th, 2009 at 10:48 am
Marvin, appreciate your support. You make some fair points, but bear with me as we dissect different aspects of your comments in subsequent postings. For example, I can’t support your assertion that we release an SP1 that has a quality of a beta. We’ll take you through our release criteria and some data, and I hope you will be convinced.
October 29th, 2009 at 10:50 am
David, totally agree with your comment that “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.” My objective in this series is to communicate our commitment to that. I also think, though, that it is informative to take you inside the tent – so you can see how we go about doing it.
October 29th, 2009 at 11:16 am
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!
October 29th, 2009 at 12:56 pm
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.
October 29th, 2009 at 1:37 pm
Jeff,
I’m already pretty far “inside the tent” here as a member of several Novell sponsored organizations and frequent beta program participant. I don’t think any level of explaining is going to help. What we need to see is results.
I’m not seeing results in “preventing defects in the first place”. I’m not seeing results in “testing and debugging to remove them”, and I’m *really* not seeing results in “patching and fixing problems in customer installations.”
To give you one microcosm example, this morning I deployed eDirectory on a Windows 64-bit platform. This is, at least in theory, supported and tested by Novell. I discovered that one essential system utility (dhostcon.exe) shipped with eDirectory/Win64 is actually only a 32-bit program, and therefor does not even run on a Win64 OS. I found that there is a bugzilla entry (https://bugzilla.novell.com/show_bug.cgi?id=528443) for this exact problem. Interestingly, the bug is marked as “resolved”, yet there is no actual customer available resolution, nor any hint that one may be provided. I obtained the fix via my support contacts, who had to get the fix off of some internal server for me.
So, scoring this one:
Prevention: 0/10
This could have been prevented by the most basic software testing procedure: Install the product. Run the utility. Find that it does not work. It’s obvious, therefor, that NOBODY ever tested this.
Debugging: 5/10
Somebody else reported this, and it’s encouraging that somebody in the engineering group fixed it. That they are able to mark the reported problem as “resolved” without providing that fix TO anybody seems like an easy to correct problem, but a problem nonetheless.
Customer: 0/10
If a customer is affected by this, and cannot actually get a fix for the problem without extraordinary access to Novell support, I have to score this one as a 0/10.
October 29th, 2009 at 1:57 pm
David, I appreciate your frustration. I’m not saying we get every bug and I’m not even saying we never have a crit sit that should not have happened. Hopefully, as I take you through our methodology and some of the statistics you will get more confidence in our quality. Stay tuned.
October 29th, 2009 at 3:37 pm
Jeff,
I am going to assume this is not intentional, but the impression I am left with as you continually repeat “just wait till you hear what else I have to say” is that the biggest defect is the failure to listen to you customers and partners. Instead of us listening to you, wouldn’t it be better for you to listen to us?
October 29th, 2009 at 4:56 pm
Jeff,
I really wish this were the case with current releases of Novell products. I come from a Microsoft background, specifically deployment with SMS and now SCCM, and I have worked on previous ZEN products which were far better than SMS. Now ZCM has come onto the scene and Novell have completely ruined what should have been a great product.
- We have had a major failure with what should be a simple upgrade to ZCM 10.2.1.
- Try doing a simple bulk import of inventory fields in ZCM. For example, Cost Centre.
- Check that Patch Management actually works on the released product.
- Have a Content Blackout period that is actually practical such as between 5am till 7pm Monday to Friday, rather than the current illogical method.
As a side note – just because the internet is the way of the future it does not mean you need to base all your apps on a web browser. Try and use ZCM all day, every day from a web console and see how painful it can get. A simple process can turn into a marathon. We need a GUI.
I have to say, Microsofts SCCM has left ZCM far behind.
Get your products to the standard of Novell Identity Manager and you will be back, otherwise forget it.
October 29th, 2009 at 6:57 pm
David, I accept your criticism on this point. In fact I am reading and listening, and I’m sorry that my responses gave you the impression otherwise.
October 30th, 2009 at 5:38 am
Mr Jaffe,
I’m in the position that I very soon must decide what software to replace ZENworks7 for Servers and Desktops with. Since Novell made the (to me completely unbelievable) decision not to develop support for Windows Vista/7 in ZEN7 we are forced to replace our whole infrastructure for application distribution to our ca 30 offices all over Sweden. Every day I follow the different ZCM10 forums and read all TIDs and it’s very depressing to see all the problems connected to this product. It’s also depressing to see many of the bugs that I remember from when ZEN was new (and since long solved) now coming back in ZCM10. From what I see today ZCM10 is sadly not on my list.
Best Regards
Rolf Lidvall
Swedish Radio (Ltd)
October 30th, 2009 at 10:36 am
Rolf,
It’s unfortunate to hear that there are still concerns, certainly our early releases of ZCM were troubled. We have worked hard the last year to increase the quality of the product and the current release is a very stable and scalable enterprise product. Worldwide we have many reference implementations and have published quite a few of those success stories with more in the pipeline.
Regarding Windows 7 support in ZENworks 7, this is a carry on from our decision to not support Vista in earlier ZENworks releases. ZCM is our platform for supporting modern Microsoft technologies such as AD and Windows 7. A key strength of ZENworks has always been our ability to bring user identity and device identity to managing end point environments. When Microsoft released Vista (and hence Windows 7) they made fundamental changes to the way their authentication mechanisms work. To support Vista would have involved a complete re-architecture of our agent and require us to maintain two separate code streams, a very expensive proposition for us, and complicated for our customers as well. We currently have preview support for Windows 7 in ZCM and will have full support this December.
Migrating to ZCM from ZENworks 7 is by no means a rip and replace. We have created a set of tools that allow customers to migrate from an existing ZENworks Desktop Management infrastructure to ZCM in a phased approach. Given that ZDM and ZCM coexist well together, you do not need to cut over from one infrastructure to the other over night. The full migration can be staged over a period of time in a manner that makes most sense for the environment. If needed, we have a very experienced and skilled partner in Sweden who is able to assist in this process.
I would like to extend the personal invitation to discuss these concerns and any others in person. I believe we can find a path to move you forward on ZCM with confidence.
October 30th, 2009 at 3:42 pm
Ok, so I’m actually laughing here at my desk at your posting. You obviously are seeing Novell’s quality through your rose colored Novell CTO glasses and I find this humorous. I think the truth really is that Novell is going down and I hope I’m proven wrong.
The best analogy I can come up with to this situation is a boat on the water. You seem to think that Novell is a boat that is built with quality materials, is really big, comfortable, unsinkable – a well running boat.
The position you are stating this from is like looking from the 1st class section of the ship where all of the cabin stewards(the people reporting to you) are telling you all is well with their facts and figures(you know how accountants and reports can twist figures to look favorable – just ask MCI WorldCom) so that things look great “to the boss.” So here you are posting on how good your processes are to somehow tell us customers that all is well in your company.
We are like the passengers in the 3rd class area where we are able to see the bad welds and leaky rivets that the builders used to build the ship. We hear the engines that misfire and vibrate real bad. We see the doors that don’t close in our rooms. We see the carpet getting wet as the streams of water come in through the leaky rivets and welds.
A few years ago, I went to BrainWash in SLC and Novell tried to convince all of us that the company was real strong and cash rich with more than 1 Billion in cash. Now I see that Novell has lost 40% of that and only has 600 Million in the bank these days. When are you guys going to notice this? When are you going to start selling your products? When are you going to listen to your current customers that tell you quality is down? Although it may be a slow death, any company not growing is dying.
Now I’m not going to specify the problems we’ve seen here. But rest assured, we’ve seen a huge increase in the support calls we’ve had to make to Novell because of the downturn in quality of code coming from Novell. The interesting thing is that I have a problem in one of my systems that has never been resolved even though it was supposed to be fixed in the last GW support pack. The SR is closed but my problem is still existing. I have coworkers with the problems that in some cases took up to a year to resolve or were also never resolved at all.
Now, It doesn’t matter what you believe about your quality nor your numbers, facts, figures, or metrics. It matters what we believe. If we think your quality sucks, then it sucks we won’t buy from you. If we think your quality sucks, we’ll migrate to your competitor’s products whether you like it or not.
Eventually, the inevitable outcome is that your ship will sink.
November 1st, 2009 at 3:04 pm
Tim, I agree that it matters what you believe and I’m sorry that your experiences with our product quality have not been good. I will continue to share our processes and metrics over the next few weeks and hope you continue to give pointed feedback so we can have an open discussion about where you perceive the breakdowns to be.
November 1st, 2009 at 11:46 pm
I have to agree about the poor quality of some of the recent products. I understand ZCM was built from the ground up and issues are to be expected however it’s taken a good 18 months (maybe lnoger) for the product to be usable (the initial release was shocking) and yet even at SP2 there was still a number of fairly major bugs (Patch Management not working via a proxy, registration issues etc). Some of these I find pretty hard to believe weren’t picked up in testing and are core functionality.
I would really like to see the type of quality mentioned in your post reflected in every single release of a product (wether a . release or patch to an existing product).
Maybe I was spoilt/lucky with ZFD7 but as it stands now we have customers looking to move to ZCM from ZFD and I’m constantly worried about whats going to go wrong next with the product, which will make us (the partner) and Novell as a collective look bad.
November 2nd, 2009 at 4:28 am
Jeff,
Great to see you are actively replying to the responses posted. I have a question for you in regards to your last post (comment #25) where you ask where Tim perceives the breakdown might be. In my opinion, the breakdown is where Novell is trying to save operational cost by moving everything (or at least lots) of the product development to India. Ever since Novell has started doing that product quality has gone down.
Same as opening a call and you have to deal with India support. No offense against the people who work there as they are trying very hard but it just doesn’t work. The language barrier is a rather large obstacle (not everyone of your customers speaks English as a first language), the products coming from Bangalor quite often lack quality etc.
Shutting down local offices didn’t do any good for customers either. People from Austria don’t like dealing with people from Germany but because they both speak German (will kinda..) Germany Office should be able to take over all Austrian customers. Same as for Australia and New Zealand. Centralizing everything is a great way to save money but how do the customers perceive that ? Hmm..No more Novell presence locally, they must be going bad, we’ll use something else then.
Fair enough Novell wants to cut costs but in order to make money you need to invest money. By cutting all operation costs to the bare minimum Novell will never be the world leader in Enterprise software they claim to be as all the talented programmers will be at the competition.
November 2nd, 2009 at 8:36 am
Edward, I hear your concerns about quality; that’s why I’m trying to explain our approach and engage in a dialog with everyone. Next week, I’ll post more on our metrics and targets. In terms of “cutting all operation costs to the bare minimum” – I don’t think that is accurate. Standard measure of whether a company is investing is the ratio of engineering expense to revenue – which is quite respectable for Novell.
November 2nd, 2009 at 8:39 am
Shane, take a look at Alan Murray’s comments – yes we had ZCM issues, but we are on a better path. Next week I’ll describe the standard metrics and targets for every single release of a product. Stay tuned!
November 2nd, 2009 at 9:46 am
“Standard measure of whether a company is investing is the ratio of engineering expense to revenue – which is quite respectable for Novell.”
What kind of crazy metric is this? Your revenue is down (as it is with pretty much every company). So you’re going to continue to spend less on engineering, to keep this ratio of engineering expense to revenue a constant? And you expect to somehow escape the rule of “cheaper, faster, better: pick two”?
November 2nd, 2009 at 2:03 pm
David, to be clear, Novell does not have a fixed formula where we track the industry’s spend level on an expense to revenue ratio. Typically we spend more.
November 4th, 2009 at 2:34 am
Jeff,
I have been reading all comments. Almost every comment was trying to make the same point: Quality is down/declining. It is not getting better, it is getting significantly worse.
Providing insight into methods and metrics which paint a different picture does not help. Your customers already know the quality, because they experience it every day.
The only logical consequence is that your metrics must give the same result – or are biased/wrong/faulty/…
I am not interested in some kind of theoretical framework with numbers which do not match reality…
November 4th, 2009 at 4:49 am
Edward,
Your comment that products moved to India and products coming from Bangalore lacks quality, seems to mean that Indians lack skills to produce quality products. But I disagree. Just that when someone else has to maintain/develop on not so good code developed by someone else, the mistakes become visible. Most of the time it is just that the older unreachable bugs are getting exposed.
Language is not a problem for an average Bangalore software engineer. But I agree a bit that of-late Novell India is ready to settle for below average employees not helped by no salary raise. Also recently hired first level managers also lack the necessary skills.
November 4th, 2009 at 3:46 pm
Re: message #34
Indian,
Well, I don’t know what Edward’s opinion on this is, but I think the core issue with moving development to India is not a lack of good programmers over there, but a lack of development experience on Novell products. It is simply an illusion that you can replace people many years of development knowledgement on a highly technical programs with new developers that may be good as general developers but that only have a few months of experience on the product which they have to take over. Novell has to understand that developers are not commodities, but for a software company, they are the core value because years of experience cannot be easily and quickly transferred to someone else. As long as Novell keeps considering developers as commodities that can easily be swapped, the steep descend on product quality will continue.
November 4th, 2009 at 5:26 pm
Indian,
Your comment jumps to conclusions. Edward did not say that all Indians lack the skills to produce quality products. He said that Novell’s focus on reducing cost has resulted in lower quality. In other words, India may have skilled developers and support teams, but Novell didn’t hire them. Novell lost focus on quality by focusing too much on cost.
November 6th, 2009 at 11:05 am
Jeff, My guess is that you’re wondering why your engineering is so expensive but you can’t figure out why the quality is really lacking. Certainly, part of it has to do with all the seasoned experience that you’ve let go and replaced with entry level persons in India. (who then get some experience and move on, providing a net loss of familiarity with that code) But your real issue is that you have too much product to support! Do you even realize how many products you have? Why is Novell so scared to cut some products, so engineering can work to better improve quality? With dwindling numbers of employees who actually have experience with the code, you need to bite the bullet and start supporting less product. There is no way your decreasing number of talented engineers can have any focus on that ever growing portfolio.
November 10th, 2009 at 3:23 am
Comments posted here are more than sad (but true) to read. Most of the comments are full with valuable data to Novell and specially their R&D management.
From my point of view Novell toked way to big “risk” trying to be so flexible in multiple architectures. How did Novell think that they could manage to maintain so wide cross platform compatibility when MS has full job to maintain one platform with huge resources.
IMHO must cut down supported products / platforms even more to be able to provide quality if the resources are limited.
J
November 11th, 2009 at 7:15 pm
Hey jef..
R u matching customer demands.. ?
What r the demands of the customers…?
What r the values you have towards customers…?
Have u ever valued customer inputs ?
Quality is a bug rather a good bug which gets lot appreciation. Whether u work from Bangalore or from Austria or Germany. It has to be experienced. Novell for some time prioritized money as primary and every else secondary. The metrics does not depend about the plans for planning a new structure. It all depends about implementing. how effective will be ur understanding about a particular model.
“Consequence of 5—we try really hard not to make the same mistake twice!” Common jeff u have no right to tell this. If u can give me ur email id I will send atleast 29 same bugs in both ZDM and ZCM. common jef apply some mind.
Ur las point “Quality is a continuous learning process. Time is set aside for our engineers to continue to grow and learn to improve their skills”.. This is some thing like escapism. Talking truly like CTO. Novell has become an escapist type of company of late. Why, u always pass the buck to others.
This is a misconception to say “There are different methodologies for developing software including agile, waterfall, and open source (community). Our customers expect and deserve equal quality regardless of the methodology.” The methodlogy is also very important. The methodology that u use makes the product more secure.
srini
November 15th, 2009 at 4:42 pm
One of my mantras over the years is that you cannot “fix” initial quality with patches. A consequence of having yet to master time travel. http://www.TrafficShaper.com/ICF Anyway…
Novell actively “manages quality” – that is to say, Novell prioritizes known defects. Perhaps there is a perceived disparity between the defects Novell thinks are important, and those which are [ important to the customer. ] Of course priorities are driven by resources. Even so, this reality provides little comfort to individual customers experiencing serious defects.
Some feel Novell has developed a regrettable penchant for creating Rube Goldberg machines. A significant part of this appears to be layering on the “mandated technology du jure.” Trading a simple, easy to understand, failsafe way of doing something critical for a complex, fragile, single point of failure. So perhaps part of managing quality is managing mandates, and tempering “overly clever” designs.
– Bob
November 16th, 2009 at 10:00 am
Jeff, you wrote that you would post an update to this story last week.. Have you forgotten?
November 16th, 2009 at 7:42 pm
Thomas, thanks for the reminder. I generally post a new entry every 2-3 weeks or so (usually 2; 3 if there is a holiday). I mentioned on 11/9 that I was postponing the update on quality to get in breaking news about Pulse. Quality is still in the pipeline – lots more to write about.