SQLServerCentral / Editorials / SQLServerCentral.com / A Software Warranty / Latest Posts

RE: A Software Warranty

Steve Jones - SSC Editor — Wed, 24 Oct 2012 08:21:53 GMT

[quote][b]Rod at work (10/22/2012)[/b][hr] do you have the developer responsible, at least for a while, for the LOB apps they put out?[/quote]I think so. We've had it both ways in a couple large places I worked. Didn't necessarily help quality overall, especially with turnover, but a few people that stuck with the company for a long time learned to do a better job in development since they'd be stuck working late or on-site supporting things.Some of them, I suspect, didn't test, just to get the chance to get a break from their other work and change environments. That works too, as long as they are providing support.

RE: A Software Warranty

Keith Langmead — Wed, 24 Oct 2012 07:30:47 GMT

[quote][b]Kevin.Young 56119 (10/23/2012)[/b]I've been in situations where management commissioned a software project on behalf of a department. The department itself is not interested in the software, they want to maintain "the way they've always done it".[/quote]That's certainly part of it, though I suspect more often it's more connected with Management's attitude that the workers shouldn't have a say, and will use whatever systems they're given. Of course they're just staff, they're paid to do a job, and you can't run a company by putting everything to a vote with everyone, but if they don't like it they sure can make your life difficult. To my mind you HAVE to get the people using the new system to understand why it's better, and if it isn't then you've identified where things need changing.We had a similar situation deploying Office 2010 for a client of ours. Most of the normal staff hated it initially since they couldn't find things, but we took the time to go round each of them individually, show them how the new version worked, find out the tasks they normally do and show them how they're done in the new version. After that they were all happy, understood the reasons for the upgrade, and in many cases preferred it.With development projects it probably depends on the specific setup how it works, but I certainly think that any developer should expect any problems to come back to them for a period after "completion". Long term you'd expect support to be passed on to others, and since the project should be documented that shouldn't be an issue. To my mind it should be a transitional process. Initially the original developer supports it, then the developer moves to more of a 2nd line role with 1st line working from their documentation. If 1st line can't resolve an issue based on the documentation, 1) the dev has to get involved, and 2) the documentation is potentially incomplete and needs revising. This way, the more effort the dev puts into documenting their work the less they're interrupted later on. I adopt the same method with sysadmin projects, I document what I do as much out of enlightened self-interest as anything. If I don't document something I'm stuck supporting it forever, but if I do it well then anyone can pick it up, they don't need me (other than 3rd line situations), and I can get on with new cool projects instead!

RE: A Software Warranty

Kevin.Young 56119 — Tue, 23 Oct 2012 09:02:15 GMT

[quote][b]P Jones (10/22/2012)[/b][hr]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.[/quote]I could not agree more. Theproblem that I see most often is passive/aggressiveness or a battle of wills between a department and management. I've been in situations where management commissioned a software project on behalf of a department. The department itself is not interested in the software, they want to maintain "the way they've always done it". They are not interested in helping with the requirement/discovery process and they are, most certainly, not interested in testing the software during UAT. Then suddenly the go live date shows up, they realize that the software is not going away and they reluctantly start using it. At that point, all the bugs that should have been caught in UAT come to the front. They complain that the software is not working the way it should to management, and then the developers are scrambling to fix major problems.In the meantime, the department next door diligently tested their software in UAT and all major problems were corrected. The go live date comes along and there are some minor bugs. However at this point, there are no resources to put on them because the project team is scrambling to fix all the major issues from the department that didn't test. So what you get from the outside looking in, is the perception that the developers aren't doing a good enough job supporting their code.I've worked in several different industries and unfortunately this type of situation happens way too often.

RE: A Software Warranty

roger.plowman — Tue, 23 Oct 2012 07:00:41 GMT

