Got to get this blog going again!

In the meantime here is my movember badge!

Attack of the Killer Tomatoes!

Google App Engine already has a Killer App.

…my plan is to build a tomato tracking application on top of THE CLOUD (cue the music). The wife and I are planting a bunch of tomatoes this year, so I’m sort of hopped up on them. The app will let folks to report on the life, well being, and eventual yields of their backyard tomatoes.

That'll learn them Ruby weenies to underestimate us!

Can Software Engineers save lives?

Keith has a post about getting on the DVCS bandwagon. What really interested me in the post is the part about his discussions with a colleague about the choice of tools.

"It's kind of a shame that people like Ed and myself can semi-legitimately get involved in a conversation about which DVCS and why. Summed over all the people like Ed and myself that's a lot of mental energy being poured down a black hole, across the industry as a whole. Especially since it seems as if there is almost nothing to choose between these tools."

It reminded me of this quote from Philip Greenspun.

“Another issue is a perennial side-show in the world-wide computer programming circus: the spectacle of nerds arguing over programming tools. The data model can’t represent the information that the users need, the application doesn’t do what what the users need it to do, and instead of writing code, the “engineers” are arguing about Java versus Lisp versus Perl versus Tcl. If you want to know why computer programmers get paid less than medical doctors, consider the situation of two trauma surgeons arriving at an accident scene. The patient is bleeding profusely. If surgeons were like programmers, they’d leave the patient to bleed out in order to have a really satisfying argument over the merits of two different kinds of tourniquet."

I can't find the original source of the quote, so I grabbed it from this post. My guess is that the original quote dates from the late 20th century.

It's good to see how slowly technical culture evolves.

List Comprehensions Lazily

Ed has a nice post about list comprehensions in Erlang, and mentions that Python has them as well.

If you are interested in using them in Python, but actually only need the resulting items one at a time or on demand, then try generator expressions.

They have the same syntax, except they are enclosed in parentheses rather than square brackets.

>>> some_list = [i*i for i in range(12)]
>>> some_list
[0, 1, 4, 9, 16, 25, 36, 49, 64, 81, 100, 121]

>>> some_generator = (i*i for i in range(12))
>>> some_generator.next()
0
>>> some_generator.next()
1
>>> for i in some_generator:
... print i,
...
4 9 16 25 36 49 64 81 100 121

The list comprehension creates and returns a list (as you would expect) whereas the generator expression creates a generator object that you can call next() . This will return the value defined in the expression that "generates" the values i.e. in this dumb example range(20).

I've heard from the horse's mouth that if you get to larger amounts of data (no idea what would be large enough to cause concern here) that generator expressions will be more efficient.

Agile and Orthodoxy

I work in a team led by someone who can safely be termed a veteran Agilist, with colleagues who have all swallowed the red pill.

I recently wrote a blog post about Kanban, which has left some of my colleagues somewhere between troubled and sceptical.

Before I go any further, please note I am not an expert in any topic, let alone Agile or Kanban. What follows reflects my limited understanding of the issues surrounding the two subjects. I should also add that Keith, as far as I can tell is not amongst the sceptics. He was also at the talk and was not troubled by the subject matter in fact I think it's fair to say he was enthused.

I don’t know what all of the reasons for disquiet are, but certainly amongst them is the feeling that as the Kanban approach does not at least presume (if not enforce) what are accepted as the pillars of the faith, then it is some sort of heresy.

Without two week iterations and test first development as pre requisites, how could Kanban be compatible with Agile?

Well I have re-read http://agilemanifesto.org/principles.html and I don’t see anything in the Kanban approach as illustrated by David Anderson at QCon that would be in conflict with any of the principles as enshrined in the manifesto.

At this point Keith will tell me that the manifesto is just a collection of meaningless platitudes. On some levels, that’s true enough. Who doesn’t want to be more of everything nice and sweet and smashing? But why expect more? It is after all a manifesto.

