Don’t Fight Ruby!

In this blog post, “Adding Type Checking to Ruby,” I spit up a little bit in my mouth. I don’t want to be harsh… I can appreciate Daniel’s different approach to Ruby.

Mind you, I’m no Ruby whiz (yet), but look at this example:

def create_name(fname, lname)
  raise "fname must be a String" unless fname.kind_of? String
  raise "lname must be a String" unless lname.kind_of? String

  fname + " " + lname
end

I really couldn’t get past this first example. We’re seriously in dire need of checking that a first and last name are passed in as String types? I know it is just an example, but it is a lousy real-world example. It’s a bit like saying we need TDD and proceeding to show test-driving an accessor. I need more red meat!

Okay, so then there is some “Type” library that bundles up some helper methods to make the ugliness above go away:

typesig String, String
def create_name(fname, lname)
  fname + " " + lname
end

Except, the ugliness didn’t go away because it is the concept that I find hard to embrace.

I think the author is attempting to coerce Ruby to act as if it was statically typed. Static typing can be a helpful crutch, but more often than not, it just gets in the way. And if you like it that much, then use a language where it is built-in already. But certainly don’t pollute your Ruby code with pseudo-static type checking on every method!

I would advise against focusing on that static typing retro-fit effort.

In doing Ruby development, I have found it better (and easier) to put your labor into:

  1. writing clear, object-oriented code
  2. driving your code test-first (BDD/TDD)

Let your tests tell you things are working right. For example, if you wanted to ensure the class that had the first and last name in it behaved properly, you could write RSpec tests:

it "should show patient name as 'first last'" do
  @patient.name.should == 'John Johnson'
end

And if you really wanted to test that the values were Strings you could protect the creation of that object. For example, in a “validate” method that ensures that if a “Setting” instance is to represent a Boolean, than its value better be set to “true” or “false:”

# Settings to be used in the program
# Access in the program as follows: s("Company")
class Setting
 include MongoMapper::Document
...
 # Attributes ::::::::::::::::::::::::::::::::::::::::::::::::::::::
 # What the user sees as a label
 key :label, String, :unique => true, :required => true
 # How we reference it in code
 key :identifier, String, :unique => true, :required => true
 # Data type
 key :field_type, String,  :default => "String"
 # Store any kind of object in the value field.
 # This is what we will use to substitute for the setting
 key :value, Object,  :serialize => true

 # Validations :::::::::::::::::::::::::::::::::::::::::::::::::::::
 validates_inclusion_of :field_type,  :within => FIELD_TYPES
 validate :validates_as_boolean

  def validates_as_boolean
    if field_type == 'Boolean'
      errors.add(:value, "must be set to true or false for Boolean type") unless value == true || value == false
    end
  end
...

Adding a contract into every method as a matter of course, is just a waste of time and a polluting of the code “forest.”

IMHO, let Ruby breathe the freedom it was meant to have.

The Agile Parallel

For nations that have known virtually nothing about individual freedom and only ever experienced tyranny, you cannot throw a switch and suddenly declare the citizenry ready for self-rule. Same goes for non-agile organizations.

The USA is probably the rarest of rare, in that we actually embarked on just such an experiment in 1776:

Can man rule themselves (without a strong tyrant*)?

* such as the Kings of Western Europe, the Czars of Russia, the Sultans of the Ottoman Empire, the Emperors of assorted Chinese Dynasties, etc?

Maybe the same applies to companies as to governments as to any large organization?

After reading “The 5000 Year Leap” and many other books about the founding of the USA, I have developed an opinion that our Founders distilled the essence of Man (and our flaws) in terms of governing. Around those inherent flaws, the Founders attempted to build an organizational structure that prevents these flaws from succeeding to take hold. After all, our Founders came from a experiential base of being under Kings… but they wisely studied many forms of government, all the way back to Cicero. The last thing the Founders wanted was a strong Federal Government — or they would be right back to where they started: a Ruling Class and Kings (just under a different name).

I (*very humbly*) think the Agile Manifesto distilled the essence of Man (and our flaws) in terms of software development. It will no sooner be foolproof at preventing failures than our own representative government. Without understanding the motive forces behind the tenets of the Agile Manifesto (or the US Constitution), there is little chance that merely acting out the parts will result in lasting success.

The Founders knew that the USA will only survive as long as we have an educated citizenry that participates in trying to maintain our collective goals as a society (primarily freedom and security), while being ever vigilant about not giving away the freedom of the individual.

At the close of the Constitutional Convention, a curious Philadelphian wondering “Well, Doctor, what have we got—a Republic or a Monarchy?” to which Ben Franklin quipped: “A Republic, if you can keep it.” He wisely also asserted the challenges behind keeping it:

