There’s an anti-pattern in Object Oriented programming called “God object” or “God class”. An pattern is a design to follow. An anti-pattern is something to avoid. A God class is a class that knows and/or does too much. Breaking a problem down into well-defined units of limited scope is part of writing good code that can be updated later by someone else, and hopefully reused elsewhere.
Three things happened last week that got me thinking about simplicity in general.
Physical Simplicity
My boyfriend hung my art and I finally finished unpacking. I am in love with my space, how open and clean and uncluttered it is, and the pictures from my travels filling my wall space.
I’ve been throwing stuff out, and trying something where I don’t buy anything in February. I mean, I buy things I run out of (soap etc), I bought picture frames, hooks for hanging them and the two bamboo plants that frame my window. And I bought Kindle books and a TV series on iTunes (weirdly, these did not seem like purchases due to lack of physical objects and I only realized afterwards). But, having this mentality that I shouldn’t buy anything has made me interrogate what I would bring in without thinking, usually.
My policy is that if I wouldn’t take it with me on a move to another country and I’m not using it regularly, I should get rid of it. I hope this month’s awareness will stay with me because it’s apparent that to keep the empty space and lack of clutter is harder than accumulating things. It means interrogating every purchase and saying, “What will this add to my life? What will this replace?” – and it’s a constant project to decide what I’m no longer using and should get rid of.
Simplicity of Reusable Code
One of my colleagues made a reusable component, that I also was to use in my code for a particular button. I wrote the code around it on Monday, thinking I would have to change one method. On Wednesday, I got his component which worked differently than I expected. What I hoped would be a short fix took much longer, by the end of Wednesday I had it working – but only when the image part of the button was clicked, the spacing around didn’t work. There’s a long and complicated reason for this, but basically we were using two different types of buttons.
Thursday, I returned to my war with the button and by the end of the day it was working wherever you clicked. But in the process the reusable component had become a tangled and horrible mess that I was not going to submit. Initially it had fitted my colleagues purpose a little too well. Now, it fitted both his purpose and my purpose a little too well.
A good night’s sleep later, I’d stepped back sufficiently to be able to have an idea of how I should redesign it. By the end of Friday, I’d reworked the class so that our individual code was a little more complicated, but the reusable component we both called was much simpler. Hopefully someone else will be able to reuse it, even!
It is so easy to think that your use case is the same as all that will follow. Everyone I work with is really smart and the design of this component had been discussed and thought through. My use case was similar enough that it didn’t seem like it would be a problem – until I started to try and use it. This component is really very tiny, and yet it was able to know too much and do too much.
As an aside, I wouldn’t submit code that hideous anyway, but the code review process really removes any temptation because it would get – rightly – torn to shreds.
Simplicity in Organization
Someone said to me that I was trying to add an excessive amount of structure to a rule-free organization. They were right, I was asking a lot of questions and suggesting a lot of ways in which we might quantify and/or measure what it was they were proposing to add.
We have something very simple. Everything in it has clearly defined responsibilities and purpose. It’s easy, and it’s clear. What they are proposing changes that somewhat, but I don’t think we should use that simplicity to add extraneous things – that’s how we’ll end up at something complicated.
Fight to Keep it Simple
I may or may not manage to keep my apartment clutter-free. My design may or may not work for the next person who wants to use it. I may or may not win the argument over complicating organizational structure.
My friend says, why do you need to get rid of things you wouldn’t take when you move, now? My colleague asked why didn’t I just use the thing that the reusable component uses. My friends ask, why do I care about the argument – I can just walk away from it.
And it all comes down to the same thing – I think you need to fight to keep things simple. So I’m not going to say, “I’m just not going to bother with this” without first attempting to make the case – via code or via argument – for a simple, reusable way.