[quote][b]L' Eomot Inversé (10/22/2012)[/b][hr][quote][b]roger.plowman (10/22/2012)[/b][hr]1) They're too busy to beta test software. 2) They're not too busy to call and complain.3) They don't remember you have to sleep.4) 18/7/365 on call [i]sucks[/i] unless you're very very good at preventing errors from happening in the first place.[/quote](i) So they should be, they have a job to do which isn't acting as guinea pigs for half-baked software from some supplier. You should deliver a working product. If you can't find users willing to Beta test, it's probably because what you are calling a Beta Test is a load of sub-Alpha rubbish. Do that testing yourself.(ii) Why shouldn't they complainm if you deliver unworking junk?(iii) Not their problem - it's your employer's problem, not the users' problem.(iv) It doesn't just suck; any employee who accepts that must be desperate to get (or keep) the job, and any employer who proposes that is someone you never want to work for in the first place.[/quote](i) Who then, do you suggest tests the software? We have 1 IT person, who is the person who developed the software. That is not the person who should be testing, correct? Which leaves users, because we don't have anyone else. Built-in code diagnostics are extremely helpful--but they don't catch everything. Our software is custom written in-house, we're our own supplier. It gives us our edge.(ii) Unworking junk? :) No, you misunderstand. It works fine--except in the corner cases that happen once in a blue moon when you hop on one foot and spin around thee times to the right. Problem is that usually happens on nights and weekends when the part time users are on the system. What adds to the fun is their inability to tell you what they did--or anything [i]close[/i] to what they did.(iii) In a small company it's everybody's problem. We all wear multiple hats because we have to, not because we want to. The economics of our business don't allow generous budgets for anything. Which means I have no dedicated IT team. I have no QA department. You sound like you work in a large company with the luxury of specialization. Not all industries support that model.(iv) Or who doesn't like large corporate environments and the office politics that go with them. Service industries like my company is in have certain realities. Narrow operating margins are one of them. And in a down economy those margins get narrower. But at least I don't have to wear a tie. :)My point actually is that in a situation like mine you [i]have[/i] to make sure your software is robust. And even then, it's not easy to do. Steve was talking about software warranties, well, in my case it's not just a warranty--it's a lifestyle. (chuckle)

RE: A Software Warranty

tabinsc — Tue, 23 Oct 2012 06:27:20 GMT

RE: A Software Warranty

Jeff Moden — Mon, 22 Oct 2012 21:36:24 GMT

RE: A Software Warranty

L' Eomot Inversé — Mon, 22 Oct 2012 18:56:18 GMT

[quote][b]roger.plowman (10/22/2012)[/b][hr]1) They're too busy to beta test software. 2) They're not too busy to call and complain.3) They don't remember you have to sleep.4) 18/7/365 on call [i]sucks[/i] unless you're very very good at preventing errors from happening in the first place.[/quote](i) So they should be, they have a job to do which isn't acting as guinea pigs for half-baked software from some supplier. You should deliver a working product. If you can't find users willing to Beta test, it's probably because what you are calling a Beta Test is a load of sub-Alpha rubbish. Do that testing yourself.(ii) Why shouldn't they complainm if you deliver unworking junk?(iii) Not their problem - it's your employer's problem, not the users' problem.(iv) It doesn't just suck; any employee who accepts that must be desperate to get (or keep) the job, and any employer who proposes that is someone you never want to work for in the first place.

RE: A Software Warranty

Mark Classen — Mon, 22 Oct 2012 16:17:44 GMT

A little bit of devil’s advocate here. It seems there is a correlation between management’s willingness to bypass established development workflow (and the checks within it) and the frequency of bugs / issues in prod releases. Assuming this, giving developers the access to production systems with enough rights to support them also gives them the ability to develop this and other products directly on production servers. This is a double edged sword and seems a bit like rewarding them (with the prod access they tend to clamor for daily) for making buggy code – reinforcing the behavior this is trying to prevent. While it may feel a little better knowing you are not alone on the conference call at midnight, it has not solved any process issue in my experience.There is no replacement for a properly managed development workflow that includes required testing / workflows / environments / requirements / etc that has the best chance of catching the issue prior to deploy.

RE: A Software Warranty

TravisDBA — Mon, 22 Oct 2012 14:56:05 GMT

[quote][b]Rod at work (10/22/2012)[/b][hr]I imagine that in such companies there's a really big tendency to have clear delineation in development, QA, test, deployment, IT, etc. I would imagine that its just harder to do what you've suggested in your article. [/quote]Exactly right. Two words come to mind for large organizations nowadays. SarBanes-Oxley:-D

