Bitrot

| September 15, 2013 | Programming, Rant | No Comments

So from hardware failure back to software failure.

Bitrot is defined in The Jargon File as

bit·rot
Pronunciation: /bɪt rɒt/
Noun [common]
Also bit decay. Hypothetical disease the existence of which has been deduced from the observation that unused programs or features will often stop working after sufficient time has passed, even if ‘nothing has changed’. The theory explains that bits decay as if they were radioactive. As time passes, the contents of a file or the code in a program will become increasingly garbled.

A bad case of bitrot
A bad case of bitrot
I would measure bitrot by the amount of effort required to get a formerly perfectly functioning piece of software that used to work three years ago to do the same thing in, say, Windows 8, or your new cloudy environment thats going to save you money by making you rebuild everything again, whilst locking your data into a third-party vendor’s environment that will be extraordinarily difficult to extricate yourself from at a later point in time when they decide to charge per individual CPU opcode.


Assuming you’ve got maven running (and therefore bamboo, nexus or something similar), I think it would be interesting to make charts of the following things over time:

  1. number of inconsistent artifacts within an environment (i.e. same artifact at different version levels)
  2. same classes/resources in multiple JARs/in different locations in classpath (and/or different precedent levels)
  3. artifacts that don’t match their md5/sha1 hashes in your repository (probably local builds, patched builds, or multiple branches/directories building to the same version number)
  4. number of dead branches in your source control system
  5. number of active branches in your source control system (i.e. old branches still in production or the number of active maven builds)
  6. number of undocumented classes / packages
  7. number of untested classes / packages
  8. number of active APIs
  9. some measurement of maven dependency complexity (e.g. number of dependent packages per artifact or the total number of JARs within a WAR/EAR )
  10. time since last update of each maven artifact (may indicate no owner/maintainer of code)
  11. code size / file size
  12. changes to release branches that have not been integrated into HEAD in source control
  13. changes to old branches that have not been integrated into HEAD
  14. changes to HEAD that have not been integrated into branches being actively developed
  15. maven groupIds/artifact names that bear no relation to their java package structure
  16. maven groupIds/artifact names that bear no relation to their position relative to HEAD in source control
  17. xml namespace inconsistencies
  18. any use of AOP
  19. the number of levels of configuration before you hit something that isn’t a dereferenced property
  20. projects that aren’t in bamboo
  21. projects that aren’t in nexus
  22. inconsistent version numbers across a branch
  23. groupIds/artifactIds that are not consistent between maven1/maven2 files in the same folder
  24. inconsistent bamboo build config (e.g. java versions)
  25. maven build plan descriptions that bear no relation to their locations in source control
  26. inconsistent bamboo config for plans within a project (java versions, clover-enabled…)
  27. project dependency artifact versions that override parent dependency versions (mvn2) or vice versa (mvn3)
  28. SNAPSHOT project dependency artifact versions that are in a parent pom xml
  29. inconsistent parent pom version numbers between projects

I wrote most of this list a few years ago when I was working in a much, much larger company but I still think it’s relevant today, so if anyone wants to go and write up some anthropological software that generates some metrics out of, say, everything that’s currently sitting on central, then I would find that sort of thing fascinating.

So someone go and do that.

Tags:,

Related Posts

About The Author

knoxg

Add a Comment

Your email address will not be published. Required fields are marked *