Architecture and Collaboration, The cornerstones of Continuous Delivery @ W-Jax

Tom Sulton and I present this talk on implementing Continuous Delivery at W-Jax 2012.

Synopsis

Once you've been on a continuously-delivered project, there's no way back. The combination of rapid feedback, high levels of collaboration, and great software quality produces a virtuous delivery cycle that is both pleasing and effective. However, existing delivery models and product portfolios may not allow for straightforward adoption of CD. Technical and organisational debt accumulates inexorably over time and can make continuous delivery difficult or even impossible. In this session, we draw on our extensive project experience to demonstrate some of the software architecture patterns that enable continuous delivery. We look at related anti-patterns; and some strategies for getting a codebase into a shape such that it can be continuously delivered. We use examples of both successful and unsuccessful projects to show some of the rewards and pitfalls of following these strategies. As the structure of a software product changes, the organisation of the teams building and supporting it will need to go through concomitant changes. Using more real project examples, we discuss what drives these organisational changes, how they can be managed, and how to base a delivery team around collaboration rather than conflict. As we go, we engage members of the audience in a conversation about instances where they have seen similar issues, and encourage sharing of some methods that they might have tried. After this session, attendees will be able to recognise common anti-patterns in both software architecture and development practices. They will have an understanding of how these anti-patterns affect a development team's ability to deliver. Attendees will also have a number of tools and practices available to them to resolve those issues that are holding their team's continuous delivery efforts back.

Pair Programming, the good, the bad and the ugly @CWDNUG

Sara Stephens and I presented the following at the Canary Wharf .NET User Group.

Synopsis

Pair programming is an XP practice of programming together, two people, one computer. When it's done right, it's fun and productive. This talk takes you on a journey through good and bad pair programming patterns and anti-patterns and explains why pair programming can benefit you and your company when it is done right.

TDD in Python @ PyCon

Charles Haynes and I presented a TDD tutorial in Python.

Synopsis

Do you think TDD just improves the quality of your code? We'll show you how TDD also improves the quality of your design, makes your code more manageable, readable, reusable and cures hangovers. OK maybe the last one isn't true but we know from experience that the rest are.

In this tutorial, we will focus on a practical introduction on how to do Test Driven Design in Python with a real world example, on real code, in real time with your participation. We'll cover the Red, Green, Refactor practice, commit frequently, what a unit test is and is not, and how to use mocks to write good isolated, fast unit tests. We will also cover patterns for keeping your code clean, well designed, reusable, and give you the courage to refactor fearlessly and mercilessly!

We will demonstrate and describe some of the specific scaffolding you can use to make all of the above as easy as pie. We'll also show you some of the super cool stuff that only Python can do! Or at least is trivial in Python.

Continuous Delivery @ Oredev

Tom Sulston and I presented the following tutorial at Oredev 2012. Slides to follow.

Synopsis

In this tutorial we take the unique approach of moving from release back through testing to development practices, analyzing at each stage how to improve collaboration and increase feedback so as to make the delivery process as fast and efficient as possible. At the heart of the tutorial is a pattern called the deployment pipeline, which involves the creation of a living system that models your organization's value stream for delivering software. We spend the first half of the tutorial introducing this pattern, and discussing how to incrementally automate the build, test and deployment process, culminating in continuous deployment.

In the second half of the tutorial, we introduce agile infrastructure, including the use of Puppet to automate the management of testing and production environments. We'll discuss automating data management, including migrations. Development practices that enable incremental development and delivery will be covered at length, including a discussion of why branching is inimical to continuous delivery, and how practices such as branch by abstraction and componentisation provide superior alternatives that enable large and distributed teams to deliver incrementally.

Context is Key

I recently spent four months as trainer at ThoughtWorks University, which is the graduate training programme for ThoughtWorks. It is a six week programme and I was a trainer for two terms. One of the key learnings I had while there is the value of context and the danger of assumptions!

During the programme we spend four of the six weeks on a real project which at TW is described as an SIP (Social Impact Programme). On the project as well as being a trainer/coach I played an unofficial tech lead role, while the grads got up to speed. One of the things I noticed very early is the grads assumption of my vast knowledge of the application and code base we were working on and therefore when ever they asked me any questions they rarely gave me context. I spent a large amount of my time asking lots of questions about what the hell they were on about. Often people would walk right up to me and just start explaining some very specific piece of code wasn't working. I'd often be thinking "What the hell are you on about?", as I quickly tried to change context from what I was working on with my pair before I was disturbed.