You can try to live up to some or all of the manifesto if you like. But claiming to adhere to the principles means nothing if you take no action is support of the aims. Actions taken in conflict with the principles must surely discredit your claimed adherence.

On the other hand if you claim to believe in some set of principles, take actions that support them, and do not take actions in conflict with them, then surely you have some right to say you are an adherent.

I should say at this point, that it’s probably of no interest to teams who are happy in their jobs and producing good work that delights their customers, what any manifesto . But let's pretend for a moment that it is important to them.

Despite it seeming too obvious to mention, I think its worth remembering that the things we might like to aspire to in Agile are not laws of nature. They are principles. The simple fact that we have XP, FDD, Crystal, DSDM, Scrum and others should be evidence enough for that.

Before you cry foul and say there is something in common with all of the approaches that form the core pillars of the faith, and amongst the common features are, for example, short iterations and test first development, let me respectfully direct you back to the manifesto.

So why don't I get back to my vague rambling point? Given that we are mostly normal human beings doing mostly abnormal stuff, then we still have the problem of working out what practical things can we do in our daily work to help us achieve our goals while not compromising our principles (too much)?

Clearly the best approach would be for us to be liberated from wage slavery but that’s another issue.

However, to be more realistic, putting the principles into actions is where the specific day to day activities of Agile come in. This is where a team might decide to do XP for example, with a Scrum wrapper perhaps?

Nothing in the manifesto requires such explicit practices as n-week iterations or test first development. XP or FDD have, on many occasions been found to greatly improve the chances of reaching the goals of a project while being true to the principles of Agile. Test first development is a pre-requisite in XP, but that is not to say that it is a pre-requisite for meeting the higher aims of Agile.

That’s all great but what if someone finds a practical approach that also helps in meeting customer needs and values, but at the same time does not care whether you do formal design or test last. You or I might think that sounds strange but surely regularly delivered, working software in the customer’s hands, meeting their needs and values trumps all.

For me the basic principle that I believe has most value is favouring individuals over processes. If we follow this principle then what I think should flow naturally from this are practices that people are happier with.

To insist on two week iterations and test first above all else then that would be favouring a process over individuals.

If being Agile was as simple as adopting a recipe of processes, it would not be so hard to adopt. But then it would be as meaningful as public only displays of piety as a means to get into heaven.

So getting back to a really good talk I listened to at QCon. The case study was an example where a demoralised, staggeringly under-performing team was turned around very quickly. There was no test first, no iterations … no kidding eh?

The team focussed on what was blocking progress and the elimination of wasteful practices in what they were trying to achieve. They tackled those problems in a way that empowered individuals in their daily work. They took an approach that imposed very little in the way of process. They freed people from a lot of the wasteful drudgery in their jobs but did not dictate how they should carry out their allotted tasks.

All of the above could have been achieved in many ways. What I think is exciting about Kanban is that it focusses very tightly on controlling a variable that is very easy to understand and can be controlled quite easily.

That variable is:

The amount of work in progress

I reckon it’s always best to try and effect changes on things you can control rather than things you can’t.

Dramatically changing how a team works is a great deal harder to do and I would argue ultimately a futile undertaking.

Should you do DSLs alone when no-one is watching?

This post is sponsored by InfoQ and in particular this article.

The article gives a summary of a blog post from Dave Thomas, who may well be a very pragmatic guy.

The main thing of interest to me in the post is something related to why I think that the current hype about DSLs is becoming a bit onanistic and the BDD frameworks are at best a distraction.

If I understand correctly the crux of the problem is as follows. If we are touting these DSLs at domain experts in the belief that the domain experts who will be comfortable with these DSLs are business users, then we have a problem.

In the context of Applescript Dave makes the following observation:

Given ...

"... for years, I've been trying to get into AppleScript. I keep trying, and I keep failing. Because the language is deceptive. They try to make it English-like. But it isn't English. It's a programming language. And it has rules and a syntax that are very unEnglish like. There's a major cognitive dissonance—I have to take ideas expressed in a natural language (the problem), then map them into an artificial language ..."

