Getting your programming/developer team up to speed

Question

I recently left a large university hospital for a much smaller one because of the pay increase and because it was a career booster. Of course these two things would generally be something to be excited about and a great accomplishment (esp.for someone my age) but I have found myself pouting on the inside as I drive to work every morning, and here is why. The new t=eam I joined is dreadfully behind in the times with coding practices, latest technology (yes they still use classic .ASP), and software - leaving me in a backwards time warp from using VS2008, .NET 3.5, and SQL Server/BIDS 2008 to using ancient SQL 2000/ VS 6.0 relics.

At first, not so bad, I figured not all companies are on the cutting edge right away and are just waiting for that right spark to send them in the direction of change and improvement - nope - I started suggesting (in a professional and non-condescending manner) some new tools and what benefits they'd have for our company on both our side and client side but they (as in the team I am a part of) looked at me like I was an alien and gave me the simple, why would we need that stuff, even after I had made my case.

This has led me to believe that I may not be going about this in the right manner and was hoping some more senior developers/engineers would share their experiences when they were younger and just starting out. I know times have changed but I feel it'd be useful nonetheless and any advice would be much appreciated!

Thanks everyone!

Answer 1

This happens all the time.

You should have asked what tools they use and how they work before agreeing to join them. I would also point out something like "If I discover you made it up only to get me to sign up, I will not be staying long.".

Answer 2

Is it just the tools that are out dated? Or is the code they are producing subpar? If it is the code your best bet is group code reviews. If it's just tools, simply produce articles and/or documents that list features they are missing and how those could benefit the group.

Answer 3

If the team is stuck in the past there might not be much you can do about it. Some developers either don't see the benefits of newer technology/methods (and in some cases they might be right) or are scared of change. I'd say learn what you can from them - there are lots of interpersonal, project management, political and other skills you can learn. Spend some of your own time keeping up with the current technology and keep your eyes open for a chance to move on to something else. For now, learn what can. Lots of developers focus on the technology and miss out on the important skills that they will really need later on in their careers.

Answer 4

It's pointless adopting new technologies unless they resolve actual problems in a easier and more efficient manner then previous technologies. (Including the learning curve.).

It may be that your university has a huge amount of legacy code, which relies on those old technologies. Moving to later ones can be an extremelly costly and tiresome process which is quite hard to justify.

The way to introduce new technologies would be either at a step change in architecture, like the university as a whole decides to move to SharePoint or whatever, or in a new project, where you can demonstrate the advantages of the new technologies, and let the existing developers have time to get some understanding of them.

Something to bear in mind with all of this, is that most people do not like change, and by changing the existing technology you are going to step on people's toes. For example, the experts in particular systems or technologies.

Answer 5

You're out of luck, frankly. If they don't see any need to learn, they're never going to do it on their own. You're going to have to work to get the newer stuff mandated in the office, and probably find a way to pay for some training for 'em. Or convince their bosses to fire them.

In a lot of non-tech environments, people settle into their rut, and continue using the same tools, even as they go out of date. Seen it a hundred times.

Answer 6

You're gonna find people resist to change strongly and you should know the reasons why people use to reject change in order to try to change it.

Firstly people in general is risk avoider (with some "early adopter" exceptions). That is, people avoid risk and any change is a risk.

Secondly, in your situation, people tend to be afraid of WHERE the change will put them. Look at it like this: a developer on your team will be thinking "if we change to xxx technology, how will that affect my career? How will it affect my chances to get a promotion or even get fired? They don't know the new technology, they don't want to get outdated or lose their position as experts or whatever in the "old ways".

Finally everything new is hard to learn and understand, specially when you've been working in the old thing for a long time. It takes time and makes you feel as if you were an idiot. In oldest teams (and I mean literally in terms of people being older) it also increases the fear for being replaced for someone younger who already know the technology.

If you intend to overcome the resistance you'll need to address all the things.

Firstly the thing will have to be gradual. One step at a time, one product at a time. Don't try to change the full process for the entire company. Instead propose taking a lesser project and apply the new tech to it. Present is as an opportunity and a test. If it isn't useful then we won't use it anymore, but let's just try, then the risk will be minimal.

Then reassure the people. Make sure everyone feels appreciate and that you or the company trust more on the long years of experience in the field that on any given technology used. Listen to the people, respect their opinions and make them feel you care what they think. Of course this shouldn't be an act, you should really feel that way. Great teams trust each other.

On the other hand, handle the change. Milestones need to be wider, you have to account for the change. You have to make the team feel you understand change is difficult and that is a long time process. That no one will be judged if the new thing takes more time than the older one and that failures are to be expected and no one will be fired because of it.

In the end, if you want change you have to reassure people and make them understand the change is just a test, if it works then great for everyone, if it doesn't then it OK. Of course the company needs to understand this as well. For managers this means presenting them with a clear risk vs benefit report, stating truth and telling them WHY the change must be done.

When speaking to management remember also to remember them that competition is always out there. You have to evolve or more correctly be always evolving. Even if the product is the same in terms of functionality and saddest as it may seem, from a marketing point of view, saying you use the latest xxx technology with the lates yyy development technique is a great hook. Clients are not stupid but they aren't computer literates either so they are easily impress with fuzz words so competition can steal them without really having a better product, just a "newer" one.

Just one more thing: Maybe you'll find useful to tell them about the "Who moved my cheese? history" which revolves about the change and how the market evolves around change.

