Interview with Dave Thomas on Agile

I found a really good podcast called The Agile Toolkit Podcast, in which the host, Bob Payne, attends agile conferences and interviews people there. Some of the interviews include people like Bob Martin and Mary Poppendieck among many others.

The most interesting show I’ve listened to so far is an interview with Dave Thomas (of Pragmatic Programmer fame) about agile development.

For me, I think I found it interesting just in the fact that it is nice to hear someone that has the same views on development issues as I do. I’ve always been a big believer that methodologies are limiting and that each methodology should be tailored to the project team. One part of the conversation that I found extremely interesting was when Bob and Dave were talking about the dogma attached to many of the methodologies.

Recently I had attended an Agile Development training in which the instructor stated that if you weren’t using all of the components of XP, you weren’t doing Agile development. A good point that Dave made was that as XP was being developed, the teams it was being developed with actually evolved into using all of the practices at different stages of their team development. In other words, they didn’t start using all of the practices specified in XP – because they didn’t exist yet. Dave makes the point that teams need to evolve into all of the practices – and that its very difficult to implement all of them at one time. I actually think that each team will be sufficiently different enough that you may not need all of the practices, but only a core set of practices. Bob Martin also makes this point in his interview and lists the minimum set of practices that include very short cycles, an open office (a room which holds the identity of the project), test driven development (both unit and acceptance tests). He also mentions that its extremely difficult to do test driven development without continuous integration, so there are other practices that will be necessary as you begin to implement the minimum set. I actually believe that source control and automated builds are another of the core minimum practices that should be put in place before anything else – but thats just me.

Another area that Bob and Dave talk about extensively is the necessity of developers to look at other languages in the industry other than the core language they use day to day. One statement Dave makes is that he looks forward to the day that developers refer to themselves as “developers” rather than “Java developers”. I wholeheartedly look forward to that day as well.

I’ve always enjoyed learning new languages. If you run through the articles in this blog, you’ll see that every time I find some language that I don’t know – and understand the practical reasons why they exist, the chances are I start working in it right away (most recently, this language is Objective-C). I enjoyed this part of the conversation a lot, because Dave articulates very well how learning new languages can give you new insights as to how to implement things in different ways.

I’m a firm believer that in software development, you have to have a pretty large tool box. The right tool should be used for the right job. This is why in many of the things I’ve done over the years, different components are written in different languages depending on what I am doing. A web piece might be written in PHP, scripts done in PERL or Python, while other components could be written in C / C++. I’ve made a conscious effort over the years to expose myself to as many different languages as possible.

In order to have the flexibility to use the right tool for the right job, you really have to make an effort to get at least a high level understanding of the different tools available and what their strengths are. Thats the really nice thing about the conversation with Dave is that he articulates the idea that you don’t necessarily have to be an expert in all languages, but know enough to use them and glean knowledge from them and their design.

I have found each of the shows I’ve listened to from the Agile Toolkit Podcast very informative and totally worth the time investment. In the very least, I want my teams to make this a part of their learning program moving forward. There’s no better place to learn about Agile practices than from the people right in the middle of it.

New Things To Learn!

Learning Objective C

One of the really nice things about switching platforms is the plethora of new things one now has the capability to learn that you might not have found a reason to learn before.

I’m a stickler on having something practical to do when learning something. If I don’t have a real thing to shoot for when learning a language, its pretty much a guarantee that I won’t be able to learn it.

The conversion to the Mac platform, the availability of the development tools through the Apple Developer site, and some time spent reading iCon Steve Jobs: The Greatest Second Act in the History of Business has given me a lot of motivation to dig down and learn Objective C.

Free tools have been around for Objective C programming for quite a long time. The GCC compiler has supported Objective C as far back as I could remember. But frankly, I saw no reason to learn it when I had all of these scripting languages available and most of my Unix work has been either web based, or command line driven tools.

However, the last three or four weeks sitting with the Mac and working within the Mac UI has gotten my curiousity peaked on this odd little language that really gets no visibility until a few guys from NeXT choose it as the basis of their development tools. I really want first hand experience to understand why the guys at NeXT chose this language as the basis of their platform.

Now, I’ve done a lot of C and C++ programming in the past, so one might think that learning Objective C would be no big deal. I have to tell you, I’m struggling a bit. One thing I do think is pretty cool is the dynamic nature of the language. To me, it seems very Python / Ruby – ish in that respect. However, its a lot to learn and I’m really going to have to spend some quality time with some books to get familiar with the concepts. Its very different than C++.

I’ve got three books on order from Amazon: Programming in Objective-C, Learning Cocoa with Objective-C, 2nd Edition, and Building Cocoa Applications : A Step by Step Guide. Unfortunately, I received #2 before #1, and #1 is definitely the book I need first.

I think its pretty cool that I have the excuse to learn something completely different. The past four weeks on a new platform has been interesting to me. Its really like starting all over again with a whole new world available to me — which is what attracted me to this field in the first place.

