October 22, 2012 at 9:53 am
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!
October 22, 2012 at 10:08 am
"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!
October 22, 2012 at 10:13 am
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?
October 22, 2012 at 10:49 am
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!
October 22, 2012 at 12:10 pm
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.
October 22, 2012 at 1:20 pm
roger.plowman (10/22/2012)
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 sucks unless you're very very good at preventing errors from happening in the first place.
....
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).
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!
October 22, 2012 at 2:16 pm
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?
Kindest Regards, Rod Connect with me on LinkedIn.
October 22, 2012 at 2:56 pm
Rod at work (10/22/2012)
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.
Exactly right. Two words come to mind for large organizations nowadays. SarBanes-Oxley:-D
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
October 22, 2012 at 4:17 pm
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.
October 22, 2012 at 6:56 pm
roger.plowman (10/22/2012)
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.
(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.
Tom
October 22, 2012 at 9:36 pm
L' Eomot Inversé (10/22/2012)
roger.plowman (10/22/2012)
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.
(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.
+10,000!!! "Tom for President!"
--Jeff Moden
Change is inevitable... Change for the better is not.
October 23, 2012 at 6:27 am
L' Eomot Inversé (10/22/2012)
roger.plowman (10/22/2012)
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.
(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.
In my experience, if you are delivering a product that will save them time and trouble every week, they will be happy to help with testing. Some of them will even volunteer to test.
Tony
------------------------------------
Are you suggesting coconuts migrate?
October 23, 2012 at 7:00 am
L' Eomot Inversé (10/22/2012)
roger.plowman (10/22/2012)
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.
(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.
(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 close 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 have 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)
October 23, 2012 at 9:02 am
P Jones (10/22/2012)
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.
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.
October 24, 2012 at 7:30 am
Kevin.Young 56119 (10/23/2012)
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".
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!
Viewing 15 posts - 16 through 30 (of 46 total)
You must be logged in to reply to this topic. Login to reply