Change is a fundamental thing in everyone life, both personal and professional and should be always took into account. Whenever someone says "change now is too risky" or "we can't afford change" you have to really think it trough... is the picture being seen in the long term or all we talking about a short term scenario? Because if it is the latter, then we'll be fine for know but screwed in the long term ... something like always giving a loan to everyone to buy a house because houses ALWAYS increase their value... or do they?...

Answer 7

There are a lot of unknown variables here, so many that it's kind of hard to give advice. I'd like to know:

1. Are you managing this team, or just a coder in it?
2. Did your hiring manager bring you on with a specific mission to upgrade the team to newer technologies?
3. What's the attitude of upper management as far as upgrading the technologies used?

If you're in charge of this team, then it's up to you to set the agenda, get everyone excited over the new direction, and, possibly, fire someone to show the others you mean business (preferably the one who groans the loudest or drags his feet most obviously).

If you're just a code monkey, or if upper management is just fine with the way things are working now, then start sending your resume out, because you're not in a position to change anything. And next time you take a job, ask for specifics about what technologies they're using.

Answer 8

First, understand that suggesting major changes when you are new is almost always a bad idea. First you get them to respect you through performance, then you suggest changes. Then you may also understand the cost to the business of making those changes which is why they haven't made them.

IF they told you they were using these tools before you went there, you should accept that this the environment you choose to live in and work there for awhile beofre bringing the subject up again. If they told you that they wanted you because you have the skills they lack to move forward, then the person you need to talk to is the hiring manager not the team. Note that this will not create friends for you on the team.

My main suggestion to you is that you start to do some reading on office politics. Build some alliances before you try this again. Possibly there are other people who also want to work with newer stuff. Maybe the dba doesn't like being stuck with ten-year-old skills either.

As far as changing from SQL Server 2000 to 2008, you can point out that 2000 is no longer going to be supported and that when SQL Server 2010 comes out there is no longer a direct upgrade path. This is what finally got us to start upgrading to 2008. Better to convert before that happens. Research the Microsoft web site for the exact details of what happens when.

Answer 9

All of us have our platform and technology biases and when a new person joins a team and wants to change everything to their way of doing things it is disruptive and the team will often try to reject the change, even if the motivations are good.

Unfortunately the "You are using Java?? Ick! We need to port all this to C# immediately!" types have made people rightfully skeptical of the new guy suggesting a lot of new things.

One suggestion I might offer when suggesting a new process or technology is to frame it in terms of an actual problem they are having and can relate to. The technology is not the solution it is the answer. Find the problem and then perhaps offer to teach a brown-bag on the technology emphasizing the aspects that will resonate with the team in light of their pain-points. Demonstrate the value and let them come around on their own rather than taking the sales-pitch approach.

Answer 10

How did you make your case? Professional and non-condescending is good, but it's just the start.

When you're trying to persuade somebody to change, emphasize what's in it for them. Figure out what they want and show them how the new tech can help.

Management wants more work done and dollars saved. Managers won't care about wanting newer and better stuff. Try to find cases and studies showing that going to the latest stuff saved X% in money and work. Find or create good estimates of what it's going to cost (not only in tools, but in training, dual development tracks, and the like). Remember that the old stuff will stay around, and you have to have a plan to account for that.

Your co-workers need to be told how this is good for them, and that they won't suffer for it. They've got a lot invested in this. They know what they're doing, and they know the code base. Move to a newer system, and they won't know what they're doing, won't know the code base, will be incompetent at first, and may be afraid that they'll become expendable. This is a lot to ask of the average person, and may be too much to ask of some people (like the guy who's three years from retirement).

Find out what they don't like about the current system, and show them how the new software can help. Discuss training and be at least upfront about how easy it will be to convert. If you can show them how to do what they usually do in the new system, without worrying about taking advantage of new features, that will help a lot. Emphasize that their knowledge is not just of the code base, but of the business and its requirements.

And don't expect to dump the legacy stuff. You'll only be able to introduce new tools when starting a project, and if it's incompatible with the legacy systems it simply won't work.

This is difficult, of course, and you might be better off staying a few years and moving to a more modern shop.

Answer 11

As was mentioned before forget the legacy projects if they are running OK you aren't going to be able to persuade anyone to rewrite them. A better way might be to wait until a new project comes in and at that point suggest using new tools. Argue how these newer tools will improve efficiency or whatever but don't argue you should only use them because they are new. It might be easier to do this with a small project that management will see as less important.

Once you have one project up and running you have won half of the battle and can use it as an example of the advantages of new technology to the management.

Good luck anyway.

Answer 12

When the new guy comes in and starts preaching -- even in a totally legitimate, positive, and helpful manner -- about new tools, it can often set up a "you versus them" atmosphere.

It shouldn't be that way, but by admitting that these amazing new tools will save them lots of work, it's kind of an implicit admission that they've been wasting lots of time. Even if they're okay with that on a personal level (external constraints aside, most people just want to do good work!) they'll be wary about how it might look to their superiors if "the new guy" knows much more than them.

Idea: get them to go to some local developers events with you. Then it's more like you're discovering exciting new stuff together and less like a "my tools are better than yours" thing.

Above all else, you need to put in some elbow grease and nail some projects so that you build up cred at your new workplace.

Also, I've always thought that SQL Server 2000 is fantastic. SQL 2K5 and 2K8 are nice upgrades, but 2000 is really solid stuff; it's not like they're running on Access.