When ...

"When you're writing logic like this, with exception handling, command sequencing, and (in more advanced examples) conditionals and loops, then what you're doing is programming. The domain is the world of code."

Then ...

"... who are the domain experts? That's a trickier question to answer. In an ideal world, it would be the business users. But, the reality is that if the business users had the time, patience, an inclination to write things at this level, they wouldn't need programmers. Don't kid yourselves—writing these specs is programming, and the domain experts are programmers.

I guess this is the real problem I have with all of this. Surely a specification (or specification language), however captured has to have the characteristics of a ubiquitous language. A programming language does not need to have this characteristic.

I'm thankful to Keith for pointing out the Cobol Fallacy to me as I think this has some bearing on this sorry tale of trying to create a natural language like DSL.

@Spec
begin
self.am.sorry."to say that i believe".it.is.all('bollix')
end

Python is not Object Oriented - Ruby is!

It’s not that I find language debates very exciting, but when the same old tired arguments keep coming round and round I feel spurred into righteous anger.

I do have a lot of likes for Ruby. Not to the point of indecent arousal, but I do have a warm fondness for the little brat.

On the other hand I occasionally hear some nonsense from the Rubyists. I have heard stuff which is not quite as tasteless as boasting about re inventing the wheel, but more like claiming to have invented the wheel in the first place. Not bad taste but a bit upstart like.

So what has sparked this mild rant? I have recently re-heard the claim that Python is not really Object Oriented.

If I had the energy and I wasn’t so manically busy at work, my first reaction would be to question whether or not this is actually a problem at all.

There are some rather clever, but of course deeply misguided (the misguided bit is either a lame joke or serious depending on who you are) people, like him and him who think OO sucks and is a bit sad.

For a bit of balance I would have liked to have linked to posts from a woman with this point of view as well. Sadly I could not find any women that thought that this was an interesting debate …strange but true.

But for the sake of making some progress with this post, let’s indulge the “not really OO” slight and see what some other smart-arses think about this.

The OO Myth

Explicit Self

Specifically have a look at the bit about getting rid of self

“... Python uses the complimentary approach, treating functions as first-class citizens.”

As an aside I wonder if “first class functions” makes Python more functional? The functional aficionados would surely chafe at the suggestion.

Interestingly some of those who are most down on Java because:

1) It encourages mutable state.

2) It is sort of object oriented.

3) Requires a lot of low level, error prone grunt work to achieve concurrency.

4) It is not functional.

can often be inclined to “OO” zealotry when comparing Ruby to Python.

Is Ruby the revenge of the born again “OO”er?

Incidentally “OO”er should be pronounced in a Frankie Howerd style.

Before this post degenerates into handbags at dawn lets spare a thought for the many old time Lispers and Smalltalkers who think of both languages as dysfunctional, deficient, bastard children anyway.

Have a read of the comments at the end of this post for some pithy high level comments on what Gilad Bracha thinks of both Python and Ruby.

For those of you into the monkey patching debate make sure you follow the link from Voidspace to Gilad’s blog.

Even Matz has stated (in good humour of course) that Ruby is a either a cheap rip off of Lisp or Smalltalk. I can’t remember which exactly. Have a watch of Matz’s talk in the afternoon session video from this page and maybe you can catch the quote.

What’s my point or points?

Only these:

• Python had objects from what can reasonably be considered the start.
  
• The implementation or OO in Python differs from that in other languages.
• The syntax of Python differs from other languages.
  

On the last point, Python, while nowhere near as "syntax light" as Scheme, is still pretty light by comparison with some languages. To my eyes, Ruby is a lot heavier on syntax, but then I am biased.

On the other hand I am not at all upset that Ruby is not very functional a la Haskell, and would not criticize it on that front.

Anyway pick whichever language. You will have fun in either one and you won’t be ashamed of yourself in the morning.

Just don't mention the whitespace.