October 24, 2012 at 8:21 am
Rod at work (10/22/2012)
do you have the developer responsible, at least for a while, for the LOB apps they put out?
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.
October 6, 2016 at 1:55 am
Carla Wilson-484785 (10/22/2012)
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.
Yes. Anyone worth their salt, be they developer or DBA or any other role, should want to see it through. There is such a thing as professional pride. I feel it, Carla obviously feels it and I know that many of you must do too by what you post.
I have seen this best managed by developers rotating into six month stints in support. It encourages a whole team need for high quality. It may be you next. It may be your favourite colleague. It may be your next supervisor. If not this time then most likely next.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
October 6, 2016 at 2:49 am
tabinsc (10/23/2012)
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.
Interesting revenant discussion here - I always like the cut of Tom's jib though appreciate that others are in more desperate situations through no fault of their own.
Anyhow, re: Tony's comment here - that's how it should be and often is. However in other circumstances users - perhaps correctly - perceive that the software is likely to sabotage their idle life and reduce headcount. Their interests definitely do not include letting the software rollout be successful.
October 6, 2016 at 6:58 am
Jeff Moden (10/21/2012)
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. 😉
That is so true.
October 6, 2016 at 7:33 am
It is interesting coming back to these threads four years in the future. Here is what I now appreciate fully
October 6, 2016 at 8:01 am
I spent my last twelve years before retiring with a company which during that time took on a major country-wide development project, first using a number of consultants and then bringing all development in-house. The IT organization was essentially divided into application development, quality control, server support, database design and administration, and so-called 'project management'. After an extensive development effort, the project began to be implemented over parts of the organization at a time in contrast to implementing parts of the application. The unfortunate aspect of the project management was that it included largely non-technical folks who forged ahead with implementation and failed to put any emphasis on fixing problems and issues. Predictably the project, after having cost millions of dollars and a number of years, eventually failed to be implemented to more than a small percentage of the potential users. The product relied heavily on backend SQL code that was originally created by the same folks as the frontend applications. The whole thing was then processed through quality control area for testing and finally given to server support and database administration for implementation.
A main issue that I felt contributed to the eventual drastic scale back and essential failure of the effort was the gulf between developers and support, and the resistance by project management to implementing fixes due to the perceived 'risk' of implementing changes. There were bug fixes and performance improvements created by the DBA/SQL professionals that got stuck in quality control and project management while allowing on-going end user problems and poor data accuracy and reliability. Even when data inaccuracy was proven, fixes were shelved and never implemented. In this situation, even without the original developers being held responsible and involved, the organization structure itself prevented proper support.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
October 6, 2016 at 8:17 am
David.Poole (10/6/2016)
It is interesting coming back to these threads four years in the future. Here is what I now appreciate fully
- Most people want to do things to the best of their ability. We notice the bodge monkeys because what they lack in numbers they make up for in the disruption they cause
- Where possible a small focussed business unit comprising of cross functional business people and cross functional IT people should be formed. A semi-autonomous company within a company
- People need tools and information to be able to self manage quality issues. If you can't measure it (or see it) you can't improve it
- You need a culture that rewards error detection, prevention and correction
- Culture comes from the top. Behaviour descends to the worst behaviour that a leader will tolerate
- People are adults who in their private life are entrusted to borrow 6 & 7 figure sums on their mortgage and to bring up children. This is massively more trust and authority than they are afforded in their jobs.
- If you have small semi-autonomous units there needs to be a means of co-ordinating and monitoring these units to keep them aligned with the corporate strategy
- Quality is everyone's responsibility
- Management is not synonymous with leadership (unfortunately)
All good points.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
October 6, 2016 at 9:11 am
Maybe for an ISV, you have a group of developers who are always focussed on new development and then another team that does primarily maintenance and enhancement. However, everywhere I've worked in past, if you code it, and it fails in production, then you get the call. There typically is no official directive or warranty dictating such, that's just the way it is by default in most corporate IT organizations.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 6, 2016 at 9:55 am
Steve:
"...it calls for developers to support the features that they write, even in production systems. I like this idea, though I don't think that it should be a continuous expectation with developers required to support their code forever."
Having been a software developer/engineer for most of my I.T. career, and a DBA as my second I.T. career, I disagree with the latter part of the quotation.
Software is often very complex. Is it a rational expectation that someone who did not write questionable code should be asked to support it, should be held responsible for making modifications to it to correct a problem?
Are support personal mind readers, who can look at code and understand it, know its history, its effects and side effects, the type and degree of testing that accompanied it?
The best people to support code are the people that created it. No one else on the planet will know as much about it as they do, and their fixes will tend to be implemented most quickly and efficiently.
Plus, there is an incentive here for developers to produce high-quality, bug free, code. If every developer had to support the code he/she wrote forever, my guess is that there would be fewer bugs released into production. My experience of developers is that, in general, they really hate to go back and fix anything. For them, life is about producing more code. Code they wrote a year ago is someone else's problem.
October 6, 2016 at 10:48 am
Gail Wanabee (10/6/2016)
Steve:The best people to support code are the people that created it. No one else on the planet will know as much about it as they do, and their fixes will tend to be implemented most quickly and efficiently.
Plus, there is an incentive here for developers to produce high-quality, bug free, code. If every developer had to support the code he/she wrote forever, my guess is that there would be fewer bugs released into production. My experience of developers is that, in general, they really hate to go back and fix anything. For them, life is about producing more code. Code they wrote a year ago is someone else's problem.
There are probably pros and cons to developer support for SQL code. In our case, they often created both the application code and the SQL code, especially early in the project and the project relied very heavily on backend code. First, the application developers were not necessarily skilled in SQL development and did not understand and focus on data integrity, transaction control, and performance. Second, they just wanted to get the job 'done'. A large part of my task as a DBA was involved in debugging where performance and data integrity were issues. Unfortunately we did not have the support of project management people to accomplish this. Thus issues that we addresses and handled got very little, and sometimes no attention from quality control testers and further up the chain.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
October 6, 2016 at 11:37 am
David.Poole (10/6/2016)
It is interesting coming back to these threads four years in the future. Here is what I now appreciate fully
It certainly is interesting to look again 4 years on. I think that now my view on this have hardened somewhat in regard to corporate responsibility, which I think takes me further away from Steve's original position, and perhaps softened a bit a regards individual responsibility in the sense that I certainly don't expect to support code that I wrote 40 years ago as my contribution to a team effort (partly because people have altered it since to ads new functionality and partly because I no longer have a clue what it was supposed to do, and although I documented it well my employer threw the documentation away as documentation didn't matter). On your detail points I'm a bit here and there.
- Most people want to do things to the best of their ability. We notice the bodge monkeys because what they lack in numbers they make up for in the disruption they cause
Your are excessivley optimistics about the numbers of bodge monkeys.
- Where possible a small focussed business unit comprising of cross functional business people and cross functional IT people should be formed. A semi-autonomous company within a company
- People need tools and information to be able to self manage quality issues. If you can't measure it (or see it) you can't improve it
- You need a culture that rewards error detection, prevention and correction
I agree with those three points - especially the third.
- Culture comes from the top. Behaviour descends to the worst behaviour that a leader will tolerate
Culture is indeed very stongly influenced from the top. But at times behaviour doesn't descend as far as you suggest, because the top would accept standards even lower than those it enforces, and the bottom finds the top's lowest enforced level the limit of how low it will go.
- People are adults who in their private life are entrusted to borrow 6 & 7 figure sums on their mortgage and to bring up children. This is massively more trust and authority than they are afforded in their jobs.
People are often trusted with decisions in their work that that have vastly more financial effect than mortgaging their home has. And people are often trusted to mentor and train youngsters, where they have perhaps as much responsibility but perhaps less personal concern that in bringing up their own kids.
- If you have small semi-autonomous units there needs to be a means of co-ordinating and monitoring these units to keep them aligned with the corporate strategy
I think this is wrong. Units that aren't aligned with corporate starategy are something which companies (especially big ones) should encourage to some extent. I've seen such units save the company when corporate strategy was misguided.
- Quality is everyone's responsibility
- Management is not synonymous with leadership (unfortunately)
I agree with your last two.
Tom
October 6, 2016 at 11:41 am
Gail Wanabee (10/6/2016)
Steve:"...it calls for developers to support the features that they write, even in production systems. I like this idea, though I don't think that it should be a continuous expectation with developers required to support their code forever."
Having been a software developer/engineer for most of my I.T. career, and a DBA as my second I.T. career, I disagree with the latter part of the quotation.
Software is often very complex. Is it a rational expectation that someone who did not write questionable code should be asked to support it, should be held responsible for making modifications to it to correct a problem?
Are support personal mind readers, who can look at code and understand it, know its history, its effects and side effects, the type and degree of testing that accompanied it?
The best people to support code are the people that created it. No one else on the planet will know as much about it as they do, and their fixes will tend to be implemented most quickly and efficiently.
Plus, there is an incentive here for developers to produce high-quality, bug free, code. If every developer had to support the code he/she wrote forever, my guess is that there would be fewer bugs released into production. My experience of developers is that, in general, they really hate to go back and fix anything. For them, life is about producing more code. Code they wrote a year ago is someone else's problem.
Your support folks shouldn't be expected to simply read code and guess at the intent. If that's what your organization routinely does or expects, then I'd recommend everyone push back away from the keyboard and consider the mess you're creating or have created for yourselves. Those statements alone point at some really ugly org issues within IT.
Development requires focus, so expecting developers to routinely split their responsibilities and stop development to hunt down any issue that comes up is simply setting your code quality on an ever steeper drop in quality. The more items you deploy the less time you have, the less focused you become, making you less effective, your code quality drops as a result, leading to even less time. It's a death spiral.
In my past, every issue has always started out as a bug until proven otherwise. Who's doing that triaging? Did the customer even ask for that feature? Are they using the feature in the way it was intended etc...?
----------------------------------------------------------------------------------
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 6, 2016 at 12:15 pm
Tom, if the corporate strategy failed but the rogue unit was right then you have a desirable result but for the wrong reasons. The end doesn't justify the means.
A corporate strategy is quite a large thing to get wrong. Not necessarily a complex thing but certainly should be a carefully considered thing owned by the senior management team. To say that a unit flew in the face of the corporate strategy implies a massive failure by the senior management team and that is without considering the fact that their strategy failed.
If I decided to overrule my superiors I'd expect to be fired for gross misconduct.
The number of bodge monkeys I feel is related to how well "trained" their leaders are. I'm not sure how much training people get in management and leadership skills but I suspect it's somewhere between a metric sod all and an imperial nowt. I've been lucky because I've been on every course one of my employers offered and they recognised that they had to prepare for the next generation of leaders.
Done properly agile methodologies promote a much broader and coordinated base of responsibilities. I emphasise "when done properly"
October 7, 2016 at 9:12 am
Gail Wanabee (10/6/2016)
Steve:"...it calls for developers to support the features that they write, even in production systems. I like this idea, though I don't think that it should be a continuous expectation with developers required to support their code forever."
There's no mention of forever, and I agree. Not forever, but for some time.
Having been a software developer/engineer for most of my I.T. career, and a DBA as my second I.T. career, I disagree with the latter part of the quotation.
Software is often very complex. Is it a rational expectation that someone who did not write questionable code should be asked to support it, should be held responsible for making modifications to it to correct a problem?
Yes and no. First, anyone that's a competent developer needs to be able to pick up the code and figure out what's happening. It may take them more time, they might be inefficient in the process, but they should be able to decode things.
Second, it is rational in that we have jobs for support. Those people need to support code, just like we have people supporting systems in the analog world that they didn't design or create. That's the way of the world. Should they be able to fix it? Yes.
Should they? It depends on the situation.
October 8, 2016 at 2:18 pm
David.Poole (10/6/2016)
Tom, if the corporate strategy failed but the rogue unit was right then you have a desirable result but for the wrong reasons. The end doesn't justify the means.A corporate strategy is quite a large thing to get wrong. Not necessarily a complex thing but certainly should be a carefully considered thing owned by the senior management team. To say that a unit flew in the face of the corporate strategy implies a massive failure by the senior management team and that is without considering the fact that their strategy failed.
Well perhaps I phrased my comment somewhat provocatively. Another way of looking it is that the corporate strategy (in a big company, not in a very small one) should include some slack for some groups who can spend some of their budget on looking at alternatives, sidelines, variant strategies. If it doesn't, that's a clear indication that the people at the top think they know it all and that is a recipe for disaster.
If I decided to overrule my superiors I'd expect to be fired for gross misconduct.
I've held positions where it was part of my job, when I thought it appropriate, to force my superiors to stand back and undertake a thorough review instead of pushing ahead. My superiors would probably have been fired for gross misconduct if they took action against me for doing that.
The number of bodge monkeys I feel is related to how well "trained" their leaders are. I'm not sure how much training people get in management and leadership skills but I suspect it's somewhere between a metric sod all and an imperial nowt. I've been lucky because I've been on every course one of my employers offered and they recognised that they had to prepare for the next generation of leaders.
Actually management and leadership skills training is not particularly rare. In the company I spent more than half of my career in people got training before they had to do any serious management.
The number of people working in technical development or support who are capable of more than a tiny bit more than bodging is very small, much smaller that the number of architects, developers, dbas, and sysadmins who are needed in the computing and IT. Recruiting is a nightmare, and the realistic options are to run seriously understaffed or to try to train the bodge monkeys to become capable of something more. Unfortunately most of them don't recognise that they are bodge monkeys (what some of them fail to recognise is even worse: that they aren't even capable of bodging).
Done properly agile methodologies promote a much broader and coordinated base of responsibilities. I emphasise "when done properly"
That's something we probably agree on - but emphatically not if you think "agile" means what a lot of the hype implies it means, or that the things called "agile" were not regarded as good practice decades before the term "agile" was coined.
Tom
Viewing 15 posts - 31 through 45 (of 46 total)
You must be logged in to reply to this topic. Login to reply