“Captain. I have a visual.”
“What’s the status?”
“Just one mutant bug, sir.”
“Ha! What can one bug do to our company? Destroy it.”
A tank round was fired in the bug’s direction.
“Good shot. Continue onward.”
“Wait, captain. Something doesn’t seem right.”
“What’s the matter?”
“The bug…it’s spawning more bugs! There seems to be no end! What should we do, captain?!”
“We stand our ground! All troops, fire at will!”
The sound of artillery and machine-gun fire rang in discord.
“It’s no use. There are too many of them! At this rate, we’ll be destr-”
Such is the story of many software developers around the world. Day after day, hours are wasted away in attempts to eradicate bugs, and yet, bugs seem to find their way back into software in larger numbers. There are many contributing factors that lead to the decline of software quality. Time pressure is one of them. Software design, or lack thereof, is another. There are other negative forces at play, and sadly, the current state of software has become a part of our culture. Alan Kay once said, “Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.” It may sound harsh, but I think most of us can agree that this is true for much of our industry. One has to wonder how we even reached this state.
Software bugs result from a wide variety of symptoms caused by bad code. They include tight coupling, low cohesion, duplication of concepts, wrong abstractions, misuse of mutability, and much more. In an attempt to fix bad code, developers try to rely on principles such as SOLID, DRY, Law of Demeter, and others. While these properties are desired, they are end goals and are not a means to an end. What’s more important is the thought process that leads to desirable code which naturally yields those properties.
There are also some misunderstandings behind terms thrown around so much in our industry to the point where they have lost their original form, of which “object-oriented,” accompanied with its forgotten history, is probably the most misunderstood. Many think object-oriented languages guarantee object-oriented software. They do not. Object-orientation is a way of thinking. In order to move forward, it is important to understand at least some of the history behind our industry and to remain open to ideas, old or new. It is human tendency to stay behind the shield of familiarity. Familiarity can help us when it comes to productivity among other things, but it can also hold us back from understanding other important ideas. We should not sacrifice things that are simple for things that are easy.
In no way am I saying that our industry is doomed. There is good code out there, but those are hidden gems that are swept beneath all the “smelly code.” The goal of this blog is to reverse that, even if just a little bit, by exposing to others what I have learned and will learn. In no way is this blog a silver bullet, but I hope it will foster discussions that we can all learn from. Because I come from an iOS background, the language I will be using is Swift, and my examples will reflect an iOS environment. Don’t worry if you’re not familiar with this environment. I’ll do my best to ensure my examples are void of any confusion. I am excited to see where this journey will lead and the people it will bring. I look forward to seeing you in the next blog post.
eatsleepios 