Friday, 31 December 2010

Coding By Numbers - Episode 19 (End Of Year Wrap Up)

In this episode, Steve and Craig talk about the events of 2010, and ponder what is to come in 2011.

Merry Christmas and Happy New Year!

Download links:

Thursday, 25 November 2010

Coding By Numbers - Episode 18 (The role of automated testing)

In this episode, Craig talks to Andrew Newman and Richard Westwell from Suncorp about the role automated testing should play in software development teams.

Download links:

Monday, 22 November 2010

Fiddling with the feed!

Thank you to all those who have given us feedback on the podcast, please keep it coming!

A number of you have asked about an MP3 version of the show. From now on we're making the show available in MP3 and Ogg Vorbis formats, as well as the existing AAC (.m4a). We're also switching the default file format contained within the feed from AAC to MP3 which is compatible with a wider range of devices.

We will also be putting direct links to each of the files into the show notes. I've been through and done this for the previous shows from episode 12 onwards, and I'll get to the previous episodes over the next week or so!

Sunday, 14 November 2010

Coding By Numbers - Episode 17 (Interview with OJ Reeves)

In this episode, we interview O.J. Reeves about going it alone with his company, Functional IOErlang and functional programming in general. There's also another chance to win one of Mike Beale's CDs so listen carefully!

Download links:

Thursday, 11 November 2010

Paul King interviews J.B. Rainsberger!

Now there's a headline I didn't expect to write when we started Coding By Numbers :-)

Paul King recently interviewed J.B. Rainsberger about the "Simple Approach to Modular Design" and "Solve Just Enough Of Your Worst Problem" workshops he will be running at the YOW! conference in Brisbane and he was kind enough to let us publish it here.

If you like what you read, be sure to check out the conference on the 6-7th December and the workshops on the 8-9th December. The conference and workshops are also in Melbourne from November 30th through December 2nd. Enjoy!

Paul: I have read about Robert Martin's SOLID principles for good OO design. Will you be discussing those principles or are there other things we should be discussing?

JB: I will discuss SOLID, Bertrand Meyer's principles, Larry Constantine's principles of coupling and cohesion and some other principles I've named for myself. Through a decade of practice, I have seen how to reduce all these bewildering ideas to the rules of simple design that Kent Beck taught us, and at that, I even go further to simplify his rules. The result is an almost unbelievably simple approach to learning how to design well, meaning mostly how to reduce the number of unpleasant surprises when you go back to add feaures to an existing code base. I truly believe that, with enough mindful practice, anyone can become an excellent designer using these techniques.

Paul: There has been a lot of interest in functional programming lately. Should we all be changing to functional programming?

JB: I don't think we should, although I have noticed that as I practise TDD more, my style of programming leans towards the functional. In particular, one needs to consider functions as first-class types to notice, and then remove, certain types of duplication. What I don't yet see is how the move towards functional design might obviate the need for things like aspects. Seeing as I find aspects useful, but no-one ever uses them, I hope that functional programming offers a similar expressive power so that aspects can die a graceful, silent death.

Paul: I can see TDD being useful when writing small bits of code but when creating large systems and working on integration projects, would I still consider it as a useful technique?

JB: Without question. I use TDD as a technique to teach and learn modular design principles, and I don't believe there can exist a large, modular system, but rather only a large network of loosely coupled, highly cohesive modules. Through TDD I have learned, and can teach, how to create highly modular designs that scale indefinitely and don't suffer the typical pains of large systems. As for small bits of code, I wouldn't TDD that any longer: if it's small enough to throw away and rewrite, then there's no need to do it correctly, and TDD wouldn't help. Using TDD on small bits of code provides tremendous practice, but at some point one realises that TDD helps most when a code base just reaches the verge of starting to spiral out of control.

Paul: What are the strengths and weaknesses of unit, integration and acceptance tests?

JB: I find acceptance tests do a fantastic job of helping us clarify our understanding of a feature, but when teams attempt to test systems exhaustively this way, they find those tests become costly both to run and to maintain within a few short months.

JB: I find integrated tests helpful in highlighting (but not finding) mistakes in the system, but they make it too easy to allow unhealthy dependencies between modules to flourish.

JB: I find unit tests, specifically focused object tests, put fantastic positive pressure on my designs, and encourage me to keep dependencies loose, but without collaboration and contract tests, they can lead one to a false sense of security about the soundness of the system, and, of course, unit tests typically won't uncover system-wide problems.

Paul: There has been a lot of interest in parallel programming lately. Do you think our fundamental programming practices are going to change at some point as concurrency comes into the mainstream?

JB: I do. I'm quite a novice at parallel programming, having not done any since university, but I do know that attempting to take advantage of multiple cores to partition work will put even more positive pressure on our designs to become stateless, and I imagine that will shatter the object-oriented approach to pieces.

Paul: Some people claim that agile means that you don't need to do much design. Is that true?

JB: Certainly not. Evolutionary design, the central agile programming discipline, encourages amortising the design work over the entire project, deferring design decisions until we absolutely need to make them. Even so, we will always have irreversible -- or costly-to-reverse -- decisions to make in any project, and while evolutionary designs helps us challenge our assumptions about which decisions we must make now, it doesn't eliminate the need to make some key decisions early. It teaches us that we probably don't have to make as many up-front decisions as we think.

Paul: What is the difference between Agile and Lean? Don't they mean essentially the same thing?