RE: A Software Warranty

Rod at work — Mon, 22 Oct 2012 14:16:26 GMT

I like what you've brought up, Steve, but I wonder how well it works in large environments? Where I work, after layoffs and people jumping ship, we're down to just 2 people in IT/development. Of course we wear multiple hats; we have to. So for us it's easy to do what you've suggesting; we've no choice. But what about companies with hundreds of people in IT/development? I imagine that in such companies there's a really big tendency to have clear delineation in development, QA, test, deployment, IT, etc. I would imagine that its just harder to do what you've suggested in your article. I'd love to hear from others who work for larger IT departments; do you have the developer responsible, at least for a while, for the LOB apps they put out?

RE: A Software Warranty

cksid — Mon, 22 Oct 2012 13:20:56 GMT

[quote][b]roger.plowman (10/22/2012)[/b][hr]It must be nice to have a team of developers on call. :hehe:...Let me tell you something about users:1) They're too busy to beta test software. 2) They're not too busy to call and complain.3) They don't remember you have to sleep.4) 18/7/365 on call [i]sucks[/i] unless you're very very good at preventing errors from happening in the first place.....When you have no budget, [i]literally[/i] no staff, no time, and only minimal code tools you begin to understand just how important it is the software handle every imaginable user stupidity.On the upside it does tend to encourage pride of ownership (laughing).[/quote]I am in the same boat, so I can feel for you. I customized a piece of database software for my office, taking it from the bare bones, high customizable framework to a piece of software that is customized for our office. I've written hundreds of line of code. I support a hundred users in the software.My users are exactly the same as your users - "Testing - what's that? You want me to waste my time testing?" They acted as if testing was something I was to do 100% and catch all of the 'what its' that users come up with. So I test and code for all the possible 'what ifs' I can come up with, call the users for testing and cross my fingers as I push it out to prod. The majority of our issues after going live were due to lack of testing by my users and the users saying "But we do it this way too"... which was never mentioned in development.A year after after going live with the system, I can take vacations without worrying about something going horribly wrong. I check my emails every day for issues even on vacation, so is it really a vacation? But I never push out changes before vacation!

RE: A Software Warranty

Carla Wilson-484785 — Mon, 22 Oct 2012 12:10:29 GMT

As a developer, I WANT to be on the support end. Even though I try to anticipate things like missing required parameters, etc. there is ALWAYS someone who will try to do something that I didn't envision. Sometimes it's another condition I need to test for, and give a useful message back to the user. Sometimes it's for a good reason, and I am pleased if I can provide that functionality. I work in a small group, so avoiding support isn't an option, but I truly enjoy it.

RE: A Software Warranty

Miles Neale — Mon, 22 Oct 2012 10:49:47 GMT

[quote][b]Chris Ammann (10/22/2012)[/b][hr]"That was a long time ago I don't know whats wrong just fix it"[/quote]Chris, that is excellent. Unless it was a long long time ago they do remember it and should be able to assist. But then again there are those who suffer from "selective memory" and cannot remember anything about it at all. Funny they can write similar code that same afternoon that they could not remember in the morning.I think I could pick up my old code from years back and know what the code was doing and why. I might have to look again at the syntax, data, and the sequence of events but I think I could still get there. As well, as a maintainer you or others have had to look at some very old and odd code, determine what is going on with only a hint or two make significant adjustments. How much more should the one who created it from thin air be able to find and fix?

RE: A Software Warranty

