SQLServerCentral / Editorials / SQLServerCentral.com / Quality Over Timing / Latest Posts

RE: Quality Over Timing

Jeff Moden — Mon, 28 Mar 2011 17:12:51 GMT

RE: Quality Over Timing

Daniel Hallam — Mon, 28 Mar 2011 16:10:39 GMT

I constantly see our developers slap on a new feature quickly thats poorly spec'd, quickly developed, and inadequately tested. Then the business wonders why they have scalability and performance issues. Or loss of productivity waiting for a bug to be fixed.And we don't have a seperate bug fix team, so our developers constantly failing to deliver their next projects while fixing the bugs from the last project.Our developers have such a poor perception amongst the users, they really do despise them thinking they are bunch of muppets, and management will happily blame them when its their pressure to get that new feature in quickly that is as much to blame.And you see it externally too in every other vendor. I'm sure we've all raised our fist in anger at Microsoft due to some bug in a product.

RE: Quality Over Timing

Eric M Russell — Wed, 09 Mar 2011 15:56:37 GMT

[quote][b]Steve Jones - SSC Editor (3/9/2011)[/b][hr][quote][b]Mark W Johnson (3/9/2011)[/b][hr]I don't see my job as writing code so much as solving the user's problem through code; my job is to help them find a solution. I don't expect them to know what the solution looks like.[/quote]Excellent quote. Often we do need to code/mock/show something for the user so they can decide if it's what they want, and how they might change it to meet their needs.[/quote]There are a lot of developers who start off by designing a mockup of the report or web form, something that looks like what the client needs, and then assume that they will go back in another iteration and hook up the "database plumbing" after the client signs off on the visual part.However, I do the reverse. Whenever I get a request for a new report, dashboard feature, etc. that assumes required data will be in the database, the first thing I do is write a basic SQL query that attempts to return the expected numbers. I give the numbers to the business as soon as possible, so we can jump on potential data issues early in the process. There have been times when the request was simply scrapped because the underlying data incomplete for what they need, and that certainly saves a lot of wasted front end work.

RE: Quality Over Timing

Steve Jones - SSC Editor — Wed, 09 Mar 2011 15:01:46 GMT

[quote][b]Mark W Johnson (3/9/2011)[/b][hr]I don't see my job as writing code so much as solving the user's problem through code; my job is to help them find a solution. I don't expect them to know what the solution looks like.[/quote]Excellent quote. Often we do need to code/mock/show something for the user so they can decide if it's what they want, and how they might change it to meet their needs.

RE: Quality Over Timing

Mark W Johnson — Wed, 09 Mar 2011 14:07:24 GMT

[quote][b]krowley (3/9/2011)[/b][hr][quote][b]Jeff Moden (3/9/2011)[/b][hr][quote][b]Mark W Johnson (3/9/2011)[/b][hr][quote][b]krowley (3/9/2011)[/b][hr]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.[/quote]I think you nailed it on the head there![/quote]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.[/quote]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.[/quote]Exactly, I don't think most (seasoned) coders will code something until they are convinced that the user has something worthwhile in mind but just needs help refining it. That was my take on your post.Most significant software challenges rarely have a cut-n-dry solution -- especially in the case of UIs. In my experience, the "final" solution is usual grown from a series of mockups and revisions. I don't see my job as writing code so much as solving the user's problem through code; my job is to help them find a solution. I don't expect them to know what the solution looks like.It seems to me that the process of creating software for an internal user as opposed to a external user lends itself to different levels, degrees, or facets of quality. Since I have direct access to the user, I can get away with lesser quality because I can be quick to respond to bugs or other updates -- plus the "software development" is shared between me and user. The user is a contributer to the product so they have a different expectation and tolerance to the quality of the system. So, in this case, speed is more valuable than quality.But if I'm writing code for an external customer who I don't have access to and the user is not personally involved in the development of the product then quality become more important. It behooves me then to stonewall my PM and say "it'll be done when it's done" and sacrifice speed for quality, otherwise everybody will look bad after the product is put into production.

RE: Quality Over Timing

krowley — Wed, 09 Mar 2011 13:18:11 GMT

[quote][b]Jeff Moden (3/9/2011)[/b][hr][quote][b]Mark W Johnson (3/9/2011)[/b][hr][quote][b]krowley (3/9/2011)[/b][hr]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.[/quote]I think you nailed it on the head there![/quote]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.[/quote]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.

RE: Quality Over Timing

Jeff Moden — Wed, 09 Mar 2011 13:07:59 GMT

