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 Thursday, November 7, 2013 7:00 AM
SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Today @ 1:25 PM
Points: 611, Visits: 2,117
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.
Post #1512244
Posted Thursday, November 7, 2013 7:02 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, July 10, 2014 6:48 AM
Points: 63, Visits: 220
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.
Post #1512246
Posted Thursday, November 7, 2013 7:15 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 7:20 AM
Points: 1,767, Visits: 2,141
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
Post #1512252
Posted Thursday, November 7, 2013 7:19 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, July 10, 2014 6:48 AM
Points: 63, Visits: 220
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.
Post #1512254
Posted Thursday, November 7, 2013 7:25 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Tuesday, February 11, 2014 1:58 PM
Points: 65, Visits: 259
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.
Post #1512256
Posted Thursday, November 7, 2013 7:51 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 1:47 PM
Points: 5,196, Visits: 2,823
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!!!
Post #1512280
Posted Thursday, November 7, 2013 7:55 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Yesterday @ 10:44 AM
Points: 213, Visits: 517
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".
Post #1512283
Posted Thursday, November 7, 2013 8:16 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, July 22, 2014 7:10 AM
Points: 46, Visits: 144
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.
Post #1512299
Posted Thursday, November 7, 2013 8:23 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, July 10, 2014 6:48 AM
Points: 63, Visits: 220
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)
Post #1512305
Posted Thursday, November 7, 2013 8:24 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 8:27 PM
Points: 7,120, Visits: 15,016
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?
Post #1512307
« Prev Topic | Next Topic »

Add to briefcase ««12345»»»

Permissions Expand / Collapse