More on Project Risk
I share Joel’s sentiments, I really do. I’m not suggesting that enterprises jump whole hog into using a “non-mainstream” language, but they should at least give promising tools a try, starting with pilot projects to suss out any problems with scaling or performance. To continue to play it safe all the time is to miss out on potentially valuable opportunities. No guts, no glory—even in business, this aphorism applies...
Of course, I’m not saying that enterprises should suddenly abandon their Java/C++ teams. All I’m saying is that they should examine new opportunities to improve software quality, efficiency and economics of development. Start with pilot projects and if that produces impressive results, try larger projects. It has to be transitional.
But concerns about social dynamics and internal resistance imply that everyone should stick with Java/C++ for geologic ages. Not allowing for the possibility of improvements makes for dinosaurs and we all know what happened to them.
You can’t allow your staff’s beliefs about Java/C++ to stop you from moving toward better alternatives, not when the potential economic/business gains may be colossal. Change for change’s sake is not good but neither is stagnation.
Train your staff in Smalltalk. Do it in phases or do it in segments of your staff. There are ways to manage resistance.
But don’t let ignorance about the virtues of dynamically typed, purely object-oriented, meta-programming language tools stop you from discovering revolutionary improvements in the software development process. We are on a potential cusp of history...
On 11/19/06 12:02 AM, "nonpartisanartisan" wrote:
Selecting a simpler language is fine ... if you can find sufficient staff trained in that language. If I needed a team of 40 engineers trained in Smalltalk who could communicate and bond with each other I would have a very hard time recruiting these people to begin with. I would be up Sh!t Cr33k without a paddle.
Moving to a new language has a social dynamic of internal people resisting change and hating external people brought it to replace them.
Experienced C++/Java programmers are suddenly "new" inexperienced Smalltalk programmers. High stress. Or else replaced by external people - huge morale problems internally.
Having a limited supply of people, abandoning your own staff and their beliefs in what languages are good, making them feel inadequate helps morale and moves the project along?
Of course, I’m not saying that enterprises should suddenly abandon their Java/C++ teams. All I’m saying is that they should examine new opportunities to improve software quality, efficiency and economics of development. Start with pilot projects and if that produces impressive results, try larger projects. It has to be transitional.
But concerns about social dynamics and internal resistance imply that everyone should stick with Java/C++ for geologic ages. Not allowing for the possibility of improvements makes for dinosaurs and we all know what happened to them.
You can’t allow your staff’s beliefs about Java/C++ to stop you from moving toward better alternatives, not when the potential economic/business gains may be colossal. Change for change’s sake is not good but neither is stagnation.
Train your staff in Smalltalk. Do it in phases or do it in segments of your staff. There are ways to manage resistance.
But don’t let ignorance about the virtues of dynamically typed, purely object-oriented, meta-programming language tools stop you from discovering revolutionary improvements in the software development process. We are on a potential cusp of history...
On 11/19/06 12:02 AM, "nonpartisanartisan" wrote:
Selecting a simpler language is fine ... if you can find sufficient staff trained in that language. If I needed a team of 40 engineers trained in Smalltalk who could communicate and bond with each other I would have a very hard time recruiting these people to begin with. I would be up Sh!t Cr33k without a paddle.
Moving to a new language has a social dynamic of internal people resisting change and hating external people brought it to replace them.
Experienced C++/Java programmers are suddenly "new" inexperienced Smalltalk programmers. High stress. Or else replaced by external people - huge morale problems internally.
Having a limited supply of people, abandoning your own staff and their beliefs in what languages are good, making them feel inadequate helps morale and moves the project along?
posted by Darkest Knight | 7:38 AM
0 Comments:
Post a Comment
<< Home