July 5, 2008 at 11:21 am
Comments posted to this topic are about the item Enough is Enough
July 7, 2008 at 5:05 am
As a customer, I really despise when a product has errors and I try to never by from those companies again. But there is of course a tradeoff somewhere and what the other companies has to offer.
If I were to lead a company however, it's vital to make sales and have a good cashflow, and they have to make other tradeoffs on when they think the product is good enought.
So yes I understand both areas parts, but I do think you should not put something in that has errors, then you should wait for the fix. But then again, if it's something minor.. like report builder wizzard in sql server 2005 that can not handle sp's with temporary tables (just to take an example), maybe that is not grounds enought to remove the wizzard, but it sure is annoying from a customers standpoint, but the customer probably still wants to have the wizzard..
Excuse bad typing.
July 7, 2008 at 5:25 am
Software is part science and part art.
The science to the decision goes something like this: Somewhere in a marketing cube (or office) at Microsoft there's likely a graph with two lines. One line represents the number of customers who will delay purchasing until SP1 because of this bug and a general consensus that customers should wait for SP1 before deploying. Another line represents value lost by not releasing on the intended date. Where those lines intersect is a point that served as an argument for this decision.
The art of the decision involves balancing business and technology. The technology part is about the advances in SQL Server 2008 over previous versions. The business part falls into two categories: the companies that will benefit from the advances in SQL Server 2008 over previous versions and Microsoft's business strategy.
Personally, I'm glad I don't make those kinds of decisions often. When I do, it's no fun for me either.
:{> Andy
Andy Leonard, Chief Data Engineer, Enterprise Data & Analytics
July 7, 2008 at 6:13 am
We get these debates where I work a lot. For some reason, many of my fellow DBA's believe that every known bug has to be addressed prior to release or you absolutely can not release the software. I fall into the pragmatic camp. Does it break stuff, or just not work as well as we would like? If it's the latter, deploy it and we will get around to fixing it, if it needs fixing. The fact of the matter is, sometimes, what appears to be "broken" to us, is just fine to the users. What appears to be very slow to us, is fast enough for the users. If it isn't, usually, not always, but usually, the word will get back to us and we can spend time fixing what needs fixing. In the mean time, something that the users need is available, rather than sitting on a Dev server waiting for perfection.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 7, 2008 at 6:14 am
Today, we don't really deal in software much. We deal in software packages. That is to say, when we buy something, we expect it to do a lot of stuff. The days of building a company around a simple utility are largely gone. A new release of a major software pacakge like SQL Server (like any other package) is expected to have new features.
The problem is; at what point do you have enough to get the job done? At what point are new features 'gravy'? Many software purchasing entities have reached a point where they can get along without new features for quite a long time. So, why risk problems when your current package is sufficient? That's why we're hearing more and more of the "don't buy until SP1" mentality. Sometimes the only practical differenence between a new release and what you currently have is that the seller is going to stop supporting your package eventually.
This is why Apple is having so much success with their anti-pc adds. Mac is sold as being much more dependable than the PC. PC's do more for less money, but Mac still does a lot and (supposedly) does it more dependably. For many, the dependability is worth the extra $$.
My point (after the ramble) is that producers of software packages (like Microsoft) should lean towards making a smaller number of things work right at this point.
___________________________________________________
“Politicians are like diapers. They both need changing regularly and for the same reason.”
July 7, 2008 at 6:34 am
Hi SomeGuy,
I disagree. Microsoft has overwhelming marketshare and customer loyalty - why change? That's not to say Microsoft shouldn't strive to release better products. They should. And they do. From my observations, Microsoft software is more reliable and secure and stable now than it was in the past. I've seen steady improvement.
Is Microsoft software perfect? Heck no. The quality's better than it was though, and I expect that trend to continue.
I think they should remain on the course they're on and keep delivering more features at a steadily increasing quality while maintaining the value.
:{> Andy
Andy Leonard, Chief Data Engineer, Enterprise Data & Analytics
July 7, 2008 at 7:04 am
Hi Andy,
I hope I didn't miss the main point of the article with my previous post. Most of us have jobs because our employers and customers want new stuff. If my only job were to keep old programs running, I would be a 'technician' rather than a 'developer'. If Microsoft doesn't add new features to releases, their market share will diminish. And SQL Server has much more right about it than questionable.
Having said all that, I think that the folks in marketing at Microsoft should be concerned about their 'brand'. Microsoft as an entity is starting to have a reputation in some circles of putting out software before it's ready. This is a shame, because those of us who work with individual products such as SQL Server know that it's overall a good package and that there are lots of good business reasons to purchase it over its competitors.
We need to be careful about applying terms like "customer loyalty" to database packages because in the real world a company buys one and is forced to stick with it for a long time whether they feel they made a good decision or not. We techies may have an attachment to our tools, but if there are too many CIOs sitting in the country club quietly grousing to their buddies about how much they regret purchasing a certain software package, new sales will diminish. Right now, the buzz in many of the corporate watering holes is "don't buy Microsoft until SP1". Maybe that's a shame, but it's something Microsoft should think about. Likely, they are...
___________________________________________________
“Politicians are like diapers. They both need changing regularly and for the same reason.”
July 7, 2008 at 7:06 am
Andy Leonard (7/7/2008)
Hi SomeGuy,Microsoft software is more reliable and secure and stable now than it was in the past. I've seen steady improvement.
Is Microsoft software perfect? Heck no. The quality's better than it was though, and I expect that trend to continue.
I think they should remain on the course they're on and keep delivering more features at a steadily increasing quality while maintaining the value.
:{> Andy
uhm, what was the last major package release from MS before the current release cycle of Windows server and SQL? Vista? Quality?
I understand there are problems with software at times, but known issues should be addressed in one way or another. I.e. if you can not get a fix in on time for RTM, it should be removed until they can get it fixed (if it flat out does not work, if it is slow that is different).
We're not talking a piece of software written for our users, where for most of us the user base is pretty small and we can get a godo feel for what the users would prefer us to do.
Personally I think MS needs a better beta program. Too many things slip trough without working right. I.e. SQL 2005 SSMS lacking the ability to properly script out objects from the database at release. But I guess stuff like that is bound to happen as I would venture to guess most production DBAs do not have the time to extensively play around with new versions until it is time to start planning for the upgrade.
Put me solidly in the book for someone that will wait for SP1 (or SP2 if SP1 comes out shortly after release), which for us is bad timing as we are about to upgrade all our SQL 2000 boxes. I had hoped to go with SQL 2008, but will have a hard time recommending that to my bosses.
July 7, 2008 at 7:19 am
Can you imagine Toyota, for example, advertising a car with specfic new features, but when you buy it you find out that they don't work? And if you complain they tell you that in 6 months, you can take it to the dealer and (hopefully) the feature can be installed?
Software companies seem to have a very different mindset than those in the real world.
...
-- FORTRAN manual for Xerox Computers --
July 7, 2008 at 7:23 am
There's really not enough info to make an intelligent decision on the example presented. Assuming this is not the only report the feature provides, and that there is more than 5 or 6 total reports created by this feature, since there is a work around available, I would probably send this out. Conversely, if this is the only report, or very few reports are created by the feature, I would move the release date.
You have to review all your options before making a final decision - In the past I have stopped projects and recommended the stoppage of projects from being released because of critical features not working. I have also moved release dates for my our projects when too many bugs are present. When a critical issue is going to affect a release date, I have even personally got involved in testing to make sure a project is released on time. And when it's far enough in advance, I have pushed for a critical bug to be fixed when it is going to put the company I worked for at risk.
You need to understand what will happen if the software goes out as is. Will it take away current functionality, will it shut down the application or a PC, how difficult is the walk around, how critical is the feature. The more info you have, the 'easier' it will be to make or recommend the 'correct' decision.
July 7, 2008 at 8:12 am
Some questions I would ask to answer the "release or delay" question:
1) If it were released as is, would people get any increased benefit out of using the feature vs. what they do today? If no, why bother releasing it? It will just cause user frustration and waste their time.
2) If it were released as is, would the bug cause data corruption that would have to be fixed later, or is it just a matter of something the user wants to do doesn't occur? If yes, DO NOT RELEASE IT. Never release a feature that's going to corrupt data regardless of how important it supposedly is.
3) Does the bug error gracefully or does it crash the application? If no, either don't release it or add some graceful handling.
4) How tightly integrated with other features is this one, i.e. can it easily be "turned off"? If it can't be easily de-integrated with other features, you may have to release it or lose other features as well - some of which may be mission critical.
This is not a complete list of questions (nor the end-all-and-be-all of answers) but they are the first ones I would ask and the logical points I would make in response to the answers.
--
Anye Mercy
"Service Unavailable is not an Error" -- John, ENOM support
"You keep using that word. I do not think it means what you think it means." -- Inigo Montoya in "Princess Bride"
"Civilization exists by geologic consent, subject to change without notice." -- Will Durant
July 7, 2008 at 8:19 am
When "benefit > cost", is when it's good enough. Judging that is the trick.
I like to operate on lots of small, incremental improvements, rather than huge, monolithic releases. Of course, sometimes a radical revamp is needed, and it has to be done all at once.
As a side note, on the point someone made of Vista not being an example of improved software: I've been using Vista since beta, and I actually like it. I haven't been having the problems with it that some people seem to discover, but I'm generally able to make any computer run pretty smoothly, so maybe it's not a fair test.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
July 7, 2008 at 8:29 am
It's always a judgement, and I think it has to be a debate between sales/marketing and development. I certainly don't want someone in Marketing taking a guess based on their guess at a graph, but I would want input from sales or someone talking to customers.
Microsoft has released software before it was ready. In some cases, I think their move to a heavily automated testing environment exacerbates this because no one "looks" at the product. Vista's copy/delete "calculation" and the change in Maintenance plans to add hours to the cleanup task were examples of this. If someone sat there and looked at it, they'd realize there was an issue.
However I've seen Apple release things not ready either, and with bugs very soon after release. Everyone does it, or it happens to them. It just has a great impact, and happens more to MS, because of their breadth of products and size of customer base.
I don't have a good solution, but I wanted people to think about this. The feature that inspired this, in my mind, isn't worth waiting for. It's possibly annoying, but it's not causing data loss, I think a minority, much less than 50%, would even notice it, and it's not that hard to work around. I just don't think it's worth interrupting testing for it. If you delay for this one fix, there will be two more that someone wants things delayed for and you must "arbitrarily" decide when to ship at some point.
July 7, 2008 at 8:40 am
I think that we as developers should be open about the "issues" that still exist. If we publish a list of known issues along with the benefits of the new release/fix/SP etc AND it doesn't corrupt data (that, to me, is such a no-brainer red flag) then we should be able to send out the release without it being perfect. I think the issues bothering the consumer are not those that they have been made aware of, but rather those that testing didn't catch and that they are now involuntarily "beta-ing" for. IMHO, anyone who sends out software with known bugs without advising the recipient doesn't deserve to earn a penny in this profession.
July 7, 2008 at 8:46 am
The key problem is, desiging, building and deploying software is still not an act of engineering like building a car, a toaster or a bridge. As Steve pointed out in his list of articles comparing building software to various other endeavors... It's just not the same and we can't have the same expectations. Someone said, imagine Toyota releasing a car that needs fixes, well, one, that sometimes happens, but imagine Toyota releasing a car that allows users to customize it on the fly, dropping features, adding features or going out and grabbing Honda parts and glomming them on... It's not always going to work right, is it? Until huge portions of the computer industry are simple toaster style machines, other huge portions of the industry are going to be just as complex and difficult to develop against as the other parts. SQL Server is no exception.
I think most software companies do a good job most of the time. Those who don't, lose market share and go away.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 15 posts - 1 through 15 (of 23 total)
You must be logged in to reply to this topic. Login to reply