Thinking Software
There’s a couple big steps to make in designing software. First, the initial idea that I have or that someone comes to me with isn’t very detailed yet. It’s usually more of, “I need something that has a window on screen with a button that does this cool feature and fields you can type in the useful information to do that other cool feature!”.
So, the first step is to translate that initial idea into the internal structure of the geometric shapes in my head. Well, actually, the first step is to explore that initial idea and see what needs editing and changing. Ideas are great, but the first idea isn’t always the best one. Usually things improve with consideration no matter how much I get enamored with that first idea. So I have to be able to think it before I can write it.
There’s lots of ways to do this stage of design. But basically all the approaches for this are often rule-of-thumb approaches that work in some types of cases and not in others. Experience comes in handy for figuring how to do this.
Anyhow, this design idea has to get translated to those geometric shapes in my head. To do that, I have to figure out what little details in the design go with each other in a natural way. What’s the best fit or most elegant. Not, I’m not a perfectionist (well, sometimes I am), or compulsive (ditto). It turns out that math and beauty are related somehow. Elegant math is often “better” in some consistent way that inelegant math. And since math and software are so closely related, this works for software too.
Elegant software is better. Often it’s better in a measurable way. The software is more maintainable so it can be changed more easily with changing requirements. The software is more easily understood by another programmer, or more easily debugged (understood by the original programmer). I think of elegance as partly beauty and partly cleanness. A clean design is more likely to be a good design.
Elegance isn’t complexity, nor is it cleverness. It is a clean and natural design. To make a clean design, I have to let the components push back to me. I have to listen to them in a way. I have to pay attention to what they need as well as what I need them to do. In a weird way I have to let this imaginary objects have a life and be able to demand their own destiny.
So, finding that natural and elegant fit is important. One big part of this is what I tend to think of as figuring out where the edges should be. Edges are important - this is something like a buddhist or taoist concept. Figuring out the interfaces between components (those geometric shapes) is figuring their edges. What’s in them and what’s not, how do they “talk” to the other components and what do they “say”? It’s really becomes the definition of what each component is.
In my head, when I change what’s in a component, often that component changes shape. I visualize connections as thin strings between components, or sometimes ribbons. Occasionally they plug into each other like lego blocks do (layered network protocol software is like that).
Once I figure out those components, I have to translate those ideas again, this time into software code. Each component has to be expressed in the software language I’m using for it. Sometimes, or perhaps most of the time, as I’m writing the code some detail comes up that I didn’t consider earlier and that changes things in a big way. I have to go back and reshape some of the components again. There tends to be a lot of this back-and-forth. I don’t think there’s any really linear way to do this stuff.
Sometimes I make a component too big, and have to think of the smaller things that go inside it. I can do that on purpose to simplify things - after all there’s only so many things I can keep in my head at one time! But sometimes it’s because I didn’t understand that component well enough or missed some detail that caused it to need to be bigger.
After I get this into code, I work in the “code domain”. I’m writing the software code in an editor and changing it in that. But in my head there’s still the domain of those various shapes and structures there. The code and that stuff in my head are the flip sides of the same coin.