[quote][b]Mark W Johnson (3/9/2011)[/b][hr][quote][b]krowley (3/9/2011)[/b][hr]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.[/quote]I think you nailed it on the head there![/quote]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.

RE: Quality Over Timing

Mark W Johnson — Wed, 09 Mar 2011 12:31:14 GMT

[quote][b]krowley (3/9/2011)[/b][hr]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.[/quote]I think you nailed it on the head there!

RE: Quality Over Timing

krowley — Wed, 09 Mar 2011 12:16:38 GMT

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.

RE: Quality Over Timing

Mark W Johnson — Wed, 09 Mar 2011 08:44:41 GMT

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.

RE: Quality Over Timing

cfradenburg — Wed, 09 Mar 2011 08:31:42 GMT

[quote][b]david_sipos (3/9/2011)[/b][hr]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?[/quote]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.

RE: Quality Over Timing

cfradenburg — Wed, 09 Mar 2011 08:27:49 GMT

[quote][b]Jeff Moden (3/9/2011)[/b][hr]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." :-P[/quote]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.

RE: Quality Over Timing

chrisn-585491 — Wed, 09 Mar 2011 07:43:39 GMT

[quote]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.[/quote]Many developers are overloaded and have too much work to do and too many bosses to please... :crazy:

RE: Quality Over Timing

Eric M Russell — Wed, 09 Mar 2011 07:39:27 GMT

[quote]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?[/quote]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.

RE: Quality Over Timing

dmoldovan — Wed, 09 Mar 2011 07:30:57 GMT

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.

RE: Quality Over Timing

blandry — Wed, 09 Mar 2011 06:07:19 GMT

As a big Sci-Fiction fan, one of the things I hate with a passion is how any movie with computers (and software) in it always shows things working perfectly. There is never a blue screen, never an unhandled exception, never a crash...In the real world, in the last 15-20 years software quality has gone out the window finally relenting to sales and release deadlines. How did this happen? "Service packs" and automatic updates. In other words, things are delivered untested, unfinished, and we all then just accept that the next service pack or service release will fix things - or in other words, give us what we actually paid for.Don't you wish just once that our entertainment would reflect that? In the last Die Hard movie, Timothy Olyphant directs his rogue crew to tinker power grids, gas pipelines and all sorts of things that in the real world... Well, if the movie were truthful, Olyphant would have threatened and then tried to tinker these things, but get a message he needed to download the latest service pack.Worse, imagine if other industries worked the way software did. Imagine buying food, poisoning your family, and then calling the CDC or someone and having them ask - "Did you download the latest version of that Lean Cuisine dinner?"...Once we start accepting this kind of thing it become inevitable we will move in the wrong direction - as we are. What we call "quality" these days - well, there was a day when things were delivered "ready" - now? You could get a blank CD, install nothing, and then call the company and have them ask "Did you download the service pack?" - and THAT would be the actual software you purchased...Brave new world indeed - in fact, its the old world, circa 1800 or back.

RE: Quality Over Timing

david_sipos — Wed, 09 Mar 2011 06:01:04 GMT

