RMS Suckiness

A couple weeks ago I wrote a framework for working with the images that we use for our system at work that I'm rather proud of. The framework took a couple of weeks to write to the point of it working well enough to make it to our production environment, but there are still some improvements that I wanted to make to it to make it easier to test on an ongoing basis and a bunch of other small improvements throughout the system.That part is 100% normal.Then I started to poke at the code. Keep in mind that this is code that I myself had mostly written; there were some additions made by my co-worker for the parts that used my framework.Adding a feature necessarily is changing the code. Anything that's changing has various degrees of freedom about how you're actually changing things. You make some changes and basically figure out how it smells--are there any aspects that piss you off.Here's where things change. I have my own ideas about what makes code suck. I'm not alone though, there are plenty of people with other opinions--none of them the same. Many, or even most, designs can be made to work as long as you force things to fit together. Like, for instance, anything can be made to work if you have enough hash tables strung together. It'll nominally function, but god help you if you ever need to change it or if you find a bug.You have design reviews before you start coding something big. After that you wind up with something that's maybe 90% of the way there; the only way to get to 100% (if that's even possible) is to do a pure waterfall approach to the problem. Most times, however, when modifying an existing system you just rely on code reviews. That's a problem.Here's where I started to think about things like this. Everyone has an opinion about how things are supposed to be put together. Everyone's opinion is different. What if you could just metaphorically take the root-mean-squared of the opinions to make the decision. Some people want more abstraction, some people want less. Some like complexity and flexibility, some like to be as simple as possible. Look for agreement and try to discount the outliers while still trying to understand where they're coming from.As things shake out, it's a little of everything.Don't make things that make only one person happy, not even yourself. Make sure that you get input for even things that might seem a bit trivial. Take that feedback into account.Then give it the smell test. What looked good with handwaving or on a whiteboard might not feel right when you have it committed to code. Iterate. Smell.Just because you made a design doesn't mean you have to stick with it. You don't.Aim to minimize the suck. It won't be perfect for anyone, but hopefully, people can get along with each other--and the code.