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 Monday, October 22, 2012 7:04 AM


SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Today @ 12:07 AM
Points: 101, Visits: 759
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.
Post #1375403
Posted Monday, October 22, 2012 8:04 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Monday, December 2, 2013 6:30 AM
Points: 346, Visits: 691
It must be nice to have a team of developers on call.

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).
Post #1375436
Posted Monday, October 22, 2012 8:30 AM


SSC-Dedicated

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

Group: Administrators
Last Login: Today @ 9:49 AM
Points: 33,169, Visits: 15,302
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.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1375458
Posted Monday, October 22, 2012 8:54 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, September 10, 2013 8:20 AM
Points: 17, Visits: 66
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.
Post #1375477
Posted Monday, October 22, 2012 9:16 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: Monday, August 11, 2014 12:27 PM
Points: 557, Visits: 730
roger.plowman (10/22/2012)
It must be nice to have a team of developers on call.

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?
Post #1375501
Posted Monday, October 22, 2012 9:53 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Thursday, August 7, 2014 3:34 PM
Points: 2,282, Visits: 1,341
Steve Jones - SSC Editor (10/22/2012)
I think that builds a dread in developers that any mistake will haunt them for a long time.


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.



Not all gray hairs are Dinosaurs!
Post #1375551
Posted Monday, October 22, 2012 10:08 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
"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!

Post #1375573
Posted Monday, October 22, 2012 10:13 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 8:09 AM
Points: 7,135, Visits: 15,148
Steve Jones - SSC Editor (10/22/2012)
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.


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.


----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Post #1375579
Posted Monday, October 22, 2012 10:49 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Thursday, August 7, 2014 3:34 PM
Points: 2,282, Visits: 1,341
Chris Ammann (10/22/2012)
"That was a long time ago I don't know whats wrong just fix it"


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?


Not all gray hairs are Dinosaurs!
Post #1375610
Posted Monday, October 22, 2012 12:10 PM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Wednesday, August 13, 2014 6:34 AM
Points: 1,566, Visits: 1,851
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.
Post #1375661
« Prev Topic | Next Topic »

Add to briefcase ««1234»»»

Permissions Expand / Collapse