SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Effectiveness


Effectiveness

Author
Message
Nevyn
Nevyn
Hall of Fame
Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)

Group: General Forum Members
Points: 3612 Visits: 3149
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.
Tom John-342103
Tom John-342103
Mr or Mrs. 500
Mr or Mrs. 500 (560 reputation)Mr or Mrs. 500 (560 reputation)Mr or Mrs. 500 (560 reputation)Mr or Mrs. 500 (560 reputation)Mr or Mrs. 500 (560 reputation)Mr or Mrs. 500 (560 reputation)Mr or Mrs. 500 (560 reputation)Mr or Mrs. 500 (560 reputation)

Group: General Forum Members
Points: 560 Visits: 303
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.
Thomas Abraham
Thomas Abraham
Hall of Fame
Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)

Group: General Forum Members
Points: 3871 Visits: 2256
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.

Please don't go. The drones need you. They look up to you.
Connect to me on LinkedIn
Tom John-342103
Tom John-342103
Mr or Mrs. 500
Mr or Mrs. 500 (560 reputation)Mr or Mrs. 500 (560 reputation)Mr or Mrs. 500 (560 reputation)Mr or Mrs. 500 (560 reputation)Mr or Mrs. 500 (560 reputation)Mr or Mrs. 500 (560 reputation)Mr or Mrs. 500 (560 reputation)Mr or Mrs. 500 (560 reputation)

Group: General Forum Members
Points: 560 Visits: 303
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.
WolforthJ
WolforthJ
SSC Veteran
SSC Veteran (216 reputation)SSC Veteran (216 reputation)SSC Veteran (216 reputation)SSC Veteran (216 reputation)SSC Veteran (216 reputation)SSC Veteran (216 reputation)SSC Veteran (216 reputation)SSC Veteran (216 reputation)

Group: General Forum Members
Points: 216 Visits: 268
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.
Gary Varga
Gary Varga
One Orange Chip
One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)

Group: General Forum Members
Points: 27607 Visits: 6555
Thomas Abraham (11/7/2013)
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.


At college one of the courses I took was split into two halves; one half for those interested in software engineering and the other in business analysis and management. There was plenty of joint modules and everyone seemed to have a leaning one way or the other (and we all - almost all - excelled at times at looked rather foolish at others.

This one girl (for we were all kids then) leaned towards the BA/Management side and struggled with programming. She wasn't stupid at all but programming was not for her. When tasked with printing the alphabet in reverse (in Ada, if I recall correctly) she hardcoded the printing of the alphabet in reverse. She did technically fulfil the task, however, it was part of a module that clearly was to do with looping. I feel that she was too smart to know what she did was what was truly asked of her but didn't have the confidence to pursue one that did.

My point is that a software delivery still needs maintainable for its foreseeable lifetime and performant enough to be usable. Any UI must be reasonably intuitive. It doesn't need to be perfect but it should be developed properly in the context of intended use.

In my anecdote the intended lifetime needed zero maintainability, UI was irrelevant and performance was not an issue but the key requirement of the software was not met (i.e. to demonstrate a technique) so it was a failure. PS I think she did at least OK on the course and has probably been successful in her career - just unlikely as a developer.

Oh and Steve, "a little clunky"? Intentional provocation Mr Editor?

Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
JP Dakota, PRC
JP Dakota, PRC
Old Hand
Old Hand (354 reputation)Old Hand (354 reputation)Old Hand (354 reputation)Old Hand (354 reputation)Old Hand (354 reputation)Old Hand (354 reputation)Old Hand (354 reputation)Old Hand (354 reputation)

Group: General Forum Members
Points: 354 Visits: 563
In the computer world, the call center world, the farming world.....I could go on. But in many lines of work there seems to be this tendency to pit efficient and quality against one-another. I don't want it fast at the expense of quality, and I don't want quality at the expense of efficiency. These two things aren't mutually exclusive, or shouldn't be. Still there is a prevailing attitude that you can have one or the other. I want both. More pressure? Yep. More training? Certainly. More experience? Yes. To quote a popular commercial playing currently in the U.S., "and is better".
skeleton567
skeleton567
SSC Eights!
SSC Eights! (833 reputation)SSC Eights! (833 reputation)SSC Eights! (833 reputation)SSC Eights! (833 reputation)SSC Eights! (833 reputation)SSC Eights! (833 reputation)SSC Eights! (833 reputation)SSC Eights! (833 reputation)

Group: General Forum Members
Points: 833 Visits: 407
So who has this 'small number of very sophisticated users'? I never did. After I retired the first time, I was asked to come back, and ended up working another three years. During that time, I fixed many faults and improved lots of code that was never implemented by managers who were satisfied with 'good enough', to the detriment of data quality and user satisfaction. If users have to circumvent your system to do their job, you have failed. If your support people are constantly handling quality issues and failures, you have failed again.
Tom John-342103
Tom John-342103
Mr or Mrs. 500
Mr or Mrs. 500 (560 reputation)Mr or Mrs. 500 (560 reputation)Mr or Mrs. 500 (560 reputation)Mr or Mrs. 500 (560 reputation)Mr or Mrs. 500 (560 reputation)Mr or Mrs. 500 (560 reputation)Mr or Mrs. 500 (560 reputation)Mr or Mrs. 500 (560 reputation)

Group: General Forum Members
Points: 560 Visits: 303
In some business situations, time is of the essence. If a competitor rolls out a great new offer that requires you to change your systems, and you have to match the offer or lose market share, then you can't wait for perfection. In this sense, business is like war where you invariably go to war with the weapons you have and not the weapons on the drawing board and there is always an insane rush to deploy the next generation of weapons even though the might have teething issues (e.g. the Germans and the Panther tank)
Matt Miller (4)
Matt Miller (4)
SSC-Dedicated
SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)

Group: General Forum Members
Points: 30279 Visits: 19009
Tom John-342103 (11/7/2013)
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.


It's really not up to the Project manager or the Agile team to decide what constitutes "good enough". I think we've strayed way off the mark when IT internally gets to decide what "Good enough" is. This is the same failing that leads to talking about asinine concepts such as "perfect"; you're working outside of the requirements and specifications.

It's entirely OK to build something knowing that it needs to do more than what the current phase requires. That said - what is NOT okay is to go off on a tangent and build something outside of any specifications or requirements. So - you probably should build your data layer to perform well at volumes higher than where they will be day one, but you should still have a specific target performance you're aiming for, which is agreed to by the sponsor.

In a project setting, if there is any major deviation on supportability, performance, etc... these concerns should be bubbled back up to the champion and/or sponsor, along with potential costs and risks associated. They make the call on whether to implement or delay.

----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
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