Software Virgin

I know, I know. The term 'software virgin' is derogatory, but in my defense it wasn’t me that coined it. It was a fellow exec. from long ago that set the phrase. Ironically, while she was referring to others, she herself was never able to transcend its base definition.

Software is exceedingly complex, but it is easy to miss that fact. Every year, more people are attracted to it and many come in with preconceived notions about what they can do, and how simple it will be to get it done.

For those of us that have been around for a long while, and have gradually come to learn what’s possible and what is not, this influx of new people has always represented a problem. It’s hard enough to get the system working, without having fight off someone who is dismissing your knowledge as pessimism.

Knowledge is a funny thing. The 10,000 ft view may appear simple, but the true understanding comes from the depths. Doing something, and doing it well, are very different beasts. I wouldn’t discourage people from playing with a new field, but that is completely different from doing it professionally.

Software virgins come in three basic flavors. Some are business people that are drawn to technical bubbles because they sense easy wealth. Some are managers trying to make their careers by implementing a grand project. And some are programmers, fresh out of school, capable of coding solutions to homework and small systems, but dreaming of creating giant masterpieces.

They all have an over-simplified expectation of the effort. And their own contributions. The business people think all they need to be successful is an idea. The managers believe that if they get a list of things to be done, that is enough. The young coders think its some clever functionality or a nice algorithm that will get it done. Each in their own way, is missing the essentials of the problem.

Software is about building something. Something large.

An idea is great, but they are a dime a dozen these days. You see an endless stream of new web sites out there all with a slightly different variation, what my friend humorously refers to as “roadkill on the information super highway”. You can’t win with an idea, it has to go deeper than that. Ultimately software is about people, and about what the software does for them. If the idea is how to make money, then its has little to do with people. You have to convince someone to use the software, it has to do something better than what they have now.

Managers love lists. Many think that if you just get the work items into a list, and start checking them off, then you will achieve success. So often I’ve seen that fail because they’ve chosen to ignore the dependencies between the list items, or the exponential explosion of the sub-items. Some things must be done first in order to keep the work possible. In a big software project, the dependencies quickly become a scrambled nest of complex inter-relationships. Trade-offs have to be made, and the consequences can be severe. If you start in the wrong place, each thing you do simply adds more work to the list. It grows forever. A big project is really a massive sea of details, buried in a tonne of complexity. Any list is a shallow reflection of the work needed to be done. If you believe in Jack Reese’s perspective, the final list, the one that contains everything, is the code itself. You don’t have all of the details in place until you have all of the details in place. The list is the code, the configuration items, documentation and all of the other stuff that is assembled to be able to move the system into a place were it can be utilized. Until then, you have no idea about ‘everything’, just some things.

When programmers first learn to code, they quickly become entranced by their own ability to assemble increasingly larger sets of instructions. At some point, usually before they’ve experienced working on a full project from start to finish, they come to an over-estimation of their experience. If they can build something small, then clearly they can build something massive. I guess it’s a natural part of our human behavior, best summarized by “a little knowledge can be a dangerous thing”. Since software isn’t well organized, and there isn’t some 60 inchs of textbooks that will give you the full sense of just how wide and deep things really are, it’s easy to miss its vastness. And to make it worse, those with experience tend to frequently contradict each other, or drop out early. We’re a long way from being a sane profession, or even a craft. Within this environment, it is easy to draw certainty from too little knowledge. The consequences of this litter the web with endless arguments over things poorly understood. In many instances, both sides are wrong.

Software has a startling high failure rate. So do technical startups. And every time, each different type of virgin, blames the others. Many, even after some experience, become fixed to their errors believing that they are somehow superior, even if their efforts are barely working. It’s a strange industry, software. A place where one of the most difficult problems is working around the software virgins, on your way towards trying to get something substantial. And the more you know, the more you learn, the less certain you are of anything, or everything. Someday I’ll get to the point where I am absolutely sure I know absolutely nothing. The zen of software knowledge I guess.