November 7, 2013 at 9:55 am
Tom John-342103 (11/7/2013)
At one point, one of the telcos started to offer billing to the nearest second or something like that where the competition could only do it to the minute. This forced the competition to jump through hoops to try to offer the same thing. Whether or not they would have been better off just cutting rates, I don't know, but they certainly seemed to think they needed to bill by the second as well.
These feature matches are often to make a few big sales to companies. When a salesperson loses a $1mm sale to a competitor over a feature, he/she screams for that to be added. It happens in SQL Server and in other products.
However these features may or may not really determine sales. It's so hard to tell. Not that they're not worth doing, but they don't usually decide the make or break for the company.
November 7, 2013 at 10:28 am
Steve Jones - SSC Editor (11/7/2013)
Tom John-342103 (11/7/2013)
At one point, one of the telcos started to offer billing to the nearest second or something like that where the competition could only do it to the minute. This forced the competition to jump through hoops to try to offer the same thing. Whether or not they would have been better off just cutting rates, I don't know, but they certainly seemed to think they needed to bill by the second as well.These feature matches are often to make a few big sales to companies. When a salesperson loses a $1mm sale to a competitor over a feature, he/she screams for that to be added. It happens in SQL Server and in other products.
However these features may or may not really determine sales. It's so hard to tell. Not that they're not worth doing, but they don't usually decide the make or break for the company.
In any event, the telcos decided that it was worth spending zillions of dollars to catch up with the competition. And that meant enhancing their billing software as quickly as possible.
November 7, 2013 at 12:48 pm
Which features through the generations of Microsoft Office were regarded as a little clunky?
Early generations of SQLPrompt and SQLRefactor were clunky.
DBCC was a little clunky.
Profiler was a little clunky
sp_add/update extendedproperty is still bloody clunky compared to Vertica's COMMENT ON TABLE dbo.Orders IS '<user friendly description>';
I would describe clunky as of merchantable quality, functional, useful but not necessarily as refined and/or slick in its operation as it could be.
Ultimately what we produce has to make a profit or at worst not make a loss. In some cases the revenue generated from releasing code is what funds the later refinement.
Would I like to produce a Rolls-Royce solution. You bet I would, it would be a matter of pride to have done so. Often I've had to satisfy for "my colleagues won't hate me for having to support this".
As to Rolls-Royce, I live near Crewe and once saw the quietness of the engine demonstrated. I asked one of the engineers if it was true that you could balance a 50p on the engine cover at 3000rpm. He was afronted that such crudeness was regarded as high quality.
He balanced a 20p (half the width and a lot more difficult to balance) on the engine cover and revved the engine to 6,000rpm repeatedly. The coin barely wobbled.
For me delivering quality is a matter of pride and self respect. I'd happily put in extra unpaid time just to make sure that I could be proud of what I had delivered.
A little bit of me cracks and dies when I have to deliver a compromised solution but I'm pragmatic enough to recognise the necessity of doing so.
November 7, 2013 at 1:47 pm
Tom John-342103 (11/7/2013)
If "a little clunky" means that the application is good enough, then by all means roll it out. Because "good enough" delivered today beats perfection delivered tomorrow 100% of the time. However, if "a little clunky" means healthcare.gov, then a premature rollout risks discrediting the whole program.
+10
I'm ok with a little clunky being a little slower. When it comes to being buggy or dead as a door nail slow - that should not be released.
There are trade-offs to time spent developing and the performance gains from tuning the code. One needs to accept that and know where to draw the line as far as clunky goes.
One also needs to understand project and scope creep and keep things moving forward with scheduled enhancement releases. That is FAR different than releasing buggy code.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
November 7, 2013 at 1:51 pm
If you want it real bad, that's the way you'll get it.
Rework costs at least 8 times more than doing it right the first time.
Your customers are the most important assets you have. Ask them what's "good enough".
A black-eye from a customer almost never heals and it may keep you from being attractive to other customers.
While "Perfection" might not be achievable or even practicle, "Good enough" usually isn't.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2013 at 2:05 pm
It simply amazes me that many of you can say a quick solution is OK over an effective solution while the whole ObungledCare fiasco is going on which disproves your very argument. It's no wonder most of the systems these days don't last very long. They have too many failures and are so costly and difficult to maintain and update due to poor design that they get trashed and replaced more frequently at higher and higher costs. And replacing them with more poor quality, unmaintainable code is akin to most government programs.
In my final years one of my main functions was to take quickly developed poorly written and tested SQL Server code and stored procedures and rewrite and test them to eliminate locking and blocking, improve performance often to fractions of original execution time, and to correct blatant inaccuracy in the data they presented.
It boggles the mind that critical code development is turned over to the youngest, most inexperienced coders and testers and their younger, most inexperienced managers. And furthermore, the best of those who are mentored and coached by really good developers and DBA's then get promoted to better paid positions instead of paying them well for what they do best.
A good developer is usually is not a good manager, but a good manager MUST be a good developer.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
November 7, 2013 at 2:10 pm
Excellent words of wisdom by Jeff Moden above
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
November 7, 2013 at 2:56 pm
If you have fancy window dressing(s) but a weak foundation because you wanted to move into your house "yesterday". The foundation will crumble sooner. The house will be on jacks while the foundation is "fixed", all the while the overall cost has skyrocketed 5 times or more. And for what? To be the first on the block with the fanciest house.
November 7, 2013 at 3:16 pm
Sqlraider (11/7/2013)
If you have fancy window dressing(s) but a weak foundation because you wanted to move into your house "yesterday". The foundation will crumble sooner. The house will be on jacks while the foundation is "fixed", all the while the overall cost has skyrocketed 5 times or more. And for what? To be the first on the block with the fanciest house.
Sometimes being first to market is one of the key BR's. What about the new estate that needs a house or two to show what the overall picture will be. Remember the Bluth's? I was working on a system that had both an implementation date and a use date. As the PM I forced everyone to accept that the implementation date was the date the company was going to market to display the companies capabilities in the space. As the system required a minimum of 12 months of data before any reporting could be generated we all accepted that the initial solution just had to be good enough to demonstrate our capabilities with the final delivery including a lot of clean up and re-factoring to reduce the technical debt.
November 7, 2013 at 3:50 pm
Jeff Moden (11/7/2013)
If you want it real bad, that's the way you'll get it.Rework costs at least 8 times more than doing it right the first time.
Your customers are the most important assets you have. Ask them what's "good enough".
A black-eye from a customer almost never heals and it may keep you from being attractive to other customers.
While "Perfection" might not be achievable or even practicle, "Good enough" usually isn't.
Winner winner chicken dinner 😀
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
November 7, 2013 at 8:26 pm
This argument seems to have devolved into competing viewpoints on what "a little clunky" means.
The original article was about a piece of software which was tested and meeting all established requirements, but where there were questions on whether the architecture was ideal. That's far different from, say, a government website that crashes frequently, can't handle load, and is full of obvious bugs.
And there is also the matter of "decision point". Doing it right the first time is a great motto, but when this decision is to be made, that ship has often sailed. You are already at the point of rework. And the question becomes whether you need to push back launch until that rework is done.
I absolutely agree that being in a hurry doesn't justify making poor design decisions or cutting corners. But it absolutely can justify making a decision that a less than ideal solution today helps more than an ideal one much later.
November 7, 2013 at 10:44 pm
Nevyn (11/7/2013)
Doing it right the first time is a great motto, but when this decision is to be made, that ship has often sailed.
That's EXACTLY the problem I'm speaking of and it has become a rule rather than the exception. It usually stems from someone making some over-promised agreement which also means that the ship sailed long before the first delivery could be made.
"Doing it right the first time" shouldn't be just a motto. It should be the best of all practices.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 8, 2013 at 5:44 am
Steve Jones - SSC Editor (11/7/2013)
Gary Varga (11/7/2013)
Oh and Steve, "a little clunky"? Intentional provocation Mr Editor?
The exact quote from the email I saw. I did not press further as to what "clunky" was, but from my impression of the question and response, it had to do with a somewhat strange way of taking input in a frame instead of some popup that communicated back with the original page.
Oh, I am not accusing you of anything more than accurate reporting and writing on interesting subjects to provoke debate. It's all good 😉
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 8, 2013 at 5:53 am
David.Poole (11/7/2013)
...A little bit of me cracks and dies when I have to deliver a compromised solution but I'm pragmatic enough to recognise the necessity of doing so.
I think that will apply to many of us 🙁
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 8, 2013 at 5:59 am
skeleton567 (11/7/2013)
It simply amazes me that many of you can say a quick solution is OK over an effective solution...
I hope that you haven't interpreted anything I have said as this. Sometimes, through appropriate design, you can have areas that need further refinement, efficiency or enhancements whilst still producing quality. An example might be that you know that there are another half a dozen reports that are required to complete the systems but as long as they can be added seamlessly as part of an upgrade, that they data is captured from the start and the UI remains intuitive then you may have released a "good enough" version initially followed by a "complete system".
(Update: Just read dogramone's post. Exactly what I was meaning.)
Also quick solution does not necessarily equate to an ineffective one either.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 15 posts - 31 through 45 (of 82 total)
You must be logged in to reply to this topic. Login to reply