|
Start from scratch or build from within?
When changing legacy code to OOP, is it better to bring in a new team of developers, or build from the industry knowledge that you've already got?
The existing programmers have no OOP backgrounds - they've all used a proprietary, procedural language.
New programmers would have to be trained on our product.
A new manager
Wednesday, March 17, 2004
Fire them all! Then hire some lower grad students.
_
Wednesday, March 17, 2004
Why not bring in a few new programmers with OO experience and pair them up, new and old. You'll educate the older programmers on OO by directly interacting with it, and get knowledge transfer to the new programmers at the same time.
It might not work, but if your team is good and open to the process it just might be a good thing.
Lou
Wednesday, March 17, 2004
lemme guess:
Are you the brand new spanking project manager just out of a CS degree that walked into a banking job, saw the Massive Iron running thousands of KLoc's of Cobol and went: Give me six months and a few good men and we can rewrite that dungheap in six months in Smalltalk?
No? My appologies. Just there seem to be so many of those around.
OOP is hardly rocket science. Granted, maybe some fresh faces would carry less (or other) bad habits. But how much tacit knowledge is there in the old team that has been gained through years of experience? Would you expect the old team to transfer this to their replacements?
Why do you say OOP? It is very strange to put it that way. OOP is a means, not a goal in itself. If there is a certain development environment which you believe would offer benefits over the current system, why not name it?
What are the benefits you are hoping to get from OOP?
Just me (Sir to you)
Wednesday, March 17, 2004
Why not bring in a few new programmers with OO experience and pair them up, new and old....
- Tried this, and the existing staff immediately went into job-security mode. Just not communicating their knowledge. While I believe that some of the existing programmers can make the "jump," I don't think others will.
lemme guess:....
- Nope - been writting software for 12 years, and managing for about 5. I say OOP because I didn't want to get into a war over the choice of language. Let's just say TUI/Green Screen vs. GUI. Also, while I agree that its not rocket science, I liken it to the transition from arithmetic to algebra, or from algebra to calculus.
A new manager
Wednesday, March 17, 2004
If you're trying to put a nice interface on a CICS or other terminal program, rather than rewriting that part of the app you could user a Web interface instead. The transition might not be as dificult.
Lou
Wednesday, March 17, 2004
lemme guess:.... Nope
That's why I covered my ass.
Are you resource constrained? Would it be possible to retrain all of the old gang and bring in some fresh blood?
The previouos development team might be a bit more forthcoming when you give them a fighting chance.
Just me (Sir to you)
Wednesday, March 17, 2004
Pick up Agile Software Develpment by Alistair Cockburn. It might give you a few ideas that you could apply to your situation.
If it was me I would probably bring in at least one or two technical experts and keep some of the old programmers as domain experts. I've never been a manager, but that has been a successful strategy on several of my projects.
NathanJ
Wednesday, March 17, 2004
I'd be hesitant to break up the old team. If you did break them up, then those that remain would be disgruntled and have low productivity. If you dropped them all then a) you have no domain knowledge transfer, and b) if your new team is smart they will see how easily you fired the old team (not a good way to start off your new team). I would try to keep the entire old team, and bring in some mid-level new people familliar with whatever methodology you wish to implement. I would be hesitant to bring in a whole slew of junior programmers as they old team may not respect them. That could create a rift between the two teams. Some juniors would be fine, but I'd make sure you have someone with a substantial resume that the existing programmers will like and respect. Just make sure that the existing team is aware that you aren't replacing anyone's job function, demoting anyone on the team, etc. You want them to think that you are merely augmenting the existing team.
Elephant
Wednesday, March 17, 2004
Get your team together. Tell them to brainsotrm about what they would do if they could start all over, not just fix things up. Let it be their idea and you'll get buy-in. Let it be your idea forced upon them from on high and you'll get nothing but resistence. Attempt to bring in new blood to change things too rapidly and you'll get blowback.
old_timer
Wednesday, March 17, 2004
Outsource it to Canada !
Kentasy
Wednesday, March 17, 2004
Better still, to India. They can do OOP using EJB coupled with SWING across DB2 or VB on .NET with RDBMS as the DB layer, combining the strengths of XP integrated with the stablity of AGILE incorporating XYZ tightly bound with ABC, not forgetting to add EFG into the process while ensuring a smooth migration from to FP, as well as any other. And guess what, all that at 1/4 the price in 1/2 the time.
Seriously, though, what you are asking is really silly. Get rid of the initial developers? No way. New blood may help, but only help. They cannot be the primary developers. Give them a month off to catch up and then ask them to lead a new team to change to a _better_ language/approach.
A legacy man who is no legend
Wednesday, March 17, 2004
> Tried this, and the existing staff immediately went into job-security mode. Just not communicating their knowledge. While I believe that some of the existing programmers can make the "jump," I don't think others will.
I don't know what to say about that.
As someone who learned OOP to rearchitect a C-based system, I'd suggest existing staff can (theoretically) make the jump, if jumping is a sensible requirement. One possibility might be to bring in a single OOD/OOP expert, with whom they can consult (who can review and help with their redesign).
Christopher Wells
Wednesday, March 17, 2004
Is existing team bought into the idea of moving to OOP/GUI/whatever? If they are and you have one or a few good people on the team you'll be just fine. These people will drive the technical changes.
If the team doesn't really believe that the changes are neccessary then there's little you can do with them. Bringing new blood is hard to do - existing people will percieve them as a threat.
Try getting the team excited about making the change themselves.
igor
Wednesday, March 17, 2004
Even if the team is enthusiastic I would bring in a technical expert to mentor. Otherwise you'll end up wth a pile of well-intentioned crap.
NathanJ
Wednesday, March 17, 2004
I am baffled.
Why the emphasis on technology rather than on the features? If you can make the software work with old techniques then do so. If you can't - and it's likely, from what you say - get your team on board. Focus on what the customer needs, not the fact that everything they've been doing for the last 15 years is crap.
These guys have outlived every software fad for a long time. If you're not careful, they will outlive OOP.
pdq
Wednesday, March 17, 2004
"
Tried this, and the existing staff immediately went into job-security mode. Just not communicating their knowledge. While I believe that some of the existing programmers can make the "jump," I don't think others will.
"
Then you need to work on your management skills.
jqb
Tuesday, March 23, 2004
 Recent Topics
Fog Creek Home
| 
