Return to Answer

• If you do, however, do not try to convert existing code. Design the system from scratch. Otherwise you're wasting your time. I have never seen or heard of a "conversion" project that didn't end up miserably.
• Replace the old system team at a time. Identify the teams that have the MOST pain with the existing system, and migrate them first. Let them spread the good news by word of mouth. This way your new system will be sold from within.
• Design your framework as you need it. Don't start with some I-spent-6-months-building-this framework that has never seen real code.
• Keep your technology stack as small as possible. Don't over-design. You can add technologies as needed, but taking them out is difficult. Additionally, the more layers you have, the more work it is for developers to do things. Don't make it difficult from the get-go.
• Involve the users directly in the design process, but don't let them dictate how to do it. Earn their trust by showing them that you can give them what they want better if you follow good design principles.

• If you do, however, do not try to convert existing code. Design the system from scratch. Otherwise you're wasting your time. I have never seen or heard of a "conversion" project that didn't end up miserably.
• Migrate users to the new system one team at a time. Identify the teams that have the MOST pain with the existing system, and migrate them first. Let them spread the good news by word of mouth. This way your new system will be sold from within.
• Design your framework as you need it. Don't start with some I-spent-6-months-building-this framework that has never seen real code.
• Keep your technology stack as small as possible. Don't over-design. You can add technologies as needed, but taking them out is difficult. Additionally, the more layers you have, the more work it is for developers to do things. Don't make it difficult from the get-go.
• Involve the users directly in the design process, but don't let them dictate how to do it. Earn their trust by showing them that you can give them what they want better if you follow good design principles.

These things are pretty self-evident. When to decide on a complete rewrite versus an incremental rebuild is more subjective, and therefore more politically charged. What I can say with conviction is that to uncategorically state that it is never a good idea is wrong.

These things are pretty self-evident. When to decide on a complete rewrite versus an incremental rebuild is more subjective, and therefore more politically charged. What I can say with conviction is that to categorically state that it is never a good idea is wrong.

• Developer ramp-up time is very high. If it takes any longer than below (by experience level) to ramp up a new developer, then the system needs to be redesigned. By ramp-up time, I mean the amount of time before the new developer is ready to do their first commit (on a small feature)
  • Fresh out of college - 1.5 months
  • Still green, but have worked on other projects before - 1 month
  • Mid level - 2 weeks
  • Experienced - 1 week
  • Senior level - 1 day
• Deployment cannot be automated, because of the complexity of the existing architecture
• Even simple bug fixes take too long because of the complexity of existing code
• New features take too long, and cost too much because of the interdependence of the codebase (new features cannot be isolated, and therefore affect existing features)
• The formal testing cycle takes too long because of the interdependence of the existing codebase.
• Too many use cases are executed on too few screens. This causes training issues for the users and developers.

• Developer ramp-up time is very high. If it takes any longer than below (by experience level) to ramp up a new developer, then the system needs to be redesigned. By ramp-up time, I mean the amount of time before the new developer is ready to do their first commit (on a small feature)
  • Fresh out of college - 1.5 months
  • Still green, but have worked on other projects before - 1 month
  • Mid level - 2 weeks
  • Experienced - 1 week
  • Senior level - 1 day
• Deployment cannot be automated, because of the complexity of the existing architecture
• Even simple bug fixes take too long because of the complexity of existing code
• New features take too long, and cost too much because of the interdependence of the codebase (new features cannot be isolated, and therefore affect existing features)
• The formal testing cycle takes too long because of the interdependence of the existing codebase.
• Too many use cases are executed on too few screens. This causes training issues for the users and developers.
• The technology that the current system is in demands it
  • Quality developers with experience in the technology are too hard to find
  • It is deprecated (It can't be upgraded to support newer platforms/features)
  • There is simply a much more expressive higher-level technology available
  • The cost of maintaining the infrastructure of the older technology is too high