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 1234»»»

A Software Warranty Expand / Collapse
Author
Message
Posted Sunday, October 21, 2012 4:27 AM


SSC-Dedicated

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

Group: Administrators
Last Login: Yesterday @ 4:10 PM
Points: 33,095, Visits: 15,202
Comments posted to this topic are about the item A Software Warranty






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1375155
Posted Sunday, October 21, 2012 10:19 AM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Yesterday @ 1:33 PM
Points: 8,571, Visits: 9,076
Well, I'm totally in favour of Ms Smith's views, except perhaps where she writes "Explicitly dealing with failure" in her list of problems where she clearly means "Not explicitly dealing with failure". I've written the odd diatribe on that topic (which has included suggesting that those who simultaneously fail to deal with failure while logging too much irrelevant junk and logging no useful diagnostics, so that they fail on all Ms Smith's first three bullet points - which for me are just essential parts of error management - should be locked up and not be permitted to develop anything or manage anything. Unfortuantely the concensus amongst holders of degrees in IT and of MBAs seems to be that anyone who wants error management should be locked up and shunned , so I used to spend a lot of time being rather grumpy.

I think your editorial watered it down rather a lot, and this passage is why I rated it only 3 stars (otherwise I would probably have rated int 5 starts for raising such an important - and controversial- topic:
I like this idea, though I don't think that it should be a continuous expectation with developers required to support their code forever. I would like to see developers giving their code a "warranty" of sorts, perhaps a couple months of priority support when code is deployed into live environments with developers taking responsibility and responding to calls, even after hours.

A couple of months is nowhere near enough for the users to develop power users who will be pushing the product to its limits and discovering the bugs that are hard to fix. I suspect you are making the same mistake as one of the commenters on the original post, and treating the "you" in "you write it, you support it" as refering to an individual instead of to the development team as a whole, because I can't imagine any reason for limiting this support to a couple of months other than that the person who wrote the code may no longer be available.

Of course there has to be a proper understanding of which parts of support are a development responsability: holding the users hand, making sure that he remembers to plug the power lead in, and so on isn't a development responsability (it's actually the responsability of the user's manager). Neither is what I call "first line support" (usually fixing the user's failure to RTFM, and rarely explaining errors in TFM). But second line support - helping the user to model what the product does when the manual fails to deliver the required information - and third line support - fixing the errors and omissions in the product - should always be considered a development responsability.