Objective C Resources

List of Languages I have coded in …

Tom the Architect’s latest posting details a list of languages he has coded in. I thought this would be a pretty interesting exercise, so thought I would throw one together as well:

  1. BASIC (quite a few flavors from old school CP/M up to Windows)
  2. xBase
  3. DataFlex
  4. C
  5. C++
  6. x86 Assembler (light, but still counting it)
  7. Pascal (Turbo / Quick)
  8. Unix Shell (BASH. KSH, etc)
  9. Java
  10. JavaScript (light, but I think it still counts)
  11. Perl
  12. Python
  13. PHP
  14. Ruby

You know what? That wasn’t a very interesting exercise. Thanks a lot Tom …

Ruby on Rails – WOW

Over the last couple of weeks I decided to re-familiarize myself with the Ruby programming language. I was first introduced to it back in 2002-2003 at OOPSLA (or was it the Software Development Conference?) when I took a full day workshop with the Pragmatic Programmers, Dave Thomas and Andy Hunt.

Back then I loved the language, but decided not to focus on it since the support in the form of libraries just weren’t there like they were for Python at the time. I wrote a few programs in Ruby, but left it to the side and focused on Python.

Well, those days are over. When I started with Ruby, I decided to take a look at Ruby on Rails as well. Over the last couple of weeks all of my spare time has been focused on learning the Ruby language and this completely awesome framework, even at the expense of regular podcasts.

First off, I’m absolutely enamoured by the language. So much so that with Rails piled onto it I couldn’t imagine programming in any other language. For quite a while I’ve hated Java and the complexity that it brings to projects. There’s just too much work involved in doing Java development anymore.

Ruby combines complete object orientation with the flexibility of a scripting language. Some of the features it has baked into it, such as iterators and blocks make life so much easier.

Now pile Rails on top of it. Rails is an elegant MVC framework written in the Ruby Language by the folks over at 37 signals. These two things combined make for the perfect programming environment for web applications.

I’m still on the steep end of the learning curve. I’ve got the Programming Ruby : The Pragmatic Programmers’ Guide and Agile Web Development with Rails : A Pragmatic Guide (The Facets of Ruby Series) constantly at my side as I pull my hair out trying to learn all of this stuff.

But the cool thing is, even with my unfamiliarity with the language I’m still productive. If that isn’t the sign of a great development environment, I don’t know what is.

I’m working diligently to become proficient in the language. Rails is a little complex and I’m still struggling to learn all of the conventions. However, I think most of my programming moving forward will be with these tools. Its just a lot easier to spend time thinking about the problems you are trying to solve and being able to express them eloquently rather than struggling with the complexity and code/compile/run process baked into Java development.

What Corporate Projects Should Learn from Open Source

Aside

OnLamp had an excellent article yesterday called What Corporate Projects Should Learn from Open Source. The articles pretty long, but well worth the read. While there are obvious differences in the two types of projects (like budgets and deadlines), I still believe that corporations can move closer to the OSS model of development and get major productivity increases.

Build Google and Yahoo Maps Without Coding

I stumbled across MapBuilder as I was browsing the Google Code site today. MapBuilder was referenced as one of the sites featured projects. The application is pretty interesting, allowing you to visually create a map using either the Yahoo Maps or Google Maps API and then to export the source code for inclusion on your web site. There is also an option to host your maps directly on MapBuilder and reference them from your site with a button that links to a list of all of your available maps.

There are quite a few things that are really cool about the site:

  1. Supports both Yahoo! Maps and Google Maps.
  2. No need to learn the details of the mapping API’s – just create your maps and go.
  3. MapBuilder does geo-coding, using the Yahoo! Geocode API’sand geocoder.us while Google Map API’s require lattitude and longitude in order to do anything with them.
  4. MapBuilder does the “driving directions to / from here” for you. No need to create custom code for this functionality.
  5. MapBuilder will also do custom development for you if you want something different from what the basic services provide. I’m assuming there is a fee involved, but I couldn’t find reference to it.
  6. The site facilitates building communities around maps that people create on the site.
  7. Best of all, it allows the “common man” to include mapping capabilities on their web sites without having to know how to code in Javascript and HTML.

MapBuilder is a really good example of new, unintended possibilities that are exposed when web applications are designed as a set of API’s using the web as a development platform rather than the siloed approach that we have used historically. This application was written by a third party not affiliated at all with Google or Yahoo!, but because of the way their applications were written they have the possibility of an audience that they did not originally target by allowing someone to build applications around their base functionality.

One should note that creation of a user account is required in order to use the full functionality of the MapBuilder site. They basically ask you for a username, password, and your email address. Thats it. Registration for either a Google Maps API key or Yahoo! Maps API key is also required if you would like to host your map on your own web site rather than hosting it on MapBuilder directly.