In many ways my last few days have been filled with thoughts about scope creep. As I said a little while ago, a lot of my projects are suffering from this. And partly it’s because I’m being a little bit too ambitious. So I’ve intentionally dialled back on what I’m doing to make sure I hit the core values.
Part of this has involved reviewing my coding, and I’ve reminded myself of the importance of building a central, maintainable framework.
“Maintainable” is the key word here because “code rots”:
Code is bad. It rots. It requires periodic maintenance. It has bugs that need to be found. New features mean old code has to be adapted. The more code you have, the more places there are for bugs to hide. The longer checkouts or compiles take. The longer it takes a new employee to make sense of your system. If you have to refactor there’s more stuff to move around.
You realise this when you come back to something you were working on several months ago, try to run it and it crashes.
- Partly it’s because of that bug that you never got round to fixing but knew about and knew the workaround for.
- Partly it’s because something else changed along the way and broke it.
- Partly it’s because you’re not caring for it and fixing bugs and improving it any more.
As soon as you stop actively looking after it, it starts getting worse.
Of course, you can’t look after every project at once, but what you can do is write a centralised code library, look after that, and pull much of your stuff from that. That way, you’re actively looking after most of the code at once.
Jeff calls this “tending to your software garden” and I think I agree with him. I think I need to come up with more ways to keep my garden well looked after.