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 ««123»»

Quality Over Timing Expand / Collapse
Author
Message
Posted Wednesday, March 9, 2011 7:30 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: 2 days ago @ 3:14 PM
Points: 364, Visits: 1,333
Customers require (almost) immediate satisfaction for a low price. They often forget that they are not paying a developer for doing some typing.
I have not seen really good product documentation for years. Microsoft's MSDN is far worse now than ~10 years ago. TechNet seems still better.
One of my customers asked me recently for a code review for his real estate website. There was no written documentation; even the code was not commented at all. He has not been willing to pay the developer for the additional time. Nice way to shoot yourself in the foot.
Post #1075544
Posted Wednesday, March 9, 2011 7:39 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Sunday, November 23, 2014 2:48 PM
Points: 1,754, Visits: 4,966
This piece is a few years old, and it talks about how quality has become more important at many large software vendors. Looking back across the five years since the article was written, do you agree?

For the IT departments of large publicly traded US corporations, one development of the past few years are the new SOX regulations. The emphasis on process, seperation of duties is now required. Also, the growing number of software vendors who provide service oriented architecture to external clients kow they are held to a higher level of scrutiny. It's a lot easier to say "Oops! Let me fix that." to an internal client than an external client or auditor.
Post #1075553
Posted Wednesday, March 9, 2011 7:43 AM
Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Friday, November 21, 2014 6:04 AM
Points: 699, Visits: 1,754
Many Developers are still of the ilk that they've been given an assignment and they just want to get it off their proverbial plate.


Many developers are overloaded and have too much work to do and too many bosses to please...
Post #1075556
Posted Wednesday, March 9, 2011 8:27 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Monday, October 27, 2014 8:55 AM
Points: 1,639, Visits: 1,985
Jeff Moden (3/9/2011)
Oddly enough, I don't blame the customers. On the jobs where I've been able to contact the customer directly instead of through a PM, I've been able to convince them that it really is in their best, long term interest with THEIR customers to do things right the first time.

Someday I'm going to have to open a development shop of my own where the slogan is, "If you want it real bad, we won't let you have it that way."


I haven't seen that personally just due to the development environment I've been in. However, I have friends in a graphic design firm that have seen that where the PM didn't stress the downsides of doing something enough (like the inability of being able to bookmark Flash pages.)

I like that slogan. It may mean turning away clients but that's not always a bad thing. One of the things I've wondered about is whether or not my company is vetting our clients enough for the enterprise level application I work on. We've had a number of deals that I really wonder if were in our best interest. On the flip side, I just watched a presentation where it was said a competitor was kicking everyone's butt in a certain market space because they were being selective about their clients.
Post #1075599
Posted Wednesday, March 9, 2011 8:31 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Monday, October 27, 2014 8:55 AM
Points: 1,639, Visits: 1,985
david_sipos (3/9/2011)
The "pressure of immediacy" seems to be literally changing our concept of time. Are the posts you make to Facebook, Twitter, etc, so urgent they must be delivered throughout the day?


My company has seen this in several ways and the pressure to get things done quickly overrides the pressure to get them done right frequently. Even after a major new release severely fell short of quality expectations. One of the things I've tried to be good about is pushing back on that. Fortunately, by and large I've been successful. However, I'm on the bug fix team not on the new development team so I'm not under as much pressure to get the next pretty thing out.
Post #1075605
Posted Wednesday, March 9, 2011 8:44 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, April 15, 2014 12:50 PM
Points: 3, Visits: 89
This week I have 16 meetings that I have to attend and I'm also concurrently coding on 4 unrelated applications, managing several SQL Servers, as well as other admin minutae for various servers, answering questions, and debugging & researching crap for apps that I have developed and apps from coders that are no longer with the company.

I've been running like this for just short of two decades and it has just gotten worse -- this year in particular. I don't know if other internal development groups run like this but it's impossible for me to tend to the level of quality that I want simply due to the amount of task switching I have to do during the day.

