Take Away
The primary danger in the major rewrite is proceeding before the business has bought into it; this is usually fatal (or you end up wishing it was fatal). Along with the important technical skills needed, this talk identifies how to know when the business is behind it, and how to help to navigate the business to support the rewrite. (Or, to determine that it's not a good idea to do the rewrite at this time.)
The Big Rewrite, Doing it Right
Rich Kilmer
btw, he used a presentment software package called Prezi which was very effective with swirling text while zooming.Drivers for a Rewrite
- Must be business driven
- Must NOT be technology driven
- Don't call it a rewrite
- Complete in a major release cycle
Preparing for a rewrite
Drop a major release before you start.- One the customer is really happy with.
- Understand your domain
- Or have a domain expert available all the time.
- Break down the current system into logical sets of functionality. (Rich later showed the resulting code which was incredibly clean; this made a (hopefully) lasting impression on me.)
- Choose the right technology for what you want to do. Examples:
- Develop a standard worker framework (minion, resque)
- Dedicate resources to repeatable data migration
- Keep services code consistent, models clean
- Use the right tool for each job
Flip It
- Perform incremental migrations of historic data
- Prepare business users for potential disruptions
- Run flip scenarios several times
- Enable "read only" system during final lip (if needed)
- Provide a way to fall back if the flip fails
Miscellaneous
- Don't code for assumptions.
- If you find that you want to use the same name for two different classes, you may have two different domains which might need different applications.
- Design for expectation that backing up separate systems will probably not backup synchronously. So be prepared to recover disparities.
No comments:
Post a Comment