The Art of Agile Development

Keep this book to hand

The Art of Agile Development was recommended to me by Jeff McKenna when he provided some Scrum coaching to those of us in the Dublin office working on Oracle Social CRM. Back then it was a new, hot off the press book, but I have recently reread it because I have found it useful in providing guidance on what to watch out for when changing agile development practices. This was necessary due to changes in teams and technologies as some of us focused full time on Fusion Applications. Practices, roles and responsibilities we had gotten used to had to be adapted or dropped to blend in with APM, Oracle Fusion Application’s development methodology.

The book, by Shane Warden and James Shore, is a great introduction to agile development methodologies by covering both XP and scrum. Practical examples are generally from XP projects because that is where the authors have the greatest experience. The authors identify a broad set of practices that would be considered as characteristics of agile development methodologies in way or another. Recognising that it is very rare in most organisations to be able to follow an agile methodology completely as prescribed alternatives are mentioned, but not in every case. Shane and James are also very clear that many of these practices are often taking place at the same time in a software project rather than in a sequential waterfall methodology. However, categorising practices by what sort of activity and the nature of the activity give a very useful matrix for teams to analyse how agile their own practices are and perhaps identify areas where realistic improvements can be made. Just being able to have a label or term for a specific practice makes discussing within a group easier.

Download poster from James Shore

I see the collection of practices being grouped by phases (planning, analysis, design & coding, testing, deployment) and verbs (thinking, collaborating, releasing, planning, developing). For example, when team members are working on implementing a specific feature that kind of collaboration is ‘design & coding collaborating’ and the section in the book covers some pair programming techniques. In fact, this particular section addresses the misconception that pair programming is a fulltime ‘paired for life’ regime. It is a useful tool that can be used for a few hours a day to make some significant progress, reduce interruptions, and spread the knowledge of how and why parts of the system being developed work.

Other useful techniques peppered through the book include the Agility Self Assessment and the many skill development routines, which the authors called ‘etudes’. These are short exercises that may help in getting the feel for a more agile approach. When reading the chapters you might be thinking we don’t have the development experience to let team members do organic, incremental architecture design, or implement thorough automated testing. I wonder how many people never complete the book because they do not believe they can carry out these changes and deliver software in a timely fashion. It’s not until towards the end of the book that the authors address the reality of the mixed capabilities of the team. If this was at the beginning it might give the readers more staying power. The book does have some helpful advice on working with and around the politics, the mixture in experience levels, and heavy weight project management within your organisation. It has to be read in it’s entirety though and does make for an excellent reference book to dip in and out of.

This article has been edited since it was first published.

Interface Oriented Design

This book has been sitting on my desk for a long time and I’ve been dipping in and out of it for at least a year. I’m a big fan of The Pragmatic Programmers and the topic of interface is very close to my heart as it is often the most ignored when system analysis and design occurs. Apart from performance, interfaces are generally the biggest problem that is faced when a system goes live because once people start to use it, they want to use it with the other systems and tools they are using. The human interface to a computer system gets, quite rightly, a lot of focus. The topic gets it’s own module in Computer Science degree courses. This has meant that today’s software developer is familiar with the concepts of usability, task analysis, workspace arrangement, error detection and recognition.

I was hoping that Ken Pugh’s Interface Oriented Design was going to be that seminal book which would set out design principles and approaches for deriving robust interfaces. It is not. While it does introduce some interesting concepts such as the Three Laws of Interfaces and Interface Responsibility Interaction it lacks a real world sense about it. In fact, the purpose of the book appears to be the platform to launch Pugh’s Interface Responsibility Interaction format. It’s an interesting idea, but unfortunately it does not make a strong case for using such a format in real projects. Some case studies from other projects where IRI was used would have been beneficial.

One gets the sense that this is a serialisation of some lectures within a system design module in college, with a trivial exercise to prove the points. Put simply, there’s really not much in the book to grab the experienced developers attention.

Oracle SOA Suite Developer’s Guide

Service-Oriented Architecture (SOA) is not about technology, although technology is used to implement it. The principles of reliability and accommodating unexpected changes at a manageable cost can be applied equally in any programming language. However, as with most things in life, not just software development, it is easiest to use a model that is supported by tools and inter-operable (the ability of two or more systems or components to exchange information and to use the information that has been exchanged). A standards-based Service-Oriented Architecture (SOA), is such a model that enables IT infrastructure is continuously adapted to keep up with the pace of business change.

