Maintainable Software — A Terrible Blog Post #3
Blog post number three in a series of terrible blog posts is now underway. Today, Dear Reader, (for there can’t be more than one person reading this, surely) we will continue where we left off yesterday rambling nonsensically about maintainable spaces and dive into a few disorganized thoughts about maintainable software and how it relates to maintainable spaces.
I really am in quite a mood this morning. I’m loving the idea of these terrible blog posts. I’m free to just give in to my self-deprecating humour. I embrace the terrible nonsensicality of everything that I have to say. There’s no need to justify my thoughts, or even to organize them nicely. I said something terrible yesterday and I’ll just add another worthless thing on top of that. Tally ho! Sally ho? Sally forth?
Onward…
I can’t carry on until I’ve reminded you, Dear Reader, of what I said last time. I was talking about maintainable spaces and how the foundational concept that allows us to design a maintainable space (e.g. my garage) is if everything is important then nothing is important. So we need to decide what’s important and get rid of the junk.
I failed in that post to go to the next step which is to say that after we’ve identified what’s important and let go of the stuff that’s not important, we can then start designing the space to fit the important things. Wouldn’t it be tragic if you decided that your shiny new compound mitre saw was important but then built shelves and not one of the shelves was the appropriate size to stick your saw on? That would be completely ridiculous and I would not know anything about that situation personally.
Let’s not dwell here too long because, well, I don’t have enough time for that. We must generate a large volume of terrible blog posts!
What about maintainable software? you ask, Dear Reader. Yes, what about that? It’s the principle of designing the space to have a place for what’s important that I was attempting to get to in order to jump off into the software realm.
The tricky part about comparing physical spaces to software spaces is that there are a number of things that we could possibly mean when we talk about software spaces. Could we mean an individual file in a project? Could we mean an object? Could we mean a collection of objects? What on earth could it be?
I cry forth a lusty laugh! Fah! How terrible this writing is! Haha! Let’s just embrace the terribleness of it and giggle for a moment before I share my thoughts on this matter.
I think that a ‘space’ in a bunch of source code would need to be a ‘context’. To understand what I mean you’d have to think about code execution path as a real life path. When the software you are writing is executing, there’s always some entry point where something starts happening. There’s some event whether it’s pushing a button, starting up the program or calling an endpoint in a web service like `POST terrible-blog-posts`.
Right after the event happens, the code is now running and we’re in the first place. As an all powerful software developer we can now ask ourselves, what is this place like? What’s important about this place? Is is organized? Do the important things have important shelves to sit on? If I look around this place, is it clear what’s important? Can I see what the exits are?
Sadly, a lot of times we arrive in ‘places’ inside of the software execution path that are more like a hoarder’s hovel than a maintanable mansion. It’s a place that’s stuffed with every idea imaginable.
Isn’t this wonderful Dear Reader? I have run out of time and I’ve hardly scratched the surface. I’m not even sure if I said anything of value.
I must empasize though, Dear Reader, that you are the only person reading this, surely so it behooves you to post a comment. No one else is available. Did any of that make sense? It’s alright if it didn’t because it was supposed to be terrible after all, but it would be interesting if it did make sense.
In conclusion, all I really managed to do was make a quick stab at defining what a ‘space’ is in software so that I could begin an analogy about how to make that space maintainable. Really, that ‘space’ might be a file, it might be a set of files, it might be an object. Objects and methods and files are organizational structures. These are the shelves and storage units that you put things on. The trick is to design the space so that the important things are obviously important and the less important things are put in a box or a cupboard.
I’ll never completely tame this beast today, so I might as well just jump off. See you next time Dear Reader.
