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?
Why Rely On A Compiler When You Have Tests?
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.
My First Anniversary at Thoughtworks
For the usual readers, you might have noticed I tend to avoid mentioning employers because my blog entries are solely of my own opinions, and any associations or agreements are purely coincidental. Today is a little bit different (in that I will mention my employer) because this is my first anniversary with my current employer, Thoughtworks.
A little bit about my background. 2005 is my fourth year of being a professional software developer, working my way up from apprentice to journeyman, on towards being a master craftsman. I spent my first two years working for Oracle where my fantastic manager gave me the freedom and challenges to grow out of the all important attitude-shaping years of being a graduate. After working with some agile processes there, I continually stumbled across references to Thoughtworks (all in good contexts) and ended up applying for a job. A few (six) months later, the recruitment process ended and here I am today, one year on as a Consultant working out of their Brisbane office.
I realise that my experiences in consulting have been shaped by the nature of Thoughtworks’ Brisbane office and the commercial landscape of Brisbane itself. Despite initial expectations of projects that last between 3-6 months and involve potentially lots of travel (which I don’t really mind in this stage of my life), it so happens that I have been on the same project since first joining and what travel I did do last year was mainly around my own holidays. I’ve been lucky enough to work on a project involving a larger number of Thoughtworkers, though not as many as I imagine I could have, had I been working out of the Sydney or Melbourne office (something I, as well as many other TWers would like to do).
The project itself has been pretty good, both from a technical perspective and an agile process perspective. It has become ever better this year, with the team having more self-empowerment and ability to manage itself. Last year the project had been heavily based on a single person’s interpretation of “agile” and unfortunately almost all input team members gave from both technical and process standpoints were always overridden (an anti-pattern I highly recommend any budding benevolent dictator avoid implementing if you want to build successful self-empowered teams). Agile is great, but I would love other opportunities to experience other projects to see other people’s interpretation and application of it.
I have been here for three internal conferences, where everyone in TW Oz gets together and I find these amazingly refreshing. Besides meeting everyone else in TW Australia (something we rarely get to do), hearing everyone’s passions for different things has helped me challenge myself and grow professionally this last year. I’ve learned so much about lightweight processes, technologies and strategies from the conversations and exchanges I’ve had with other TWers. I even presented (with the great help of Andy) at our last internal conference and despite being accepted into the Agile India conference, had to pull out due to some poor internal timing issues.
I was bit worried by my age when I first joined, calculating that I would have been the youngest member of our Australia office by at least a few years (not now that we have grads though!). Thankfully everyone is treated is the same regardless of age, and everyone can converse with anyone with the same level of passion or argue with the same level of heat. I do wish that there was a bit more of a structure in place, especially for younger people, to provide a little more guidance/advice, because although I can see where other people are in their careers after years in the industry, it takes me a while to work out how they got there, and work out what else I can do to expedite my journey to being a master craftsman. I find that it is sometimes good to have challenges set by other people as well to build upon your own goals and provide opportunities to outreach what grasp you think you may have.
Consulting (especially on-site consulting) is different from traditional software development. The hours are certainly not as flexible as traditional product development, and on top of the hours you do on site being billable, there are many more that eat into your own personal time, doing the things that have to be done. Besides administrative time and definitely worthwhile time catching up with other TWers, the slack time that many other development shops probably have too much of, ends up being absorbed by consultants in their own time (but we’re lucky we’re so passionate about the things we do).
Being onsite all the time, especially for such a long time certainly affects your own working attitude. I know a lot of the things that came out of my review last year was the end result of maintaining the balance between being passionate about your beliefs, arguing over and defending differences in opinions, delivering business value, growing good working relationships with the team, all while trying to maintain the “professional demeanour” expected of consultants. It’s hard to know how you’re doing with such little feedback and advice, and ever harder to do it better without this continuous loop. Asking for help and advice is the one thing I am trying to do more of, so that I can become better at what I do.
So the good: meeting and working with brilliant people, being continuously challenged, growing significantly from a professional perspective. The could be (and maybe even soon to be) improved: being a single-project consultant, lack of travel opportunities, and more feedback.
The Importance of Grammar in Software Development
Last year, I was reading a number of booking about language structure and grammar, in an attempt to address, what I consider, a deficiency in the Queensland Education system and a further pursuit of my own interest in linguistics. I highly recommend avoiding these types of books unless you are really (really!) interested in the area because most of them tend to be quite boring.
The reward of finishing these, rather dull, books is the discovery of a few interesting facts about languages. The most interesting (ok, ok, bear with me) and relevant one I found is the topological classification of the English language according to sentence composition. In this category of languages (English, German, Chinese), a majority of sentences are composed using the Subject-Verb-Object (SVO) predicate (e.g. John walked the dog). In contrast, the Japanese language uses SOV (As for John, The Dog He Walked), and Yoda used OSV (The dog, John walked).
I suppose my interest in this area is its relevance to my ability of writing clearer code that communicates better intent. One of the touted benefits of Object Oriented Programming (OOP) is its easy mapping to the natural description and interactions between real world things, and our ability to express code our ideas closer to the language we use everyday (for me, English). I’m convinced that if I learn how to write better (learn how to structure proper sentences, apply proper terms, etc) even in basic articles or entries on this blog, then I should have also improved my ability at working out code that communicates more.
Take these two simplistic (and not necessarily ideal) blocks of code:
// Block A<br />public void triggerSpecialNotification(ExecutionResult resultOfExecution) {<br /> if (ALERT_CODE.equals(resultOfExecution.getCode())) {<br /> dispatchAlarmNotification(resultOfExecution);<br /> }<br />}<br />// Block B<br />public void triggerSpecialNotification(ExecutionResult resultOfExecution) {<br /> if (resultOfExecution.getCode().equals(ALERT_CODE)) {<br /> dispatchAlarmNotification(resultOfExecution);<br /> } <br />}
Based on the proper SVO paradigm, although Block B is more susceptible to NullPointerExceptions (and probably why Block A is typically written), Block B is consistently more readable because the resultOfExecution is maintained as the subject for the entire method.
Maybe here is a better example (I’m still floundering to find a good one):
// BLOCK A<br />public void doSomeWorkAndTriggerNotifications() {<br /> ...<br /> ExecutionResult resultOfExecution = runCommand(someCommandObject);<br /> someMessagingService.triggerSpecialNotifications(resultOfExecution);<br /> ...<br />} <br />// BLOCK B<br />public void doSomeWorkAndTriggerNotifications () {<br /> ...<br /> ExecutionResult resultOfExecution = someCommandObject.run();<br /> resultOfExecution.triggerSpecialNotificationsVia(someMessagingService);<br /> ...<br />}
Although the end result is something that could be achieved via a number of other xDD (x Driven Design/Development) approaches, I think this focus on grammatically correctness may help some improve the readability and design of their own code. In fact, it’s almost as if there is an opportunity to build a design tool reviewing code based on standard grammar correctness based on an a given vocabulary (domain specific nouns, verbs and adjectives perhaps described through annotations?). My ideas are still pretty raw, but maybe it has potential…
Making Privates Public
Disclaimer: This code is not for the faint-hearted and should not be used without very good reason (in our case, an external library not giving us access to a fair property of a certain class). Tested only on Java 5.
public static Object getPrivateFieldValue(Object anObject, String fieldName)<br /> throws NoSuchFieldException, IllegalAccessException {<br /> Class theObjectClass = anObject.getClass();<br /> Field field = theObjectClass.getDeclaredField(fieldName);<br /> field.setAccessible(true); // make it available outside of class or package<br /> return field.get(anObject);<br />}
Sometimes it’s scary how it can be just that easy…
Test For The User
I enjoy Test Driven Development (TDD) for the value it brings out in both my professional attitude (affirmation that tests are important) and my code (driving out design ideas and forcing the code to be easier and faster to unit test). There are times where I get frustrated at not being able to write code as fast I as want (and believe me, typing speed is not the issue – perhaps it’s Java’s verboseness?), and you get lost in all the syntactic aspects of the programming language, thinking about proper class responsibility, maintaining consistency throughout the entire application, and trying to improve upon what is there.
I have witnessed it far too frequently (and also sometimes succumb to) the comfort provided when all tests pass, with a natural conclusion being that all things in our application are perfect. Sometimes I make the mistake of assuming that other parts of the system are just as well tested, and have not changed beneath my feet.
Though there are many (yes, unfortunately not all) of us who believe that the tests we write and automate are important, let us never forget the ultimate acceptance tests for the system we write that our end users may (or may not) give us… their happiness.
Not So Agile Operations
The last two weeks have been rather chaotic with the introduction of a whole set of new environments (one for User Acceptance testing, one for Performance testing, and one for our new Oracle database). We’ve had a number of issues moving to each of these environments, highlighted by both our own set of test suites and by our testing team.
Although all the new environments were supposed to be replicas of production, there were still many not-so-subtle and definitely unintentional and unnecessary differences (such as basic Oracle configuration of the NLS_DATE_FORMAT and NLS_TIMESTAMP_FORMAT values). Working with my, it-doesn’t-work-until-it’s-proven (with a test) attitude, has now lead to a whole new suite of “Environment Acceptance” tests that we can now run against each of these environments to further narrow our scope of debugging to just our code.
It is of great relief to have feedback should these things go awry again, but I’m now concerned that a whole other part of IT (operations management including people like systems and database administrators) may be lacking the discipline (or is it the awareness and importance?) of continuous integration and testing.
Reviewing the weeks just gone
The last two weeks have just flown by with so much happening that I really haven’t had a chance to update the blog. Last week we were fortunate enough to have Martin Fowler (known best for his collection of books such as Refactoring, UML Distilled, and Patterns of Enterprise Application Architecture) down under participating in a number of conference/seminar events. Since I work for the same company he works in, we were even more fortunate when he found space in his busy schedule to spend time with us at a client site on one of our projects. I definitely took advantage of the numerous opportunities to dine and chat with the man, enjoying the time we spent discussing a wide variety of topics.
I also returned to Aikido for the first time since my accident, training with caution so that I avoided aggravating my leg. Upon entering the dojo, I was reminded of its great community spirit when everyone showed their concern by asking where I’d been for the last month. Last week also marked the last day of employment for another mate, Aaron (AKA DJ Anarchy) at my old workplace, which, of course, demanded some sort of celebration late into Thursday night/Friday morning.
Last Friday then saw to the start of my employer’s first “Team Hug” events for 2005. My company creates these conference-like events so that everyone in the country can share their experiences and knowledge with each other. For us working in Brisbane, it is also one of the rare occasions where we actually get to meet all of our fellow employees down south in person. Saturday is reserved for the internal conference (which I’m told tends to be much better in content and format than most other conferences) whilst Sunday is seen as the chance to relax, and get to know everyone else in a much more social atmosphere. This Team Hug was held at the Australia Noosa Lakes Resort and was a perfect location to do work related stuff without feeling like it was work related stuff. It was also my first time to present at one of these events, and despite the nerves, felt like it was well-received. Thanks to Andy for pairing with me on the entire presentation.
This week I was invited (thanks Michael and Sarah) to a pre-release screening of the movie, Ong Bak. Although it’s not going to win any academy awards, as far as action and martial arts films go, this is definitely one to go and see. I never released some of the things that you could pull off with Muay Thai kickboxing and the star of this movie manages to demonstrate them all. Although the storyline is not going to make you think very hard, the fairly decent length (for an action movie)is filled with enough humour, drama and lots and lots of action to keep you entertained throughout.