I quickly gave feedback to the grads about the value of context and tried to determine what their assumptions were. What I discovered is that having just finished university they were quite used to being given a piece of work to do (an assignment) in which the lecturer probably had seen a hundred times and was well aware of the amount of ways it could be developed. However, when they were given a story, myself as the tech lead and NOT the lecturer wasn't a 100% sure exactly how the problem would be solved, that is often down to the pair working on the story. So whenever the grads came across any issue or weren't sure what to do next, they would ask me questions with the assumption that I already knew how to solve the problem and it was their job to figure out THE solution. When they got stuck they wanted to know the next step. So they would blurt out where they were stuck and I would spend most of my time trying to get context and some understanding of their proposed solution. Often what would happen is the rather enquiring 'cardboard programmer' (me) would keep digging until they actually came up with the solution themselves. So although it wasn't a completely invaluable exercise it was a little frustrating for me so I believe it is really important to always give context. Even if you assume that the other person does know what you are talking about if you assume they don't and always give context, they will tell you if they already know what you are talking about. Erring on the side of caution is always best to get the most value out of the question recipient. Often they will become a 'cardboard programmer' but regardless context is key and I found the grads became much better developers just by learning to give context. As this helped them understand their solution better and what they were trying to achieve. It isn't just important when asking questions but also when continuing a story with a new pair. But this isn't just a lesson for graduates, through this I have become better at giving context as now I appreciate the real value a lot more.

I'm sure there is even more value in giving context, which I would love to hear :)

Don't forget your relational database

Now the good old relational database has had a bit of a bad wrap lately. It's all about document databases and flat tables and CQRS and blah, blah, blah. Well let me just remind you that most of us are still 'dealing' with our friend mr relational database and I'd like us all to take a moment to treat him with the respect he deserves... or at least not forget that he still exists and requires a little bit of relationship management.

On my current project we're using an ORM to map our database objects to the nice (ahem) OO one's we've created. For our ORM we're using NHibernate and Active Record (to remove the xml configuration layer). However it has come to my attention recently that many developers were under the impression that adding attributes of HasMany and BelongsTo to the OO object properties you map to your database would carry that relational constraint down the the database. But I'm afraid not folks! That dependency still needs adding to your database the old fashioned way using your migrations. If you forget to push this constraint down you are in danger of some other code somewhere else in your system or worse outside of your system breaking the relational integrity of your database....boom!

I openly admit that this is a pain and probably another plus point for relational database naysayers but as I said earlier we still have to be nice to mr relational so don't forget him please :)

LDNUG open mic night: Pair programming, the good, the bad and the ugly

On Wednesday evening the London .NET User Group (LDNUG) hosted an open mic night. This is an opportunity for first time speakers to present in a friendly environment and this time I was one of them. Sara Stephen's and I presented our first public presentation on Pair Programming: The good, the bad and the ugly.

Our talk was a mix of presenting and some short sketches on good, bad and ugly pair programming. We decided that showing what good, bad and ugly looked like would be more helpful than describing it and hopefully be more memorable!

Being my own biggest critic there are a couple of things I would change about the presentation, but the great thing about having this small friendly environment to practice in is if we get it a bit wrong in anyway we can work on that and improve for next time and there definetely will be a next time.

Most of the feedback we received was good and the audience members I spoke to found our presentation both entertaining and informative which is exactly what we were hoping for. Even better one audience member said we stole the show, but admittedly that is easier to do when you're sketching out pairing than talking about technology on your own.

After coming up with the idea for our presentation we came across this presentation at Oredev, which is like an extended version of our talk and covers even more areas to think about while pairing.

The other great speakers of the evening who also did really well were:

James Knowles - "Three years of running a Tiny software company.. All my mistakes.."
Matt Lacey - "Cross platform mobile app development"
Robin Minto - "HTML5 basics"
Garry Shutler - "Introduction to Sass"

I think the open mic nights are a great idea and opportunity for new speakers so I'd like to say a big thank you to Toby Henderson for organising it and EMC and Michelle Flynn for hosting us. I believe he plans to do more in the future.

The next LDNUG's will be on the 4th and 18th November, the latter of which I am organising. Currenty Ian Cooper, Zi Makki, Toby and I share the load. This talk will be by Sarah Taraporewalla, another ThoughtWorker, and will be on integration points. More details to follow...