“In these sentiments, sir, I agree to this Constitution with all its faults; if they are such; because I think a general government necessary for us, and there is no form of government but what may be a blessing to the people if well administered; and I believe, further, that this is likely to be well administered for a course of years, and can only end in despotism, as other forms have done before it, when the people shall become so corrupted as to need despotic government, being incapable of any other.”

I have always said, “Agile is Hard.” So is freedom, as pointed out by Thomas Paine:

“Those who expect to reap the blessings of freedom, must, like men, undergo the fatigues of supporting it.”

Similarly, an organization’s software development “freedom” will be limited by the understanding that the “citizenry” has of just what makes up quality software and quality processes and self-rule.

Much as it is the rare country that can pull off self-rule like the USA, it is probably the rare large organization that can achieve the same measure of success. In the business world, there is at least a chance that poor leadership in a large organization will be self-correcting via business failure (barring unnatural outside forces). What’s worse, in my opinion, is that there is virtually no corrective force at work in our Government (or military), where bureaucracy and inefficiency can grow un-checked (except by the power of the purse). In large organizations, it is is often easy for folks to “hide” in the comfortable confines of busying oneself with doing a prescribed function (or being in incessant meetings <g>)and passing it off to the next cog in the process, with nary a care if it is an effective use of your time, or not.

The Founders believed that our rights came from God (for if they came from a man — King or otherwise — they could be taken away at any time). The intent was to give the individual as much power as possible, delegating very limited powers to government. As the structure of “government” moved further from the individual, from the town to the township to the county to the state to the federal level, the powers over the individual were necessarily diminished. After all, who knows best about what the town square should have but the town folk? It’s kind of like high cohesion and low coupling…

Similarly, the Founders built in plenty of checks and balances and distributed “power.” Much like a well-oiled Agile team that embraces clients, testing, and the quality folks as checks and balances.

When a software organization is similarly structured to permit strong cohesion at the local level, and responsibility to stakeholders, and very little coupling through the levels of the organization, good things happen. Even a large organization that skillfully permits freedom at very low levels (recursive-like delegation) in the organization gains the benefits of Agile. When the power structure is turned upside down (like in large, command-and-control bureaucracies with prescriptive process, or in the US Gov’t dictating minutiae in our daily lives), less good things will happen. I might even suggest that this sort of system results in natural selection of followers/non entrepreneur types, further exacerbating the situation. But I digress…

If the percentages during the USA Revolution are any indication, one-third were for the old way, one-third were ambivalent, and only one-third were for the new way. What that bodes for Agile sweeping aside the old way, I am not sure.

Fortunately, we “Agile Founders” did not have to “pledge to each other our Lives, our Fortunes, and our sacred Honor.”

Carry the freedom to deliver quality software at your core. The revolution starts with you!

The Agile Uprising

We were discussing (on a mailing list) the Egyptian uprising and the interest in watching to see who/what stepped in to fill the vacuum of an apparent “leaderless” bit of unrest. Will there be freedom and democracy? Or yet another autocracy? I think there are some parallels to our software world.

Sometimes I wonder if some folks just — subconsciously maybe? — like to be told what to do. After all, it is easier to follow a prescriptive process that you are told will result in the desired goal, than being asked to achieve a goal on your own.

In 2001, the “Agile Manifesto” asked folks to achieve a goal, largely on their own. While there are plenty of agile practices that one can adopt as individuals and teams, there was no glaring “Rational Unified Process CD” with all the process, roles and diagrams that you could ever want to hide behind. There was no venerated “Waterfall Process” that allowed entire silos of functional teams to work on their own with little linkage to being effective at ultimately meeting the goal (until it is too late). There was no marketing-driven organization crying out for the need to be more agile. Hence, it has taken nearly a decade for Agile to become mainstream.

In 2001, Agile was just kind of thrown out there, fanning the flames of freedom for millions of software developers. For a long time, there was no real concerted effort to coalesce a new form of software development and spread it among the unwashed masses.

There didn’t need to be, or so I thought. Agile urges each individual to (using a US football metaphor) “throw the BS flag” whenever there is a need. Agile asks each individual and team to be craftsmen and do their best to achieve the client’s goal.

Agile throws off the shackles of command-and-control and bureaucratic absurdity. Agile works best from the bottom up, being “pulled” in the proper direction as we attempt to satisfy the needs of the clients — not force dictates down their throat. Agile expects and demands the best from individuals.

However, with great freedom comes great responsibility. Being agile is simple, but not easy.

I suppose some dominant command-and-control, bureaucracies were threatened by Agile uprisings, and kept the practices suppressed, driving some teams “underground.”

In the past few years, however, our community has seen a major embracing of Scrum by small and big companies alike. Maybe Scrum looks enough like routine Project Management that bureaucracies can be easily led to buy into this “agile” stuff.

So, maybe the Scrum Alliance did step in to fill that leadership vacuum after all?