First, let me make this abundantly clear to everybody reading: I will not be naming names. Not here at least. On Twitter and other such places, you might be able to twist my arm enough to name such names. However, if you’re reading this, chances are you’re the type of person who will be able to decipher through what I’m saying and figure it out on your own.
Today’s post will be to talk about software. Settle down, let’s not get too excited! Specifically, this post will be about what started out as good, useful software, and then became the bane of many developers’ existence, how it came to be, and what steps can be taken to make sure you’re not producing something of similar napalm-worthy hatred by developers worldwide.
There are two major components to software development, good software design, and good UI design. This is true for any type of software, whether it’s web-based, an executable desktop application, mobile application, software running a 400 million dollar airplane, whatever the case may be. By software design, I mean the structure of the code that makes everything work, the code itself, and how it is written with future changes being kept in mind. UI is the user interface, specifically how a person is able to tell your software what to do, and how the person see’s the response from the software.
In my decades upon decades of experience as a software user, and even longer as a software developer, I have seen all sorts of combinations failing to maintain a good level of both software architecture and the UI, hell, I’ve even created a few myself. Nobody’s perfect! Sometimes a piece of software will be an absolute nightmare to maintain, but it will have the prettiest, easiest, nicest user interface anybody has or ever will see. Sometimes a program looks like it was drawn in crayon on cardboard, but the code is actually very elegant, well commented, easy to work with, and generally does what it’s supposed to do, how it’s supposed to do it.
Then we come across the monumental failures that are a combination of the above two scenarios. Terrible, unusable UI, and code that gives you a headache even thinking about it. Code that declares a global as a global. Code that could very easily turn itself into an infinite loop and crash the universe, if the user made one single input mistake. Code that should have just never been written. Code that was written “just to make it work and move on”. These are the things developers have to deal with, making sense out of this type of software, tearing it down and building it correctly.
So how does this happen? Are the programmers lazy? Incompetent? Evil geniuses who understand job security? Some of the time, sure, but I’d like to think that the majority of the time it is just poor planning. Imagine it like a building. At first it might seem like a really cool idea to have your sink on the ceiling, but once you have put all the pipes in, and forgot that you plan on having your sink on the ceiling, what are your options? You can scrap the idea of having your sink on the ceiling. You can rework the plumbing correctly so that it is able to service your ceiling-sink. Or you can just toss a garden hose on the roof, cut a big hole through the roof down to the sink, and have it “just work”. That’s definitely the easiest solution.
Perhaps I went a little crazy with this analogy, but it gets my point across to laypeople. What it all boils down to is planning. It’s your fault that you’re in this scenario, because you weren’t thinking of where the plumbing was going to end up in order to service the ceiling-sink. So now we have to completely redo the plumbing, or hack it in.
Of course we can never plan every possible outcome to every possible scenario that may or may not ever happen, but a lot of the time these software blunders happen because of things that could most definitely been foreseen if the developer had taken the time to think it through for just a few minutes. What happens to our program when we plan for exactly 3 buttons that are 200 pixels wide each, with exactly 50 pixels of space in between each, in an area that spans 800 pixels wide. Perfect, exactly enough space! 2 months later, you realize you need a 4th button. What do you do? You can’t change the width of the buttons, or the spacing in between each, because that would break this, that, and the other thing. So you put the 4th button on the ceiling. And now your application starts to look crayon’ish. That is when the cascade of failure begins. That is when you know that you have failed to plan accordingly.
So the moral of the story is to plan. If you are on a deadline, it’d be much better to take a day or two to plan everything out. To think about possible obstacles, or future changes to the project, and figure out a sensible way around them before it’s too late, rather than realizing when you have 1 week left in your deadline that you need to scrap half of the project, and start all over again with a different approach, because you failed to plan.
That’s my rant for this week. Plan, Plan, Plan!