Legislative Code I

Having just been listening to NPR, I caught a certain word used in describing what the law provided. It provided a set of "requirements" to define certain health care facilities and what they need to provide to call themselves a nursing home, assisted living facility, etc. I found this to an interesting word, perking my ears up, because as a tester the word requirements means something very important. It is what I use to create my tests. I am aware that this is both under and over generalized, but I think most testers who aren't James Bach will give me some leeway on that simplistic definition for my purposes[1]. This in turn got me thinking about Lawrence Lessig's book about code being equal to law maker's law.

Now multiple people have addressed the question of analogy in regards to software development. One example I could find was one of my favorite authors, Jeff Atwood, who discussed if software development is like manufacturing. There are many others I have found, such as the analogy with manufacturing a stimulating conversation piece. Then there is the opinion that software is [or isn't] like construction. Yet still others find it like writing. Even stranger (to me, a non-gardener), some find it comparable to gardening. Finally I will mention one last interesting analogy, software development is like handling a helicopter. I find that one particularly interesting, as I don't consider being a pilot as a well understood activity, however I'm getting ahead of myself with that comment. Of course, I'm not the first to note how many of these variations of analogy exist.

I don't intend on debating too heavily in this particular post what software development is like, but it did make me wonder if software development and legislation are similar in nature. This is a topic I may explore in a future post.  However, it does make me wonder if simple experiences shade people's analogies to the point that we are not even talking about the same activity.

To go back to my initial analogy of code smithing (an intended word choice) being like legislation, much of our language is coloured by the law. For example, we talk about code, something that at least goes back to the BC era. Then we have these legal systems, which have completely different ideas of what the law is. If the concept of the law was at one point a single entity, it no longer is. It now is something very different. It is a divergent set of ideas about what code is.  Does the law apply to you if you are a person of great ability? Well it might not, depending on where and when.  Now just think about what you think of as a system in software development.  Go on, I'll wait.  Done?  Now, why not look at the plethora of data just one wiki article has on it. Then there is the human factor. We often believe things that are simply untrue. As a simple example, keeping with the law, conviction rates are lower and have shorter sentences for attractive people, yet we overwhelming believe that they shouldn't (in at least one group in a particular society).

To wrap all of this up[2], we are biased by our own experiences and human nature into seeing some analogies as more valid than others. Be it culture, community, personal or just human limitations, we have a hard time seeing around our own biases, if we can in fact do so. So when we disagree, part of what we should be doing is asking "Why do you believe this?." Then look at the value they find in what they believe and compare it to the value you find in your own bias. If you find more value in your analogy, keep with it. If not, maybe it is time to research the field and find out what does make sense to you. Oh, one last thing. Like James Bach said in regards to categorization (similar to analogy), "Of course. It's a heuristic. Any heuristic may fail...", I believe analogies to be heuristic tools, not enforcement mechanisms. I don't think a category should force someone to be stuck in a role. To paraphrase Kranzberg's laws of technology, tools are neither bad nor good, it is how you use them.

EDIT: Like a doubly linked list, this article now points to the second of three articles.

[1] I really do appreciate Jame's position that words matter.  Just sometimes words are meant to be vague.  As Saki put it, "A little inaccuracy sometimes saves a lot of explanations."  I do recognize that sometimes in depth definitions are required to be clear about a subject.

[2] Clearly there are lot of things I hit in this short article.  I hope to come back and hit each one in greater depth over time.  I just don't want to end up like Steve Yegge whose posts are awesome yet super long.