so as mentioned in the previous post i don’t have answers, but all i did then was bitch and whine. surely i can do better than that so i’m returning to the subject after talking a bit about it w/matt, which lead me to think more on the subject. i still don’t have answers, but now i will at least offer succinct thoughts.
reasons for action
- the code it’s core/central to your biz and agility is necessary – if it’s not then why are you thinking about it
- scaling is important – partitioning/sharding or just general efficiency – simple and clean scales
- things are fragile and unstable, a lot of development time is lost to debugging, changing something small in one place breaks things elsewhere
- to avoid the broken window principle – read the pragmatic programmer already
- looking at the code is painful, working with it hurts, you don’t want to get out of bed (weekday) mornings
reasons for complacency
- you don’t know what needs to be done to improve it – what “better” would look like
- can’t afford the initial cost (loss in forward progress) – you’ll lose 10 times it in the long run tho so be ware.
- new bugs or reappearance of previously solved problems – less likely if people have been around the code for a while and were involved with building it the first time around
ways to go about it
- start from scratch – build a new system using what you can, but starting with as little as possible of the existing.
- advantages
- biggest improvements, revolutionary
- less overall effort required to get there
- easier, requires less experience, skill, knowledge, and care. you just have to know where you’re going, not an incremental path there
- disadvantages
- initial hit, you don’t see immediate results of the effort
- refactor – pick a piece and clean it up, rinse and repeat
- advantages
- incremental improvements, you can stop at any time, evolutionary
- no initial hit, you see immediate results, but their small
- disadvantages
- way more overall effort required to get there
- 10x the skill and planning required to get there in one piece
- constant potential for regressions rather than all at once of redo
- boundless patience and endurance, yikes
- stick with it – keep on the current course, add to what you already have but don’t change it
- advantages
- none really, unless the piece of code is going to be short lived, remain untouched and effort would be wasted
- disadvantages
- life sucks
side note: unit tests, the more thorough the better, are your best friend when it comes to refactoring. at amazon we were able to redo substantial portions of a system, partition it out to multiple databases with disparate schema, to avoiding having to take downtime for lengthy migrations upfront, without any production bugs post change. this was b/c we had an environment where unit testing was easy to build and we built lots of it. do it, the time required with pay off 3 fold. in fact i’m going to return to this subject now that i think about it.
after reading the above it becomes obvious, to me even, that i lean towards action, there are few situations where you won’t benefit from revisiting, refactoring, and improving an existing system. btw, if you happen to have one of them then you probably don’t want to hire me 