Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Effectiveness


Effectiveness

Author
Message
Steve Jones
Steve Jones
SSC-Dedicated
SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)

Group: Administrators
Points: 36042 Visits: 18736
Comments posted to this topic are about the item Effectiveness

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Sean Redmond
Sean Redmond
SSC-Enthusiastic
SSC-Enthusiastic (198 reputation)SSC-Enthusiastic (198 reputation)SSC-Enthusiastic (198 reputation)SSC-Enthusiastic (198 reputation)SSC-Enthusiastic (198 reputation)SSC-Enthusiastic (198 reputation)SSC-Enthusiastic (198 reputation)SSC-Enthusiastic (198 reputation)

Group: General Forum Members
Points: 198 Visits: 683
Andy Hertzfeld (one of the programmers on the original Macintosh) has this story on shipping:
http://www.folklore.org/StoryView.py?story=Real_Artists_Ship.txt&characters=Andy%20Hertzfeld&detail=medium

On the one hand, I agree with the statement that 'good enough is the enemy of best' while, on the other hand, I have first-hand experience of personal projects that were delayed by up to a year because there was always something that could be improved, or tested better or looked better. Discipline is necessary.

On a final note, it may have been in Steve's column where I read the[font="Verdana"][/font] comment that people don't remember missed features but they do remember missed shipping dates.
john.riley-1111039
john.riley-1111039
SSC Rookie
SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)

Group: General Forum Members
Points: 48 Visits: 202
In Britain, we talk about 'Rolls-Royce solutions', usually as something to be avoided because of the cost in time and money. This is not to demean the excellence of Rolls-Royce products in any way, but the fact is that most of us get by with a car that is not a Rolls-Royce. And similarly, most of us develop systems that do not need to be at the luxury end of the market.

At Uni, in a lecture on system modelling, we were asked how we should choose a model for a system. After various suggestions, the lecturer said simply "The cheapest acceptable". That was 35 years ago and it is still stuck in my mind.

Very often it is quicker and easier to adapt an existing, not particularly well-written system for a new application than write a model of coding efficiency from scratch. Save that for the bits which don't quite meet the spec.
sincosys
sincosys
Forum Newbie
Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)

Group: General Forum Members
Points: 3 Visits: 94
I am terribly sorry my dear colleagues, but I beg to differ with the "...little clunky..." type of mentality. I started my IT life back in the mainframe era; and to this date, I have always had three personal perspectives about computer coding: make it as flexible as possible, make it efficient so as to be as perfect as possible, and keep it as simple as possible. And believe me, some of my PL1 and COBOL stuff is still executing. However, in today's modern technology, I tend to see a kind of like a throw-away mentality or "...fix it in the next release...." approach. How did it get so uphold? Back in the days, computer engineers were able to develop a lot of "stuff" to put men in space, make many other developments to make life better. True, a-lot of "stuff" gets out of date in time, but that is not reason enough for us to release code that is " a little clunky". Can you imagine medical devices with "clunky" code, or a medical application with "clunky" code? After all, is something better than nothing? I wonder how the ObamaCare applicatiion would have function if it was done in a manner better than a "...little clunky".
Dan Guzman-481633
Dan Guzman-481633
SSC Journeyman
SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)SSC Journeyman (84 reputation)

Group: General Forum Members
Points: 84 Visits: 386
I've become a fan of agile (sic lower-case) development methodologies for this exact reason. It is up to the team to decide how good is good enough by balancing resources (costs), schedule and features. There are cases where time to market trumps perfection and others where it's better to strive for the wow factor. As we database folks like to say, "it depends."
Todd Townley
Todd Townley
SSC Veteran
SSC Veteran (269 reputation)SSC Veteran (269 reputation)SSC Veteran (269 reputation)SSC Veteran (269 reputation)SSC Veteran (269 reputation)SSC Veteran (269 reputation)SSC Veteran (269 reputation)SSC Veteran (269 reputation)

Group: General Forum Members
Points: 269 Visits: 475
I have certainly done initial development on ideas that I then released to my team for further development. The initial code worked for my situation, and was an improvement on what we had previously (which was nothing). I expect my team to take the concepts, then continue to improve and enhance as they make use of the code in their own projects. In this case, I have no problem starting out "a little clunky".

