Tuesday, May 27, 2014

Testing Love and Polyamorous TDD

The rigor and quality of testing in the current software development world leaves a lot to be desired. Additionally, it feels like we are living in the dark ages with mysterious edicts about the "right" way to test being delivered by an anointed few vocal prophets with little or no effort being given to education of the general populace about why it is "right", instead spending effort evangelizing. I use the religious metaphor because to me it seems a very large amount of the rhetoric is intended to sway people to follow a particular set of ceremonies without doing a good job of explaining the underpinnings and why these ceremonies have value. I read with interest an post by David Heinmeier Hansson titled TDD is dead. Long live testing that pretty much sums up my opinion of the current state of affairs in this regard. A number of zealots proclaiming TDD to be the "one true way", but not a lot of evidence that this is actually true.

Yes, Test Driven Development (TDD) is a good practice, but it is NOT necessarily superior to: integration testing, penetration testing, operational readiness testing, disaster recovery testing, and any of a large number of other validation activities that should be a part of a software delivery practice. Embracing and developing a passion for all manner of testing are important parts of being a well rounded, enlightened, and effective software developer. Since I have this perspective, I'm particularly jostled by the perspective outlined by Bob Martin's treatise on Monogamous TDD is the one true way. In direct reaction to this post, I propose we start to look at software validation as an entire spectrum of practices that we'll just call Polyamorous TDD. The core tenets of this approach are that openness, communication, the value of people, and defining quality are more important than rigorous adherence to specific practices. Furthermore, we should promote the idea that the best way to do things often depends on what particular group of people are doing them (note, Agile folks, does this sound familiar?)

I chose the term Polyamory instead of Polygamy or Monogamy for the following reasons:

  1. It implies there are multiple "correct" ways to test your code, but you are not necessarily married to any one, or even a specific group of them
  2. It further suggests that testing is about openness and loving your code instead of adhering to some sort of contract
  3. On a more subtle level, it reenforces the notion that acceptance, openness, and communication are valued over strict adherence to a particular practice or set of practices.

All this is an attempt to promote the idea that It's more important that we come together to build understanding about the values provided by better validating our code than to convert people to the particular practice that works for us individually. To build this understanding, we need to more actively embrace new ideas, explore them, and have open lines of communication that are free of drama and contention. This will not happen if we cannot openly admit the notion that there is more than one "right" way to do things and we keep preaching the same tired story that many of us have already heard and have frankly progressed beyond. It's OK to be passionate about a particular viewpoint, but we still need to be respectful and check our egos at the door when it comes to this topic.

As a final tangental reference regarding Uncle Bob's apparent redefinition of the word fundamentalism in his post. As far as I can see the definition he chose to use was never actually known to be used for this. While I understand what he was trying to say, he was just wrong and DHH's use of the word based on the definition I've seen is still very apt. From the dictionary:

1 a often capitalized :  a movement in 20th century Protestantism emphasizing the literally interpreted Bible as fundamental to Christian life and teaching
  b :  the beliefs of this movement
  c :  adherence to such beliefs
2 :  a movement or attitude stressing strict and literal adherence to a set of basic principles <Islamic fundamentalism>  <political fundamentalism>

Uncle Bob, please try to be careful when rebuffing folks on improper word usage and try not to invent new definitions of words, especially when you're in a position of perceived authority in our little world of software development. Express your opinion or facts and be careful when you state an opinion as if it where a fact, it only lends to confusion and misunderstanding.

Friday, May 9, 2014

The brokenness of java in the cloud

In the cloud, it's important to be able to do have computers talk to each other and invoke commands on each other. This is called Remote Method Invocation (RMI). By language, I have the following recap:

  • Python works
  • Ruby works
  • Javascript works
  • Java ... makes you work

Java RMI is a godawful mess that should be killed now. RMI is a very simple thing until you let an argument of architects come up with "the best solution" and then it becomes a convoluted mess of edge cases. In it's simplest, RMI involves serializing and deserializing some input parameters and then running some logic, then doing the same with some output parameters... gosh, that almost sounds like HTTP to me (hint, it really IS).

I don't know exactly where things went wrong with java RMI, but there are registries, incantations, and special glyphs you need to paint on your door on alternate Tuesdays to make it work correctly. In python, ruby, and javascript, I can do RMI 15 different ways while drinking a beer and cooking a steak. In java, I repeatedly need to stop, read a book, ask a professor, read the book again, build some custom software to bypass a limitation (like spanning subnets), then ultimately rejoice in the amount of effort I put into my masterful solution.

In some ways, I think dynamic scripting languages scare off hard core engineers because engineers enjoy a good challenge and a lot of things that engineers love to spend time doing become brainlessly simple when using the right tool for the job. Note, this entire post was spawned by trying to get jmeter to coordinate a bunch of remote hosts to run a load test distributed over remote EC2 instances... You'd think this should be an easy task, but it turns out to be more difficult that one might think (mostly due to java RMI limitations).