November 6, 2013 at 9:03 pm
Comments posted to this topic are about the item Effectiveness
November 7, 2013 at 12:27 am
Andy Hertzfeld (one of the programmers on the original Macintosh) has this story on shipping:
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.
November 7, 2013 at 2:34 am
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.
November 7, 2013 at 3:36 am
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".
November 7, 2013 at 4:30 am
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."
November 7, 2013 at 6:34 am
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.
November 7, 2013 at 6:42 am
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.
November 7, 2013 at 6:47 am
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.
November 7, 2013 at 6:48 am
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...
November 7, 2013 at 6:57 am
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.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
November 7, 2013 at 7:00 am
john.riley-1111039 (11/7/2013)
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.
Not all pegs nor all holes are the same shape.
You don't apply the same standards to all forms of software. Not every piece of code is life and death. And some applications are not financially justified in being written at all if they need to be perfected to this standard.
Perfection and simplicity are nice aspirations. But delivery date is a requirement, so not meeting it is a bug just as much as anything else.
November 7, 2013 at 7:02 am
Still, the concept of delivery good-enough (if that is what "a little bit clunky" means) is valid and correct since good-enough today is better than perfection a year from now.
The trick for project managers is to determine if good-enough really is good-enough.
Pretty clearly, for something like healtcare.gov which is being made available to potentially millions of users, the quality has to be really good. On the other hand, if you are rolling out an application for a small number of very sophisticated users, they will have some tolerance for quirks and workarounds.
November 7, 2013 at 7:15 am
bryanellis (11/7/2013)
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.
Bet you could have found it by visually scanning the list in 10 minutes or less. Why did you waste 20 minutes?
I'm not picking on this particular poster. This was just the most concrete example of the "hurry it up" at all costs mentality I run into a lot.
I agree with other posters that "it depends". However, slapped together solutions have an annoying habit of living longer than intended. Maintenance costs eat resources.
If I'm doing an ad hoc query, I tend to go for the quick solution, still being mindful of the load I might put on the server.
For anything that gets saved to be rerun, I slow down and try to get it right the first time. Do I always look at the execution plan to squeeze out every inefficiency? No. But I try to be more clever than I would for an ad hoc query. I might be stuck maintaining the beast I created for a long time.
Corners have to be cut on almost every project. But, be careful before you cut.
[font="Verdana"]Please don't go. The drones need you. They look up to you.[/font]
Connect to me on LinkedIn
November 7, 2013 at 7:19 am
When you design and deploy a system, the general concept and architecture need to be sound. You can't really cut corners in this area. However, if the first release "a little clunky" in terms of usability and nuisance bugs, you can deal with the issues.
November 7, 2013 at 7:25 am
You and I probably agree on what is good enough Steve, but I have disagreed many times with my managers and even more with marketing. I get tired of arguing with sayings and comparisons to automobiles instead of people actually making a business case. That may not be easy when shipping the first release, but I've supported products over the course of years, and at some point it's pretty easy to say that you have accumulated too much technical debt and it is time for an overhaul.
When the "good enough" mentality has won the day for so long, it can be hard to make the case to management even though it seems obvious to me. More than once I have had my concerns shot down by someone saying, "well, you made that deadline last time, so I'm sure you'll make it this time." Meeting deadlines is not that hard, creating products that meet the needs is.
Viewing 15 posts - 1 through 15 (of 82 total)
You must be logged in to reply to this topic. Login to reply