I believe this is the emerging challenge of balancing expectations, between immediate satisfaction and long-term value. Today, masses of people will pull up to a drive through, place an order and expect a meal costing $6.00 to be returned in approximately 2 minutes. We're mad if it takes longer than 2 minutes, if we're asked to pull aside, or, heaven forbid, they included the secret sauce we so loathe. 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?This dynamic is further challenged my our innate tendency to cooperate and to avoid conflict. Our society is falling into two categories where seem to operate in a mode of passive compliance or radical revolt. Our ability to offer intelligent, constructive discourse seems to be ebbing away. (http://www.ted.com/talks/steven_strogatz_on_sync.html) Then, of course, there is consideration of the cost paradigm. Its challenging to counter this, eventhough logic suggests that long-term value represents real value. This challenge may be best expressed by one of my most favorite Dilbert cartoon.[url=<a href="http://dilbert.comhttp://dilbert.com/strips/comic/2008-03-16/" title="Dilbert.com"><img src="http://dilbert.com" border="0" alt="Dilbert.com" /></a>][/url]Thank you for the editorial. I believe its a topic worthy of continued discussion.

RE: Quality Over Timing

Jeff Moden — Wed, 09 Mar 2011 05:52:32 GMT

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." :-P

RE: Quality Over Timing

TravisDBA — Wed, 09 Mar 2011 05:21:45 GMT

[quote][b]Stefano Padovan (3/9/2011)[/b][hr][quote]There was never enough time to do it right from the beginning for the customer, but there was always time enough to spend hours on end fixing it or redoing it.[/quote]But you normally can't say to a customer of yours that bad planning on his part does not translate in emergency on your part...[/quote]Nope, I've used that on many occassions in the past with users, customers, and managers, but it has never stopped them from doing it again and again. A lot of management just tends to work in firehose mode nowadays, and I have even seen owners of companies that actually endorse and encourage it too. Like I have said many times before. unless true change is embraced from the top down, it never ever works in the long run.:-D

RE: Quality Over Timing

Stefano Padovan — Wed, 09 Mar 2011 03:39:39 GMT

[quote]There was never enough time to do it right from the beginning for the customer, but there was always time enough to spend hours on end fixing it or redoing it.[/quote]And what about spending months waiting for the customer to decide he really needs some piece of software only to discover that when he finally give the start on the project it should really have been ready yesterday :w00t: ?But you normally can't say to a customer of yours that bad planning on his part does not translate in emergency on your part...

RE: Quality Over Timing

TravisDBA — Wed, 09 Mar 2011 03:27:33 GMT

[quote][b]Stefano Padovan (3/9/2011)[/b][hr]Ok, sure, you're totally right: in my dream world everithing would function as you described in your editorial. But from my personal perspective of 'one man army' independent developer (recently two man army as I took up an apprentice ;-) )the biggest issue remains this: my customers for the most part do not know what they want from custom made software BUT they want it really fast.[/quote]This has also been my experience as well. There was never enough time to do it right from the beginning for the customer, but there was always time enough to spend hours on end fixing it or redoing it. Many government oriented operations, as well as private companies, do business this way on a regular basis. Real world. :-D

RE: Quality Over Timing

paul s-306273 — Wed, 09 Mar 2011 02:01:54 GMT

Projects have project managers (ugh!) and they impose deadlines. That leads to compromise, so I'd say ideally you don't compromise on quality but ultimately it's imposed on you.Having said that, some programmers I've worked with would take until the ends of time give the chance!

RE: Quality Over Timing

Stefano Padovan — Wed, 09 Mar 2011 01:56:48 GMT

Ok, sure, you're totally right: in my dream world everithing would function as you described in your editorial.But from my personal perspective of 'one man army' independent developer (recently two man army as I took up an apprentice ;-) )the biggest issue remains this: my customers for the most part do not know what they want from custom made software BUT they want it really fast.In the last years I developed quite a good skill at mind reading but it is not always enough, moreover about 60% of times when I propose a certain approach to a problem it is rejected only to be reconsidered and approved when the project is nearing completion and this mean rushing to re-write tons of code in no time.The sad thing is (from my point of view) that if you enter in the equation the little fact that at the end of the day you have to eat something to keep going on and to eat you must have money to pay for your food... well you certainly see where this is going don't you?I really don' t know how it is in the US but here in Italy, for a whole lot of hystorical reasons, the people who will use the software simply seem not to trust enough the people who design and write it, every minor change to the routine procedures of how thing are made seems at first like a Copernican revolution to the users and I think this is the real issue that lurks at the bottom of the software quality problem.It' not all dark: during the last decade things have improved a bit but I fear we will have to wait another decade before users and customers evolve to a point where they can begin to talk seriously with us about designing and planning of the applications we are going to write for them.

RE: Quality Over Timing

Jeff Moden — Tue, 08 Mar 2011 22:17:20 GMT

Cool picture that, ironically, lives up to what I think of a lot of software vendors that write T-SQL have done and still do... take a look at the printing flaw in the lower right corner of the imprint on the paper. Heh... "BUG!".I'm still finding that software, either custom built or shrink wrapped, ummmm.... sucks. ;-) Even MS blew it on many things in the GUI's of SQL Server 2005 (IMHO) and those same mistakes and shortcomings bled into 2008. Of course, MS isn't the only one that has this problem. People (read that as mostly "managers" and "leads") just don't know how to plan and many Developers still operate under the premise that QA will catch any faults and take the shortcut of not actually testing their own code for both "happy" and "unhappy" paths. 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.Until those attitudes change and much better planning skills are realized, a lot of software will continue to make the same sucking noises under the pressure of delivery schedule that have plagued our industry since it first started.

Quality Over Timing

Steve Jones - SSC Editor — Tue, 08 Mar 2011 21:24:44 GMT

Comments posted to this topic are about the item [B]Quality Over Timing[/B]