Nearly five years ago, I was looking over some code a former developer had written, and I started to have the same thoughts that I’m sure so many other developers have had cross their minds:
- Why did they do this in this way?
- Why didn’t they use method X or framework Y?
- Why didn’t they comment this more/less/differently?
And I’ll admit it, I even had the thought “this sucks!” start to peek out of the back of my mind.
Then I started thinking about how harsh I can be, both to other developers’ work, and even to my own. So I started envisioning this hypothetical scale in the back of my mind, as a sort of ruler that I had been subjecting everyone’s work to. Then I decided to take it to the next level, and visualize it.
The Brian Adams Rating System was born:
Looking back at the system all these years later, I’m struck at both how hard we can sometimes be on others and on ourselves, but also how I think the scale perfectly illustrates how (some) users grade our software in their own minds.
A positive spin on this might be that there is always room for improvement and to make things better (which is certainly very true).
The negative spin? That unless you basically ace the landing, users will not be satisfied.
Obviously the scale is a gross generalization that describes a particular kind of person (me!), but I believe there are more of us out there than some of us want to admit (or perhaps I’ve just convinced myself of that to feel a tad less odd).
I do think looking back now, this scale can be both a humorous way to approach kludgy software (I’m still known to rate new services and apps with the scale), but also offers a cautionary tale about being hypercritical with yourself, your peers and your teams (for the managers in the room).