I worked full time in software and database R&D for more than 40 years (that's excluding time as a research student) and was a recruiting manager for most of that time (about 30 years, not all at the end of those 40+). Very early on I adopted a policy of not recruiting people for anything other than very junior/new graduate posts who didn't have real experience of customer support, because people without that experience tended not to be particularly careful about making sure their stuff worked in all imaginable circumstances (of course no-one succedes in doing that all the time, but people without customer support experience tend not even to try hard). Developers who think they have more important things to do than make their product work for the customers are, IMHO, a waste of space, and development teams who have that collective ethic even more so.


Tom
Post #1375179
Posted Sunday, October 21, 2012 1:00 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:06 PM
Points: 36,786, Visits: 31,243
While I agree that some developers are better than others and some deserve to be shot out of a cannon into a stone wall, I think way too much onus is put on the developer for writing quality code that won't break somewhere down the road especially in the case of a major increase in scale as so may software products are exposed to. It takes a team to make it and it takes a team to break it. The "team" starts with management and is quickly destroyed by some of the ridiculous schedules they put on developers. They seem to forget that if you want something real bad, you'll normally get it that way.

--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 #1375199
Posted Monday, October 22, 2012 1:19 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, July 28, 2014 3:45 PM
Points: 2,892, Visits: 1,784
They seem to forget that if you want something real bad, you'll normally get it that way.


I'll be using that comment a few times I think.

I think IT needs restructuring so you get end-to-end ownership of a product. What is produced needs to be viewed as a product that has to be something a customer would choose to buy, not something that is thrust upon them.

In the data space we face a double-whammy in that not only must a system work reliably but the data it produces must be of quality. These two things aren't necessarily the same thing.

Problems where things break under production loads are generally excused by there being no representative test environment. I have worked for only one company that has an AS-LIVE environment whose only difference from the live environment was that it ran at LIVE+25% load. I failed to appreciate just how valuable that was at the time. Older and wiser now!

We do have a software warranty period where I work now. This is nominally two weeks after production sign it off as fit for purpose but if something major crops up all sign-offs are null and void.
Irritating niggles however stay, seemingly for the life time of the product.


LinkedIn Profile
Newbie on www.simple-talk.com
Post #1375280
Posted Monday, October 22, 2012 1:42 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: 2 days ago @ 2:18 AM
Points: 559, Visits: 1,159
It's not just developers who have to take responsibility. When a piece of software is commissioned by a section of our business it has to go through user acceptance testing and be signed off as fit for purpose before it is released into the live environment. Some departments are thorough at testing whilst others just have a quick look and sign off and there's usually after release problems with the latter. And yes, the developers do the second line support as well.
Development has to be a two way process between users and developers otherwise the whole exercise is a complete waste of time.
Post #1375288
Posted Monday, October 22, 2012 5:03 AM


SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: 2 days ago @ 1:35 AM
Points: 98, Visits: 740
I personally support this fully and I agree with a strategy of developers supporting their products throughout their entire life.

As much as anything it gives you really useful information on how people actually use user interfaces and what is successful and what isn't successful. It is for instance entirely possible to develop systems that while they never break are never used potentially just because the UI is unusable.

The interesting thing about that is that developers will have to get into the mindset of producing software that is low maintenance while very usable as they will otherwise end up not being able to take on new projects as they need to support old products. I think it will keep them tied to the high value critical systems as well as ensuring continuity for users.

Some of the best open source software projects have been developed by users who needed to use the product as much as develop the product and as such they develop / maintain and use the software all the time. If you can ever get to talk to these individuals they are nearly always industry leaders in their particular peice of software.
Post #1375336
Posted Monday, October 22, 2012 5:55 AM
SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Wednesday, May 7, 2014 1:01 PM
Points: 176, Visits: 120
I know a large telecom that paid bonus on fixes in production to developers. This did not work out for them as people left bugs in knowing they would fix them later. Management fixed this by sending the work overseas. The work is now coming back (That cost savings experiment did not go well.) and one can only wonder if the fix a bug make a bonus plan will as well? Of course we all know about Facebook and the karma account that grades your code deployment with user feedback added or subtracted to your karma account (An old online game reworked for bug tracking.) and then pulled up at your review time. But getting back to support the truth be told most developers do not wish to be bothered with support and for good reason. It tends to show all the flaws in ones work and no one wants to see that.
Post #1375359
Posted Monday, October 22, 2012 6:01 AM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Yesterday @ 1:33 PM
Points: 8,571, Visits: 9,076
Jeff Moden (10/21/2012)
While I agree that some developers are better than others and some deserve to be shot out of a cannon into a stone wall, I think way too much onus is put on the developer for writing quality code that won't break somewhere down the road especially in the case of a major increase in scale as so may software products are exposed to.

If the major scale increase is explicitly pointed out in the requirements and sufficient resource (time, equipment, people) is provided to do testing at that increased scale before release, I think it's fair to put that onus on the development team. If it isn't clearly there in the requirement, then it's an enhancement. Even if it is there in the requirement, it may be appropriate to make an early release with scaling restrictions (which have to be very clearly documented) and it would be unreasonable to expect that release to support the increased scale, because product development to provide the increased scale would not yet have been done.
It takes a team to make it and it takes a team to break it. The "team" starts with management and is quickly destroyed by some of the ridiculous schedules they put on developers.
It often ends with management too - one manager can easily break a development. The thing to do is to try to avoid working for or doing business with companies that employ incompetent managers, but that isn't always easy.
They seem to forget that if you want something real bad, you'll normally get it that way.
That's almost a definition of someone with a sales or accounting background "managing" development - almost because to be 100% you have to omit "seems to".


Tom
Post #1375361
Posted Monday, October 22, 2012 6:11 AM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Yesterday @ 8:06 PM
Points: 36,786, Visits: 31,243
Precisely, Tom. Thanks for filling in the holes on my short statement.


--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 #1375367
Posted Monday, October 22, 2012 6:20 AM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Yesterday @ 8:06 PM
Points: 36,786, Visits: 31,243
Dalkeith (10/22/2012)
I personally support this fully and I agree with a strategy of developers supporting their products throughout their entire life.


I have to say that I don't agree with that. What do you do if the developer goes on vacation, gets sick, leaves the company, gets promoted, wins the lottery, or flat out dies?

This is what teams and cross training are for. Although individuals may create parts of the product, the team must eventually support it so that no one individual becomes indispensable.


--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 #1375372
« Prev Topic | Next Topic »

Add to briefcase 1234»»»

Permissions Expand / Collapse