#2782

ALT.NET Seattle Gathering

I was able to show up for the first half of the ALT.NET Seattle on Saturday and managed to attend two of the open spaces. It was a great group of people and I learnt a lot from the two talks I went to on agile without management buy in and dynamic languages and came away with some things to follow up on after the day was over.

What did I find out? Don’t feel like you have to read it all. Skip to the sections that interest you.

1 – Agile without management buy in

I’m going to blog about this some more as I have seen a fair amount of this. In general I think the consensus was that there was a fair amount you can do to improve the general practices and dynamics of the team but ultimately you’ll hit a wall. Things to consider include practices like standup meetings, retrospectives, continuous integration and unit testing.

Another interesting thing that came up in the talk was:

Each retrospective should produce one experiment that the team agrees to try for the next iteration.

I think I’d heard this before but obviously it had gotten forgotten. It seems like a great way to make sure your team really tries to get something new out of each retrospective.

2 – Distributed Domain Driven Design

Someone mentioned the article on InfoQ where Eric Evans talks to Greg Young about his large transaction system which uses domain driven design (DDD) but with very high transactional loads in mind. Greg talks about how his sytem maintains state over time and logs transactions.

The best summary I could find of DDD is a presentation by Eric Evans. Definitely worth a look. Thinking about your problem in terms of the domain has quite a lot in common with the XP concept of metaphor, which seeks to build a common language about the problem space that everyone on the team uses. Both are trying to improve communication.

3 – Dynamic languages

And now the biggie… There was a good discussion around dynamic languages. Several people in the room are using dynamic languages in their work, typically Ruby and Python.

Lots of people pointed me at Steve Yegge’s Dynamic Languages Strike Back post so I tried reading that. In all honesty the post is horribly rambling. I eventually opted for the video which covers a lot of interesting material. It talks a lot about the  three popular objections to dynamic languages; speed, difficulty of creating good IDEs or tools and maintainability of large applications. I think a lot of my reluctance around dynamic languages stems from negative experiences around the latter two*.

Steve’s post outlines how the former two of the three popular objections (speed and tooling) have been eroded, largely due to improvements in compiler design. Interestingly I’ve always been more concerned about the latter two (tooling and maintainability). Chris Tavares also had a couple of good points to add. Namely that Ruby and Python have a more readable syntax than Perl and dynamic languages tend to require less code to solve a given problem. Both these start to address the maintainability issues.

Dynamic languages allow more expressive problem generalization at the expense of type checking. Steve’s take on this was that this becomes more important the larger your application. The argument as to why you can do without type checking goes something like this…

You write unit tests to prove that your code works for all the scenarios you care about so you don’t need the compiler to check types. The unit tests do the checking so the compiler isn’t really adding value, it’s getting in the way.

This is all well and good, except… wait for it. Not everyone is that smart or disciplined. You could consider strong typing a crutch for weaker minds (including myself). Steve actually discusses this in his talk’s Q&A (around 1:03 in the video). Essentially one of his arguments is somewhat along the lines of good code should be hard to write. I’m not even sure he’s wrong about that.

But I am sure that the result will be a lot of bad code, not a lot of people thinking harder. As someone who’s in the guidance business I think a lot about how to give guidance that helps the majority of people write better code and makes them grow to be better developers along the way.

To me this seems like the top 20% of the development community runs the risk of promoting the adoption of languages that a sizable proportion of the remaining 70% will struggle with today. Tooling may help here but it’s not there yet.

I’m not knocking the 20% here. They’re the ones driving the industry and figuring out how to do what we do better than we did yesterday. They’re the ones spending their free time talking about how we can do things better. ALT.NET is full of people like this. But leaders need to remember that those who follow may not be as able at they.

I’m installing Ruby in background while writing this post. Time to play with something new!

* I wrote a lot of Perl 5 way back when I was building large web applications. I was using many of the advanced language features of Perl and it was pretty easy to tie yourself in knots and it didn’t take a million lines of code to do it. Perl’s syntax suffers from being “write only” even the author can’t read the code a few weeks/months later. Most of the Perl I wrote was written in emacs. I had the same experience using JavaScript a few years back, this time it was less the language, which I still wasn’t wild about, that dragged me down. Now the tooling and runtime environment (browser DOM) seemed like a less productive environment than using VS and the .NET framework, which was the alternative for me at the time.