JB: I don't know what the average person thinks about this. When I first read the Poppendiecks' first Lean book, I recognised it as a theoretical basis for Agile. Now I don't think I can tell the difference between Lean Software Developmet and Agile Software Development.

Paul: If there was one guiding principle  you would give to organisations to reduce waste, what would that be?

JB: Don't automate what you can eliminate. I learned that from Tim Ferriss' Four-Hour Work Week and it works wonders.

Paul: I noticed you mentioned the theory of constraints in one of your talks. Can you explain that? Is it related to Systems Thinking?

JB: I suppose one could consider Theory of Constraints a kind of school of Systems Thinking, but I'd never considered that before. Certainly, they have one thing in common: they caution against optimising small parts of the system.

Paul: I have been involved in Agile in Brisbane for quite some time. I know some projects that still haven't really taken on board many agile practices. I also know others that have taken on board many of the practices but are still struggling making them all work together or are struggling to retain the fun and productivity when applying all these practices. And of course there are plenty of people in between as well. Will there be things to learn from your talks for all these groups, i.e. beginners, average and advanced agilists?

JB: Both sessions focus on ways to learn how to do good work, rather than ways to do the work itself. In that sense, everyone can benefit. More specifically, however, there's something for everyone in each of these sessions.

JB: In A Simple Approach to Modular Design, beginners will learn how to do TDD, intermediate practitioners will learn or re-learn some key design principles and advanced agilists will learn a new model for teaching and learning how to design well. In Solve Just Enough of Your Worst Problem, beginners will learn how to map value streams, intermediate pracitioners will be reminded that understanding problems matters more than practising solutions, and advanced agilists will see how by understanding the problem deeply one knows exactly which portion of it to solve, how much of it to solve, and which solutions to apply. 

Paul King leads ASERT, an organization based in Brisbane, Australia which provides software development, training and mentoring services to customers wanting to embrace new technologies, harness best practices and innovate. He has been contributing to open source projects for nearly 20 years and is an active committer on numerous projects including Groovy, and is a co-author of Manning's best-seller: Groovy in Action.

☕ J. B. RainsbergerJ. B. (Joe) Rainsberger is a Canadian software development consultant and technology writer, best known for his contributions to agile development, for which he was awarded the highest honor from the agile community, the Gordon Pask Award in 2005 (its first year of existence). He is the founder of XPDay North America. He is also well known for his book, JUnit Recipes : Practical Methods for Programmer Testing.


Friday, 29 October 2010

Wednesday, 15 September 2010

Monday, 6 September 2010

Coding By Numbers - Episode 6 (Interview with Tom Hanrahan at TechEd Australia 2010)

In this episode, recorded at Microsoft TechEd Australia 2010, we interview the Director of Open Source Technology Center, Tom Hanrahan.


Wednesday, 28 July 2010

Coding by Numbers - Episode 4 (Platforms)

In this episode, Steve and I are joined by guest host, Andrew Newman, to discuss development and target platforms. Unfortunately we lost the first 20 minutes due to human error (i.e. I didn't do a mic level check first), but the rest of the content is good!

Desktop Platforms
Mobile Platforms
Picks of the week

Tuesday, 8 June 2010

Coding By Numbers - Episode 2 (Agile Fishbowl from Barcamp Brisbane)

This episode was recorded at the recent Barcamp Brisbane on June 5th 2010 at Queensland University of Technology.

It's a fishbowl session with the topic "Is Agile A Cargo Cult"?

A big thank you to all the speakers:
  • Rob Manthey
  • Paul O'Keeffe
  • Nathan Hoad
  • Pete Leong
  • Paul King
  • Steve Dalton
  • Craig Aspinall
Thanks to Bruce Morrison for the photo

Thursday, 3 June 2010

Coding By Numbers - Episode 1

We had some problems with the audio in this episode, we were trying a different setup and picked up an echo part way through. We've tried to fix it up as best as we could in post production, but in the future we'll just stick to the mantra "If it aint broke, don't fix it!".

IntrosGoogle IOQuitting FacebookUnconferencesPicks of the week

Wednesday, 19 May 2010

What's going on? YAP (Yet Another Podcast)!

For those of you who might have been following this blog before, you might be wondering what's going on? A friend and I have started a podcast and we wanted to call it "coding by numbers", partly because we couldn't think of anything better, and partly because I already had the domain ;-)

So I've hijacked the domain from myself to fulfill an ambition that I've had for some time. If you want to follow my personal blog, go to and subscribe there. You can also follow me on twitter, @aspinall.

Those of you that are interested in the podcast, read on...

I've wanted to record a podcast for a while but didn't want to do it alone, because I think one person talking would go stale very quickly. At the inaugural meeting of the Gold Coast JVM User Group, one of my friends said that he fancied having a go at it too. Unfortunately (or not) we lost the car after the meeting, and in the hour that it took us to find where we had parked it, we had thrashed out a plan!

So without further ado, I'd like to introduce my co-host, Steve Dalton from Refactor, who's currently working with myself at Suncorp. He's a Java developer, Groovy enthusiast, entrepreneur, eco-warrior and all round good guy! He works very hard organizing all kinds of meet ups in Brisbane and on the Gold Coast for the Java, Groovy and open source communities. And he talks a lot, which is handy for recording a podcast!

We're not sure how it's going to turn out but we're being very agile about it. We've recorded the pilot episode which we'll unleash on the world in the next week. The content will generally be technical in nature and we'll cover whatever takes our fancy from what's going on in the world, what we're working and what's bugging us. Hopefully it will be interesting and/or amusing to someone, some of the time!