thekua.com@rest

Even though this week has been mainly about training for the Aikido grading this weekend, it was nice to have an excuse to have a night out and celebrate Ajit’s birthday. Dinner was scheduled for the eight of us out to celebrate at the Belgium Beer Cafe. As I finish work early, it gave me a good opportunity to cruise into town and relax, so after picking up my favourite mags from Rockinghorse (Rave, Scene and Time Off), I headed to Pane e Vino to put my feet up for a bit of reading.

Service was excellent at both places for the evening (despite the Belgium Beer Cafe neglecting to note down the booking I had made the previous night) and the night was finished with a viewing (yes, finally!) of Star Wars Episode 3: Revenge of the Sith. Although I had missed my last bus by an hour when coming out of the movie, the night was topped off when I grabbed a taxi and I was offered a bargain-priced fare because it was a quiet night! Sweet! And now for some sleep…

Comments(3)

Every project is influenced by a number of forces that make it less than ideal. Sometimes these forces can be business decisions that create a rate of change faster than a development team can meet with perfection, other times it is technical limitations that prevent ideal solutions from being implemented, and sometimes it is simply the misappropriate application of tools and libraries that can’t fit all of the needs of the business.

Regardless of the source of these forces, anything that has a significant impact on a team delivering perfect software is worthy of documenting. Identifying and clarifying such influential forces provides newcomers with a better context to the decisions that a team might have made along the way, and better yet, provide a way of highlighting them and their undesirable effects, so they could be removed if they no longer apply.

When it comes to the technical forces affecting the level of code being produced (e.g. a library not behaving accordingly, or an unforgiving production environment), the best way that these forces should be documented is in the form of tests. Developers would not be expected to run these, and should be left for execution by a build machine running in a production-like environment. Continuous integration serves as a great mechanism to inform us when the undesirable conditions that forced the creation of less-than-perfect-code, goes away, and highlights what can be changed to bring it that much closer to perfection.

Comments(0)

After yesterday’s amazing hail storm: (Disclaimer: It’s not me in the picture…)

Comments(4)

Bar the Foo, no one really cares about you.

I like good names for all things, even for test variables, even though you may not care what value they have. However, even if you don’t care what value it has, please think about people who will maintain it and tell them (by giving it a good name) what it supposed to represent (how about something like anyName, or anyEmail?).

Comments(3)

Our last iteration introduced full time pair programming as an accepted practice (in contrast with our previous practice of “pairing”). The last couple of days I’ve been pair programming with one of client’s developers and because we seem to work well together, it hasn’t been hard to all building the synergy. As part of pair programming, I suggested we give pair pong programming a go and despite it being a new practice, we’ve found it excels at providing us with the rhythm that makes us amazingly productive.

I think there are a couple of reasons why pair pong programming works. Firstly, it’s got all the aspects of pair programming (such as constantly discussing design, questioning and trying to improve on the code that is written). As I mentioned earlier, it’s got the rhythm of proper TDD (writing a failing test, and then getting that test to pass) and finally it’s really good for actually forcing pairs to drive and navigate for an evenly distributed time. I think we’ve almost got to the point where when we write the test for each other, the other pair already understands what it would take to implement it and then the code just flows.

With the right partner, pair pong programming can be such bliss…

Comments(1)

Last year’s Splendour in the Grass was amazing. This year’s one includes acts such as Queens of the Stone Age, Moby, Interpol, The Finn Brothers, The Living End, Shihad, and Sarah Blasko. Despite tickets for this year only going on sale yesterday, it appears that they have already sold out! Such disappointment! It’s also amazing to see that people are already ebaying them for almost double the price!

Comments(0)

On our current project full pair programming has been more of the exception than the rule. In our current iteration we are trying full pair programming and we’ve seen some really good things come of it. I was thinking of writing up some entries here for Pair Programming Patterns/Anti-Patterns because it would be good for future reference but maybe there is some resource out there already. Does anyone know of such a resource and would it be worth writing some up?

Comments(3)

I’ve been playing around with Ruby and reading up on Ruby on Rails lately (yes, I have joined the bandwagon) and it interests me how Ruby’s popularity (at least in some of the circles I partake in) seems to have resparked the debate of dynamic languages being better than static languages. Static language advocates will suggest that they have frequently less bugs in the class of wrongly assigned data types because the compiler provides them with one level of feedback. Of course this does not mean that static languages (such as Java) exclude this class of bug completely (which is why we have our most favourite ClassCastException). This level of feedback comes at the cost of its programmers having to endure a much higher level of verbosity.

Although I code everyday in a static language for my current project, I’ve written some development tools and worked on a project all based in Perl (gasp!) and enjoyed the freedom its dynamic typing provided. My suggestion for people looking at using dynamic languages for a production system is that the higher level of power that the language provides also requires a corresponding higher level of discipline from developers who use it.

My response to people who strongly advocate for static languages solely based on its type safety is that this issue goes away if one actually writes tests for it (and even better, test drives the entire system). It amuses me to no end to see how many projects (both production and even many open source projects) fail to even compile when you take a copy from their source control system. Although seeing a project fail to compile gives me one level of feedback (yes, you won’t even be able to run it), I think it’s bad that when you do see a project compile successfully, it gives people a false sense that the system must be working correctly. Yes this requires high discipline from developers to write useful unit tests but is this any different from what you are currently doing or what you expect your team to be doing? I really hope not.

Comments(1)