Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12345»»»

Effectiveness Expand / Collapse
Author
Message
Posted Wednesday, November 6, 2013 9:03 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 12:34 PM
Points: 31,181, Visits: 15,626
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
Post #1512075
Posted Thursday, November 7, 2013 12:27 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Monday, October 13, 2014 12:23 AM
Points: 87, Visits: 277
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.
Post #1512109
Posted Thursday, November 7, 2013 2:34 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Monday, September 22, 2014 1:55 AM
Points: 34, Visits: 163
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.
Post #1512159
Posted Thursday, November 7, 2013 3:36 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Saturday, August 16, 2014 8:30 PM
Points: 3, Visits: 73
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".
Post #1512173
Posted Thursday, November 7, 2013 4:30 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Sunday, October 19, 2014 11:12 PM
Points: 57, Visits: 300
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."
Post #1512189
Posted Thursday, November 7, 2013 6:34 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Thursday, September 18, 2014 2:56 PM
Points: 246, Visits: 383
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.
Post #1512229
Posted Thursday, November 7, 2013 6:42 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, October 1, 2014 6:23 AM
Points: 67, Visits: 235
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.
Post #1512234
Posted Thursday, November 7, 2013 6:47 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, October 15, 2014 1:14 PM
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.
Post #1512235
Posted Thursday, November 7, 2013 6:47 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Monday, December 2, 2013 6:30 AM
Points: 346, Visits: 691
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...
Post #1512236
Posted Thursday, November 7, 2013 6:57 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Saturday, October 18, 2014 6:09 PM
Points: 58, Visits: 188
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.
Post #1512242
« Prev Topic | Next Topic »

Add to briefcase 12345»»»

Permissions Expand / Collapse