Matt Miller (#4) — Mon, 22 Oct 2012 10:13:59 GMT

[quote][b]Steve Jones - SSC Editor (10/22/2012)[/b][hr][quote][b]L' Eomot Inversé (10/21/2012)[/b][hr]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 referring 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.[/quote]I was speaking of "you" as the author of the code, not the department. While the department should support the code forever, the author, who may or may not be there, shouldn't be tasked with long term support, especially after hours. I think that builds a dread in developers that any mistake will haunt them for a long time.A couple of months weeds out the major, obvious bugs. Things that should be caught earlier, and I think it's fair for the author to get some "on call" time to iron those out if they shortcut development. However a year later when a power user finds a problem, I would argue the bug should go through a submittal, triage, and fix by someone in development, not necessarily the author.[/quote]I think there's a bit of a red herring going. Most of the time developers end up supporting their apps until death because of the deplorable documentation of both the project objectives, the constraints and assumptions and whatever the acceptance for said project should be. It's not a matter of whether they HAVE to, but more than no one else can pick up for them since noone has enough info for the context.Until you start getting a meaningful set of requirements with testable outputs which can be matched up to good covering unit and end-to-end tests that validate the functionality, a warranty is completely and utterly meaningless.Now - we developers also play a part in that, since we too ften don't spend enough time documenting HOW we did something or WHY we chose a specific design over another, but we're only one small part of a much bigger issue.

RE: A Software Warranty

Chris Ammann — Mon, 22 Oct 2012 10:08:03 GMT

"So yes the developer is involved heavily for four or so months and they should be directly involved with knowledge transfer to the maintenance team. But they remain involved such that if others cannot fix it they can."If you ever work on a maintenance team you feel the joy of being told by the person that wrote the code "That was a long time ago I don't know whats wrong just fix it"Good times!

RE: A Software Warranty

Miles Neale — Mon, 22 Oct 2012 09:53:15 GMT

[quote][b]Steve Jones - SSC Editor (10/22/2012)[/b][hr]I think that builds a dread in developers that any mistake will haunt them for a long time.[/quote]Steve, I know that it builds dread in the life of developers. Long term maintenance of day to day issues can drive some developers to seek employment elsewhere. And these are both the talented kind of folks and the lazy type. Once a system is deployed and the burn-in period of four months or so is done the project goes strictly into maintenance mode and those who are selected to maintain the code do such. There are then three lines of defence. First the Ops staff who are skilled professionals can fix some of the things that go wrong. Second the selected maintenance team is engaged. This group has had some significant knowledge transfer and experience with the developers and the code. They can find the majority of the problems and are empowered and required to fix them. If the two previous groups cannot find the problem the original development team, writes of the code and the development team architect or strategist may get involved. No one knows the internals of the project better then those who conceived and developed it. To not have this team involved in some way is to put the operational system as a significant level of risk, and will lead to a quicker redevelopment of the system. If you cannot fix it you have to rewrite parts of all of it. So yes the developer is involved heavily for four or so months and they should be directly involved with knowledge transfer to the maintenance team. But they remain involved such that if others cannot fix it they can.M.

RE: A Software Warranty

tabinsc — Mon, 22 Oct 2012 09:16:11 GMT

[quote][b]roger.plowman (10/22/2012)[/b][hr]It must be nice to have a team of developers on call. :hehe:I work for a fairly small company (about 150 employees) and I *AM* the IT department. Support, development, hardware repair, networkworking, etc, etc, etc.Let me tell you something about users:1) They're too busy to beta test software. 2) They're not too busy to call and complain.3) They don't remember you have to sleep.4) 18/7/365 on call [i]sucks[/i] unless you're very very good at preventing errors from happening in the first place.From an enterprise POV the half-dozen servers and probably 150,000 lines of custom code I manage may seem like nothing. But it's just me and my lonesome.So when I hear "management should do X and developers should own their software" I have to roll my eyes. When you have no budget, [i]literally[/i] no staff, no time, and only minimal code tools you begin to understand just how important it is the software handle every imaginable user stupidity.On the upside it does tend to encourage pride of ownership (laughing).[/quote]Yikes! I'd be tempted to work my own schedule and respond to on-call stuff at my own leisure, and see if they have the guts to fire me. It would be their loss. Seriously, you're irreplaceable at that point.

RE: A Software Warranty

gmach — Mon, 22 Oct 2012 08:54:57 GMT

Whether an individual developer supports the code or not, there needs to be a vehicle to do the support. I worked in an organization where a new piece of code was released to our customers, and it allowed all kinds of, um, stupid user tricks. Sure, it worked if users did only what they were told, but they found ways to do things they thought they [b]needed[/b] to do. This allowed for some seriously corrupted data, and a huge effort on the support team's part to get the data analyzed and fixed. The original coder's answer? Oh, it's data. Yeah, buddy... data that was created because the code you wrote let it happen. Gladly I'm no longer there, but I'm betting it isn't any better.

