August 2, 2010 at 8:10 pm
Comments posted to this topic are about the item Keeping Fresh
August 3, 2010 at 1:09 am
Great points! I too have seen (and felt) this developer fatigue and it is a real problem. But you have to be careful moving people around as this can have the reverse effect if people feel like they are interchangeable 'cogs' in the machine. This happens in Scrum environments if you are not careful.
There is a tendency for management to want to spread knowledge and therefore risk, but in my opinion it is a sense of ownership and control of some product, feature or area which brings about pride and all the other good stuff. So occasional new challenges are definitely needed, but proper ownership too.
August 3, 2010 at 1:35 am
You make some good points, but there is a reverse side to this. If the developers who write the software know in advance that they'll have to maintain it, you tend to get better quality.
I've seen the reverse happen. In my pre-database days, I was a 3GL mainframe developer. One of the shops I worked for had the development division divided in two departments: one for building new software, and one for maintenance. The maintenance department did have to formally accept software before it was transfered, but there was often time (and management) pressure, so only the very worst issues were fixed and the rest was thrown into the hands of maintenance. The quality often was really terrible; I have often wished that the "new software" developers would be forced to do maintenance for a year to teach them the errors of their ways.
August 3, 2010 at 1:50 am
I agree with what you've said, but think you've missed one vital point. All the suggestions you've made are good tactics to have at your disposal, but knowing which are appropriate for any given developer is impossible unless you talk to them. Certainly there will be some who want to move onto newer stuff, but equally there will be others who like the security of known quantities.
Semper in excretia, suus solum profundum variat
August 3, 2010 at 2:37 am
Hello!
I work for a product (and have been working with the same product since the last 6 years). What we typically do is exactly what you have mentioned - rotate!
As with any product, we would always have two tracks - brand new development or "point-release development" (includes piecemeal migration into newer technologies - not a "big-bang" approach) and sustenance (which includes bug fixes and minor enhancements, like service packs).
Some key developers are kept on the brand new development projects for a longer period (a couple of years/releases) while others are rotated across Sustenance and point-release teams. That way, if you contributed to a new enhancement, you will definitely get to see your design & implementation's salient features and drawbacks when you are in Sustenance. Next time when you work on something new, you are consciously going to make sure that you take the good points, but leave out the bad ones.
Such an approach is helpful both ways - for the developer and for a product as it matures over time in a consistent fashion.
The only thing to keep in mind is that those in Sustenance should not become "stale". It is of utmost importance to share new training, community meets, think-tank sessions, etc across everyone in the team - be it sustenance guys or the developers.
Have a good day (or a good night - depending on your time zone)!
Thanks & Regards,
Nakul Vachhrajani.
http://nakulvachhrajani.com
Follow me on
Twitter: @sqltwins
August 3, 2010 at 7:39 am
majorbloodnock (8/3/2010)
I agree with what you've said, but think you've missed one vital point. All the suggestions you've made are good tactics to have at your disposal, but knowing which are appropriate for any given developer is impossible unless you talk to them. Certainly there will be some who want to move onto newer stuff, but equally there will be others who like the security of known quantities.
Excellent point, I should have added something about communicating with developers, not just shuffling them around.
August 3, 2010 at 8:00 am
I worked for a place where after 7 years it became clear I was mainly going to be maintaining the numerous applications I wrote(VB6, Access, ASP, T-SQL) instead of getting into new things. So for about a year or 2 I didn't increase my skills in anything new at work, just on my own thru books/certifications. So, that's when I knew it was time to move on and all of a sudden I'm working in all the new technologies and in various products in a non-profit business that makes efforts to be on top of things, so its really a nice change and I couldn't ask for anything more.
As my mom would say, "You can always quit." Glad I did, but it was a good run.
They found my replacement over 2 years later after a couple failed attempts.
August 3, 2010 at 10:17 am
The nice thing about being dedicated to a piece of software or an application is that you become the knowledge expert and eventually work out most of the bugs. The bad thing is that you also become the bottleneck if you become overburdened and an issue with your application holds up other's work. No one else knows the system so they have to wait for you. You also tend to get bored and frustrated at your lack of options and growth. I have seen a number of times where no one knows how a system works and no one really cares to ask because the expert is there. That works out fine until the expert leaves, at which point there is a mad scramble to figure out what that person was doing. Often they end up scrapping and rebuilding the entire app because it is easier than trying to figure out the "expert"s code.
Rotating developers amongst projects is very important and usually does not happen at a company until after a couple of key personnel have left. Even though knowledge transfer can be painful, it is always less painful than trying to figure out someone else's code when that developer is already out the door.
August 3, 2010 at 10:29 am
Note that you being the only resource for a system, or one of a few, doesn't mean you can't do anything else. Even if someone wants you to be dedicated, I think I'd limit that to some period of time (say 6 months or less) and after that at least give you a half day (4 hours) a week to do something else. If nothing else, it helps keep your mind fresh or moving in new directions.
August 3, 2010 at 2:05 pm
It's your personal responsibility to yourself to keep your own skills current.
Occasionally, for brief, shining moments, you may have a boss or employer that cares about that. Few will ever be luckier than that.
If you want your employer to participate in keeping your work interesting and your skills top notch, you need to find a way that's:
1) easy for them to do .
2) cheaper than the true cost of not doing it.
3) make the true cost of not doing it fully visible.
Your talking points should be based on time-to-market, quality, revenue, cost, risk management, market or operational benefits, etc.
Because when it comes to where organizational money gets put into the budget, the bean counters don't care how you feel, and neither will 99.9% of the senior management of the company - unless your feelings and skills are demonstrably tied to the bottom line.
August 3, 2010 at 9:01 pm
Lots of folks insist that managers talking to developers is one way to have a great product and interested developers. There are two major parts missing from that equation... first, the developers have to want to talk (think incentive and interest) and the managers actually have to listen and be empowered to actually follow through.;-)
--Jeff Moden
Change is inevitable... Change for the better is not.
August 3, 2010 at 9:07 pm
I saw an advertisement for a particular recruiting shop. One of the things they say that they and their clients owe their success to is correct appreciation, utilization, maintenance, and treatment of a frequently mislabled, underutilized, and poorly treated resource... they called that resource "Human Capital".
Developers and DBA's are part of the team, too, ya know? 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
August 3, 2010 at 10:34 pm
I guess the concept of team members being "resources" or machine equivalents is where the problem lies. Machines can designed to repeat an activity again and again; while the very existance of humans is on change - adaptation - evolution. While today's industrial scenario is based on efficiency and precision, the H-factor is not something that should be ignored by project managers and team leaders.
Another problem that I see is the fact that quite often young leaders create a dependency and do not pass the baggage on to fellow team members. What this leads to is a divide - not a divide of the high & low - but a divide in the relative growth rates. The leaders grow, but their team does not. On the other hand, pure deligation is also not the solution (after all, if a team member asks the leader a question; the leader must be able to answer it. Also, the if an estimate is provided by the team member, the leader must be able to judge if that is correct or not - without having to go back to the drawing boards). Leaders must have grooming skills - that way as they grow, junior team mates fill into the "holes" left behind. Leaders grow and their team grows with them.
Thanks & Regards,
Nakul Vachhrajani.
http://nakulvachhrajani.com
Follow me on
Twitter: @sqltwins
August 6, 2010 at 4:41 pm
I think project rotation or task rotation maybe even responsibility rotation is a good way to keep fresh in the business. It helps to be able to do something different from time to time.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
August 6, 2010 at 6:36 pm
CirquedeSQLeil (8/6/2010)
I think project rotation or task rotation maybe even responsibility rotation is a good way to keep fresh in the business. It helps to be able to do something different from time to time.
Rotate responsibility... I like that. This could also help to teach people about being PM, team lead, etc. Nice idea.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply