Kane Mar

Adventures in Agile Software Development and Scrum

Two observations from attending JAOO in Brisbane

I had the opportunity to attend the JAOO conference in Brisbane the last few days. There were some really interesting talks and a lot of good discussions. I wanted to mention two points that were made at JAOO that have left me thinking, but first let me say a few words about the highlight of the event, for me. I loved Linda Rising’s two talks. I’ve never heard her speak before (although I’ve read her work) and, I can honestly say, her talks were fantastic. Both talks were funny, engaging and thought provoking. I won’t say anything further, suffice to say that I would recommend Linda if you every have an opportunity to hear her speak.

Now, back to the two observations that I had at JAOO.

The first occurred during Pamela Fox’s presentation on Google App Engine when she started talking about the limitations of BigTable. BigTable can’t do joins. This isn’t a problem if you’re building something new from scratch, but it’s a whole new world for companies that are entrenched in large relational databases. One of the questions from the audience left me thinking, “How would I migrate an enterprise scale application to Google App Engine?” I think the answer is quite clearly, “Not very easily.” Google App Engine and BigTable are entirely different beasts and are going to drive a whole new type of software architecture.

The next observation that I had was during Joshua Bloch’s keynote presentation about upcoming changes to Java. It was a good presentation and Joshua is a great, engaging speak.

In his keynote, he talked about Java generics. I won’t go into the details of Java generics because I don’t think it matters any more. Java generics is overly complex and confusing. This is a shame because it needn’t be that way. There are many languages where generics are simply accepted as part of the language without the need to call it out as a feature. When a language gets so overly complex that one spends more time trying to figure out the code than solving the problem, then it’s simply time to move on.

Java will still be around, much like COBOL and Fortran are still with us, but I believe, few and few systems of consequence will be built with Java.

Filed under: Agile Software Development, Technology , , , , , ,

Beyond Continuous Integration … Continuous Deployment at IMVU and a tale from Pirum

I’ve just finished reading an excellent article on Continuous Deployment. This is the way of the future. Now that Continuous Integration has become (almost) mainstream and as expectations for services to be “always on” becomes the norm, the interest and demand for practices such as Continuous Deployment (CD) will increase. With CD, the cost of rolling out an update is very nearly zero* because deployment and releasing is fully automated.

I first had a discussion about Continuous Deployment with Rupert Perry the CEO of Pirum Systems. Rupert is a first rate developer and wrote the first version of their systems with the CTO. While we were discussing some of the advantages of Continuous Deployment, Rupert told me a story. He was in a clients office trying to make a sale and was demonstrating the live system to the potential clients. The client wanted to sort by a particular column. Not having worked directly on that particular function, Rupert said “Let’s try it.”

The function failed … but here is where the story becomes interesting. The developers who were monitoring the system noticed the failed function. It wasn’t a lot of work on fix the problem, so they coded, tested and deployed a solution. Knowing that Rupert was seeing a client they gave him a call and asked him to demonstrate the function again, which he did successfully. The elapsed time for all this was in the order of 15 minutes to 20 minutes.

Oh, and Rupert made the sale!!

* It’s not quite zero because there’s a cost involved in initially building and configuring the CD system.

Filed under: Agile Software Development, Patterns, Technology, Web 2.0 , , , , , , , ,

The top five ways to survive Scrum

http://www.flickr.com/photos/randomurl/

Image by Zevotron: http://www.flickr.com/photos/randomurl/

Over the last few years we’ve seen the introduction of Agile software development into the mainstream. In 2006 the Agile Alliance are claimed that Agile frameworks had crossed the chasm. Frameworks such as Scrum have been seized upon by management and they are the ones who are now controlling the introduction of Agility.

The reasons for this are quite understandable. Management are simply looking for ways to improve how technology (and especially software) is created. And why shouldn’t they? As a profession we have been spectacular in our failures. We have deliver low quality code, at a cost that’s greater than what was promised, and we’ve delivered it late. We should expect there to be changes to this state of affairs.
Read the rest of this entry »

Filed under: Agile Software Development, Cultural Change, Organisation Change, Project Management, Scrum, Technology , , , , , ,

Introduction to Agile Engineering Practices

Last night, as part of our regular Seattle Scrum meeting, I presented a half hour introduction to Agile Engineering practices. I talked about the four big practices: Continuous Integration, Test Driven Development, Refactoring and Pair programming. It’s just a gentle overview that’s intended to introduce some of the ideas and concepts, and to provide a starting point from which to learn more.
Read the rest of this entry »

Filed under: Agile Software Development, TDD, Technology

“Eating one’s own dogfood” should not be an excuse for reduced quality

Personal Comment: I started this article about 5 months ago and it’s just been sitting in my queue. I’ve been undecided about publishing because I’m not especially fond of it. But rather than let the bits rot, I thought I’d share it in the hope that someone will get some benefit out of it. If you find this interesting or helpful please leave a comment. Thanks.

The concept of “dog fooding” your own products has been around for a long time, and has been made famous my Microsoft who are rumoured to practice “dog fooding” their products as a regular part of their culture. What is dog-fooding?
Read the rest of this entry »

Filed under: Agile Software Development, Patterns, Planning, Technology

Applying the Principle of Postponement to Software Architecture

This article is about my further understanding about Agile software development. As I my understanding of Agile software development has increased, so has the conflict between my established ideas and what I now see happening in the real world. The latest casualty was my belief that having repeated code or components is bad.

I was greatly influenced by Bertrand Meyer’s [1] book Object-Oriented Software Construction [2] where he presented the case of reusable software components. It could be argued that reusable components are with us now in the form of large frameworks, but my understanding of his vision (reuse of fine grain components) never fully came to pass.

The original impetus for this article was a conversation that I had with Ken Everett. He described the logging scenario that I use as the example for this story. His argument was that for a large team using more than one logging framework was not a bad thing provided that the code quality was good and that it met the business functionality. I absolutely agree. I also wondered, when was the latest responsible date at which point a decision needed to be made?
Read the rest of this entry »

Filed under: Patterns, Technology

“Competing on the basis of speed” by Mary Poppendiecks at Google TechTalk

Here’s another excellent Google TechTalk. This one is given by Mary Poppendieck, author of “Lean Software Development: An Agile Toolkit for Software Development Managers” and “Implementing Lean Software Development“.
Read the rest of this entry »

Filed under: Agile Software Development, Project Management, Scrum, Technology

Improving the Selenium include extension

Update: WordPress has altered how the code tags function, making this post very confusing and difficult to read. I’ve replace the code tags and so, even though it’s not pretty, it’s at least readable.

My current client is working with Selenium to automate their acceptance testing. Selenium is an open source tool javascript framework for testing web applications. From the OpenQA website [1]:

"Selenium uses a unique mechanism which allows it to run on multiple platforms. Installed with your application webserver, Selenium automatically deploys its JavaScript automation engine — the Browser Bot — to your browser when you point it at the Selenium install point on your webserver. Thus, you must have write access to the machine your web application server is running on to install Selenium."
-OpenQA.Org

Read the rest of this entry »

Filed under: Selenium, TDD, Technology, Test Driven Development

Share This Blog

Bookmark and Share

My Twitter Updates

Agile Carnival