I've been recently involved in a project where the initial development (if you want to call it that) was "a little clunky" in order to get something off the ground, but then became the standard method moving forward. Because it "worked", there was no company incentive to change it. Then a new release of our software came out and the whole process melted down. Now there is a new initiative to create something else a little less clunky, rather than doing the correct (albeit expensive) thing.

Relating to the Rolls-Royce analogy, this was like trying to farm 1000 acres with a tractor from 1950, because the tractor was cheap. Now that it broke down, rather than buying what it takes to do the job (because it's too expensive), we'll just buy a tractor from 1960 this time. I can tell you right now it won't hold up, and we'll be back to square one.

Certainly there is a judgement call as to when "a little clunky" is okay.
Tom John-342103
Tom John-342103
SSC Journeyman
SSC Journeyman (80 reputation)SSC Journeyman (80 reputation)SSC Journeyman (80 reputation)SSC Journeyman (80 reputation)SSC Journeyman (80 reputation)SSC Journeyman (80 reputation)SSC Journeyman (80 reputation)SSC Journeyman (80 reputation)

Group: General Forum Members
Points: 80 Visits: 284
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.
bryanellis
bryanellis
SSC Rookie
SSC Rookie (26 reputation)SSC Rookie (26 reputation)SSC Rookie (26 reputation)SSC Rookie (26 reputation)SSC Rookie (26 reputation)SSC Rookie (26 reputation)SSC Rookie (26 reputation)SSC Rookie (26 reputation)

Group: General Forum Members
Points: 26 Visits: 21
This reminds me of a programming test I had when in college. The professor gave us a single task: get the top 10 student names alphabetically from the college database. The database was in an unsorted text file and we had to use assembler language. I asked a simple question "Does efficiency count?" to which he responded "No". I promptly left the classroom for the computer lab. 30 minutes later I had the 10 names by running through the list 10 times. While extremely inefficient it gave the answer to the problem. I went back to the classroom and found the professor still lecturing the rest of the students on how to build a merge sort. To my knowledge I was the only one to finish the test in the class period. Many times a business user just needs an answer, not always a solution that can be repeated efficiently in the future.
roger.plowman
roger.plowman
SSChasing Mays
SSChasing Mays (613 reputation)SSChasing Mays (613 reputation)SSChasing Mays (613 reputation)SSChasing Mays (613 reputation)SSChasing Mays (613 reputation)SSChasing Mays (613 reputation)SSChasing Mays (613 reputation)SSChasing Mays (613 reputation)

Group: General Forum Members
Points: 613 Visits: 1121
I've been a developer for over 35 years. While there is a *little* merit in "good enough" coding (but who decides "good enough"?) the refrain of "shipping is a feature" covers a multitude of sins.

Yes, you need to get it out the door--but no, don't expect your cobbled-together solution that mostly works to ever see any refactoring. Because if you don't have time to do it right you almost certainly won't have time to do it over. You or anyone else in your programming shop.

Now, having said that judgment calls about "good enough" must be made. Is a 1 hour run time good enough? Not if it's for an interactive system! Does one solution beat another 100-fold in performance? Then the original clearly isn't good enough. But what about 20%? Or 5%?

If your developers have time to refactor code, then they have time to refactor before release, marketing be damned.

Or it's HealthCare.gov all over again...
skeleton567
skeleton567
SSC-Enthusiastic
SSC-Enthusiastic (130 reputation)SSC-Enthusiastic (130 reputation)SSC-Enthusiastic (130 reputation)SSC-Enthusiastic (130 reputation)SSC-Enthusiastic (130 reputation)SSC-Enthusiastic (130 reputation)SSC-Enthusiastic (130 reputation)SSC-Enthusiastic (130 reputation)

Group: General Forum Members
Points: 130 Visits: 368
My 42 years of IT experience all the way from a beginning code writer to database administrator, including 13 years of management taught me that quality of design and functionality is critical, and CAN be delivered with adequate MANAGEMENT of entire projects.

the current ObungledCare is a prime example. My career spanned the change from dependability to delivery, and I think I understand the consequences. The major consequence is the ongoing cost of supporting failures and validity issues daily.

You either pay the one-time cost of proper development or the ongoing cost of supporting bad design, development, AND testing.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search