RE: A Software Warranty

Steve Jones - SSC Editor — Mon, 22 Oct 2012 08:30:28 GMT

[quote][b]L' Eomot Inversé (10/21/2012)[/b][hr]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 referring 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.[/quote]I was speaking of "you" as the author of the code, not the department. While the department should support the code forever, the author, who may or may not be there, shouldn't be tasked with long term support, especially after hours. I think that builds a dread in developers that any mistake will haunt them for a long time.A couple of months weeds out the major, obvious bugs. Things that should be caught earlier, and I think it's fair for the author to get some "on call" time to iron those out if they shortcut development. However a year later when a power user finds a problem, I would argue the bug should go through a submittal, triage, and fix by someone in development, not necessarily the author.

RE: A Software Warranty

roger.plowman — Mon, 22 Oct 2012 08:04:41 GMT

It must be nice to have a team of developers on call. :hehe:I work for a fairly small company (about 150 employees) and I *AM* the IT department. Support, development, hardware repair, networkworking, etc, etc, etc.Let me tell you something about users:1) They're too busy to beta test software. 2) They're not too busy to call and complain.3) They don't remember you have to sleep.4) 18/7/365 on call [i]sucks[/i] unless you're very very good at preventing errors from happening in the first place.From an enterprise POV the half-dozen servers and probably 150,000 lines of custom code I manage may seem like nothing. But it's just me and my lonesome.So when I hear "management should do X and developers should own their software" I have to roll my eyes. When you have no budget, [i]literally[/i] no staff, no time, and only minimal code tools you begin to understand just how important it is the software handle every imaginable user stupidity.On the upside it does tend to encourage pride of ownership (laughing).

RE: A Software Warranty

Dalkeith — Mon, 22 Oct 2012 07:04:36 GMT

I've seen the problems of loss of support for applications both when lead developers leave and when bought in systems are no longer supported by the lead developers so I'm not sure that either way protects you from losing general support.The way I would tend to protect against that is try to target the technologies in use to those for which there is a market for developers and yes have a rolling apprenticeship in developer section to ensure new blood regularly comes through and is taught up on existing systems. If the management isn't good enough to manage that then the management ain't good enough.

RE: A Software Warranty

Jeff Moden — Mon, 22 Oct 2012 06:20:15 GMT

[quote][b]Dalkeith (10/22/2012)[/b][hr]I personally support this fully and I agree with a strategy of developers supporting their products throughout their entire life.[/quote]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.

RE: A Software Warranty

Jeff Moden — Mon, 22 Oct 2012 06:11:22 GMT

Precisely, Tom. Thanks for filling in the holes on my short statement.

RE: A Software Warranty

L' Eomot Inversé — Mon, 22 Oct 2012 06:01:38 GMT

[quote][b]Jeff Moden (10/21/2012)[/b][hr]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. [/quote]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.[quote]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.[/quote]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. [quote]They seem to forget that if you want something real bad, you'll normally get it that way. ;-)[/quote]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".

RE: A Software Warranty

Chris Ammann — Mon, 22 Oct 2012 05:55:43 GMT

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. :smooooth:

RE: A Software Warranty

Dalkeith — Mon, 22 Oct 2012 05:03:41 GMT

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.

RE: A Software Warranty

P Jones — Mon, 22 Oct 2012 01:42:21 GMT

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.

RE: A Software Warranty

David.Poole — Mon, 22 Oct 2012 01:19:45 GMT

[quote] They seem to forget that if you want something real bad, you'll normally get it that way. [/quote]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.

RE: A Software Warranty

Jeff Moden — Sun, 21 Oct 2012 13:00:39 GMT

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. ;-)

RE: A Software Warranty

L' Eomot Inversé — Sun, 21 Oct 2012 10:19:58 GMT

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 :angry:, 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: [quote]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. [/quote]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.

A Software Warranty

Steve Jones - SSC Editor — Sun, 21 Oct 2012 04:27:38 GMT

Comments posted to this topic are about the item [B]A Software Warranty[/B]