October 21, 2012 at 4:27 am
Comments posted to this topic are about the item A Software Warranty
October 21, 2012 at 10:19 am
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:
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
October 21, 2012 at 1:00 pm
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
Change is inevitable... Change for the better is not.
October 22, 2012 at 1:19 am
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.
October 22, 2012 at 1:42 am
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.
October 22, 2012 at 5:03 am
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.
cloudydatablog.net
October 22, 2012 at 5:55 am
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:
October 22, 2012 at 6:01 am
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
October 22, 2012 at 6:11 am
Precisely, Tom. Thanks for filling in the holes on my short statement.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 22, 2012 at 6:20 am
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
Change is inevitable... Change for the better is not.
October 22, 2012 at 7:04 am
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.
cloudydatablog.net
October 22, 2012 at 8:04 am
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 sucks 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, literally 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).
October 22, 2012 at 8:30 am
L' Eomot Inversé (10/21/2012)
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.
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.
October 22, 2012 at 8:54 am
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 needed 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.
October 22, 2012 at 9:16 am
roger.plowman (10/22/2012)
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 sucks 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, literally 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).
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.
Tony
------------------------------------
Are you suggesting coconuts migrate?
Viewing 15 posts - 1 through 15 (of 46 total)
You must be logged in to reply to this topic. Login to reply