Matt Wright and Antony Reynolds have just published a book Oracle SOA Suite Developer’s Guide that provides a best practice guide to using the Oracle SOA Suite for building a real world applications. This book bridges the gap between SOA theory and the Oracle SOA Suite Manuals and is based on the experience of implementing SOA across a number of organisations in EMEA and APAC. It is a book of three parts. The first section of the book provides detailed coverage of all components of the SOA Suite, namely OSB, BPEL, Rule, BAM and OWSM. The second section addresses the common question: “What is the best way to combine / use all of these different components to implement a real-world SOA solution?”. Using a working example of an online auction site, it leads you through key SOA design considerations in implementing a robust solution that is designed for change. Though the examples in the book are based on Oracle SOA Suite 10.1.3.4 the book will still be extremely useful for anyone using 11g. The final section addresses non-functional considerations and covers the packaging, deployment, and testing of SOA applications; it then details how to use Web Service Manager to secure and administer SOA applications.

I’m sure this book will continue to be relevant in years to come to. Unlike other technical books, this one does more than just explain “how” to do A, B, and C, but goes to great lengths to explain the concepts. As a software developer it is vital to understand why we were doing what we were doing, so that we know which principles to apply in different situations.

Starting up in a Credit Crunch

It is hard enough to come up with a unique business idea, let alone see it through to implementation. One of the big challenges is the cost of getting going, as well as meeting existing financial commitments. Oh, and there’s the time commitment too. Statistically, most self employed people work well over 60 hours a week.

With open source, and development licences, the technology costs in getting started are not significant. The OTN licence permits free use of Oracle products while developing an application. Oracle also provides Free and Open Source software products too. Even the Oracle 10g Database can be packaged and distributed in your application for free.

The BIG cost for a start up is expertise. So, even if the technology stack is free, someone needs to be paid to put a scalable, robust and reliable solution in place. Someone needs to be paid to market and sell the product too. Finding such resources is tough, finding the money to pay them is tougher. The author of Go BIG or Go HOME, a book about startup strategies, offers a social network dedicated to startups that seeks to make finding resources, and investment, easier.

As an obvious marketing tie-in, the network is called Go BIG where Angel Investors and people looking for funding to grow their business can meet. The member profiles are quite detailed, allowing an Angel Investor to specify exactly what sort of industries, business types, and geographies, they are interested in providing venture capital for. At this point it is worth mentioning the international aspect of Go BIG. The network is tailored for 11 countries so far. It’s not all about the money though, the network also allows people to get help on business plans, and to promote their own skill sets. So, finding a Flash Developer or an Accounting Assistant is a bit easier. Just a bit though 🙂

Practices of an Agile Developer

Title: Practices of an Agile Developer

Authors: Venkat Subramaniam & Andy Hunt
Publisher: Pragmatic Bookshelf

If you are looking for a step by step guide on running your software development projects, THIS IS NOT THE BOOK! This book, published in 2006 but still very valid today, collects the personal habits, ideas, and approaches of successful agile software developers and presents them in a series of short, easy-to-digest tips. There are 45 tips in all, covering a broad range of subjects such as the development process , incremental learning, etc. The format taken for each tip is quite interesting. As well as the indepth explanation and case study references, each tip has:

A taunt from the devil. That voice in your head that seems perfectly reasonable, but is infact taking you to a world of pain in the future.
Advice from your guardian angel. The counter-argument to the devil’s shenanigans.
A ‘What it feels like’ section. Nice short description of what happens when the tip is applied.
A ‘Keeping your balance’ section. This really reflects the Agile Development philosophy of adapting to the circumstances.

The authors have taken this approach out of the firm belief that the most important part of software development takes place in the developers head, so there is little focus on tools. However, they do provide a little sidebar called the Agile Toolkit which outlines the uses for:

Wiki
Version Control
Unit Testing
Build Automation & Continuous Integration

These tools support Agile Development, which the book describes as follows:
Agile Development uses feedback to make constant adjustments in a highly collaborative environment. Emphasis is mine, but I think this is a very good definition.

To summarise, Practices of an Agile Developer provides pragmatic ways of approaching the development process and your personal coding techniques as well as your own attitudes, issues with working on a team, and how to best manage your learning.