Managing multiple version of any product is tough and intricate and if the product is poorly written, you have a mess in your hand. Refactor or rewrite is a debate we participate in all the time. Let’s not go into that again right now. Let’s pretend that we have decided to rewrite our product….hoooray. But rewriting the whole product in a one bang is not only ill-advised but a project doomed to be failure.
So what should we do then? Take small steps. If you have a big, unmanageable product in your hand, figure out the core/important services/components that need to be rewritten (maybe in different technology). Integrate those components with your existing product as soon as possible and release it. If you have many existing clients, releasing quite often could be an issue. Maybe hosting your new solution as a service (SaaS) with data centers might solve that problem. This could also be very lucrative to customers because they don’t have worry about any infrastructure/administration issues any more. This might cost you more money but you know what! you will always have a working software.
Sometimes you cannot avoid having multiple version of same product, especially when you are transitioning from old messing mud ball architecture to something more manageable. But rewriting in one big bang is an illusion which results in a 200 member team project with no end date (I am serious).
Stuff about software development, agile and testing
Friday, July 13, 2007
Software rewrite and big bang theory
Labels
- agile (4)
- agile testing (1)
- build tool (1)
- design (1)
- DSL (1)
- duck typing (1)
- eclipse (1)
- ejb3 (1)
- Fluent Interface (1)
- grails groovy (1)
- groovy (1)
- gwt (1)
- hacking (1)
- haskell (1)
- java (1)
- javascript (1)
- jvm (1)
- languages (1)
- mac (1)
- pipes (1)
- programming (1)
- qa (1)
- rant (2)
- ruby (6)
- sas (1)
- scala (3)
- scripting (2)
- software rewrite (1)
- statically typed (1)
- testing (4)
- two phase commit (1)