Category: legacy code

Code is Forever

If you still need another source of motivation for taking care to write clean code, now there’s the Software Heritage Foundation. It’s a non-profit organization dedicated to preserving for the long haul all the world’s source code (or at least all the code found in public repositories like Github). It’s early days for them, but they have already archived and normalized a huge amount of code, which they make available for browsing and data mining. They’re looking for donations, as well as volunteers to help with documentation and coding adapters to repositories they haven’t yet tackled.

So now we can imagine that 100,000 years from now, there will be some archaeologists who, after browsing through the photos of you posted by your “friends” on Facebook (“Ah, look. Another one puking at a party. Why did they do that ?”), they will then run FindBugs or some more advanced analysis on your code (“How about that ? The puker’s lifetime code has 355,000 copy and pastes, a cyclomatic complexity per method of 18.7 and 23,000 abstraction leaks.”). And if you think the code you’re working on is secret, well in 50 years it will probably be in a public repository.

So take good care of your code – it will be around for a long time, and you never know who will be reading it.


API is Legacy

Now that I’ve released version 1.1 of interface-it, I understand better why so many projects decide to do a big 2.0 release which includes breaking changes to API’s.

Once you’ve decided to support backwards compatibility for all the exposed API (all public and protected methods in the public classes, normally), minor releases hit a lot of technical debt because you can’t refactor everything you want to. TDD doesn’t save you from this .

With interface-it, I made a few assumptions about the API which changed very quickly when I discovered new requirements. For example, before the 1.0 release, I thought about encapsulating some of the arguments to key methods, but I didn’t see clear affiliations or behavior related to these arguments. It was just data needed for generating a mixin. For version 1.1, where you can generate a hierearchy of mixin types (just parent-child via the command-line interface, but the code API is more flexible), it was no longer data but behavior that I needed, because I had to manage multiple classes in the same call. Despite having excellent code coverage thanks to TDD, the change was a bit painful to implement, and I had to leave in place some methods which I would have preferred to delete.