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!
In this episode, we interview O.J. Reeves about going it alone with his company, Functional IO, Erlang and functional programming in general. There's also another chance to win one of Mike Beale's CDs so listen carefully!
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. (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.
Six Degrees (formerly Coding By Numbers) podcasts are licenced under the Creative Commons Attribution licence. This allows you to distribute, remix and build upon a work, even commercially, as long as you credit us.