Amazingly, I have been able to fudge it for a long time now and I have a great set of users that are ok with me getting to 80% of their needs and scrambling to fix bugs that are nearly always because of my lack of attention to details because I have too much to do and too many interruptions, and etc..

Is this my fault? Probably, but it's a systemic relationship issue between me, my boss, his bosses, and our users. The group dynamics support this way of doing things. For this to change we need a company and culture wide paradigm shift. That being said my team is working on a method to address this chaos because it's simply not sustainable.

But one point I would make is that I feel we, as an industry, are just now actually figuring out how to write software. And we should remember that as an engineering discipline our industry is just getting started.

Along with this site, tekpub, cleancoders.com, and others we are finally just starting to get and idea of how to create and maintain software, how to actually use patterns, how to communicate with and manage users. We've been winging it for about 60+ years and we are just being able as an industry to discern what works and what doesn't. We have spent most that time re-inventing the wheel -- we keep solving the same problems with different variations of the same code.



Post #1075615
Posted Wednesday, March 9, 2011 12:16 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, August 28, 2014 1:35 PM
Points: 113, Visits: 423
More and more I find myself leaning toward a sub version of the "Agile programming methodology", though this kind of thinking works better for somewhat smaller web-based programs than traditional large software releases like SQL Server. As a small independent developer I too have experienced users not really knowing what they want, but if I use a modular "Agile" approach I can mock up a more or less working version of a new feature and put it quickly into production to see if this is really what the users want and if it is I can (hopefully) spend the time to improve the code later to eliminate bugs etc... When you don't know if a feature will really meet the needs of your users because they don't really know what they want themselves, it just makes a lot more sense to focus on speed over quality, since spending a lot of time getting a feature perfect when in the end it won't really meet the business need of the user just makes no sense at all.
Post #1075793
Posted Wednesday, March 9, 2011 12:31 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, April 15, 2014 12:50 PM
Points: 3, Visits: 89
krowley (3/9/2011)
When you don't know if a feature will really meet the needs of your users because they don't really know what they want themselves, it just makes a lot more sense to focus on speed over quality, since spending a lot of time getting a feature perfect when in the end it won't really meet the business need of the user just makes no sense at all.


I think you nailed it on the head there!
Post #1075814
Posted Wednesday, March 9, 2011 1:07 PM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Yesterday @ 8:51 PM
Points: 35,606, Visits: 32,190
Mark W Johnson (3/9/2011)
krowley (3/9/2011)
When you don't know if a feature will really meet the needs of your users because they don't really know what they want themselves, it just makes a lot more sense to focus on speed over quality, since spending a lot of time getting a feature perfect when in the end it won't really meet the business need of the user just makes no sense at all.


I think you nailed it on the head there!


Again, this is where I talk with the user because it makes no sense to write code for something the user isn't sure of.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1075855
Posted Wednesday, March 9, 2011 1:18 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, August 28, 2014 1:35 PM
Points: 113, Visits: 423
Jeff Moden (3/9/2011)
Mark W Johnson (3/9/2011)
krowley (3/9/2011)
When you don't know if a feature will really meet the needs of your users because they don't really know what they want themselves, it just makes a lot more sense to focus on speed over quality, since spending a lot of time getting a feature perfect when in the end it won't really meet the business need of the user just makes no sense at all.


I think you nailed it on the head there!


Again, this is where I talk with the user because it makes no sense to write code for something the user isn't sure of.


Sometimes it is (or at least seems) quicker and easier to simply write up some code to mock up a feature when I have a general idea of what the user wants than to spend another several hours in meetings trying to make the user decide what they really want. There comes a point where you just have to create SOMETHING and then refine from there, rather than trying to gets the specs exactly right the first time.
Post #1075862
« Prev Topic | Next Topic »

Add to briefcase ««123»»

Permissions Expand / Collapse