I figured I'd start this blog with a bit of philosophy. Why did I call it 'The Nothingness of Software'? Well, there are two reasons. The first is that software development, from my perspective (and probably from the perspective of management) is like a void: money and tasks/requirements are input, and a small amount of an intangible, unmeasurable resource known simply as "code" is output. It's kind of like juicing an orange - you go through a lot of effort to produce a very small amount of end product.
But there's more to it than that, right? In most industries, a large amount of effort producing a small amount of end result would quickly be analyzed for "efficiency", and projects would probably be scrapped or "enhanced" to maximize output and profit. This does happen in software development, but not in the same way as it might in, say, cooking or manufacturing. If efficiency in manufacturing were down, this situation would be corrected by either decreasing workload, or increasing the number of potential workers (either human or automated). In software, however, the workload is tied into the end product - can you really ship a software product that doesn't have feature X when that was a feature that was required by the end customer? Worse yet, the problem is compounded if we add additional workers - it's widely known in the software industry that adding new engineers to a late project will only make it later [1:1].
But why is this different than, say, building a bridge? The civil engineers in charge of creating a bridge over a river have a goal which they can't skimp on. My rationale is that 1) a bridge is a tangible object, meaning that you can touch it, feel it, and visibly gauge how much work is getting done on it, and 2) civil engineering is a rigorously developed field - the current standards for civil engineering are the result of evolution over thousands of years (essentially since humankind began). Software engineering, on the other hand, is the product of evolution of just over 60 years. Comparatively speaking, software engineers are babies compared to civil, mechanical, or even electrical engineers.
But I said there were two reasons I chose this name for the blog, right? The other one comes from my martial arts studies. In Kung Fu, we strive to strike in such a way as to move from absolute stillness to motion in no time. The concept stems from the idea of the "Wu Chi", or the void, from which all energy is thought to flow. We strive to attune ourselves to the void, so as to listen to the messages of the universe. Sound like gibberish? Perhaps... it takes some getting used to, and sometimes philosophies such as this don't lend themselves well to those who haven't been through years of training to really understand what it means.
What does that have to do with software? Well, in a sense, software development is a creative process - an art - much like Kung Fu. In that sense, software development should stem from the void ("Wu Chi") as well. So, the "nothingness" in software is actually the creative process. If you're a Lost fan, there's an episode of Lost where John Locke and Boone are sitting on a log staring at the newly uncovered hatch. Boone comments that they have been coming to the hatch for the last three days and doing nothing more than staring at it. Locke tells Boone a story about how Michaelangelo, due to his father's insistence that he wouldn't use his hands to do his work, was commissioned to carve a statue. Michaelangelo would come every day and stare at a block of marble for eight hours. One day, his sponsor asked him, "What are you doing?" Michaelangelo, surprised, turned around and replied, "I'm working." Years later, the block of marble was the statue of David.
Creative inspiration comes from the mind. Thus, to simply be "doing" something doesn't necessarily mean you're working. Similarly, just because you aren't outwardly doing any activity that's visible to the human eye doesn't necessarily mean you aren't working. I chose the name for the blog because what I do is software. Sometimes I feel like, as Jimmy Buffett so eloquently puts it, "I'm stranded on a sandbar." So what differentiates a good software developer from a bad software developer, or a good software developer from a great software developer? These are some questions I ponder sometimes. Additionally, the software development world is really not what they teach you in a Computer Science department - it's much more intricate than that. In a Computer Science degree program, you learn (or should learn) programming skills, software engineering concepts, teamwork, communication skills, problem solving, creativity, and similar technical aspects about your career. What they don't teach you is the politics - how people will interact with you and treat you, or ignore you, in the workplace. Now, I'm not saying all of this is bad. It's just sort of a nebulous area. A void, so to speak, which I call the "Nothingness of Software."
Welcome to my nothingness (or perhaps Nothingness?). Please be aware that this is an uncharted void and you may get lost. Or, you may have found a better path through it or around it. You can opt not to take this journey with me, or leave anywhere along the way. I don't know where we'll end up, but I hope you and I both learn something along the way.
Helm, set a course for two two seven mark eight six. Engage.