A slideument is a cross between a slide deck and a document. The idea is that you can use a single slide deck both for slides during your presentation and as a handout for people to read afterwards. The trouble is that those two needs lead to very different requirements on your slides, so you can't satisfy them both. The result is that slideuments usually fail at both.

We give a one-hour overview of Continuous Delivery. Topics include the justification of Continuous Delivery, the deployment pipeline, continuous integration, devops, and deployment strategies. The highlight is Jez's personification of a release candidate as a hero in a greek myth.

A few months ago I got issued a new company laptop - a Macbook Pro with the Thunderbolt port. As I got it started idly thinking about getting a Thunderbolt display. I've heard good things about Apple displays, despite their expense, and the idea of a display that would act as a docking station was appealing.

In 2006, my colleague Neal Ford coined the term Polyglot Programming, to express the idea that applications should be written in a mix of languages to take advantage of the fact that different languages are suitable for tackling different problems. Complex applications combine different types of problems, so picking the right language for the job may be more productive than trying to fit all aspects into a single language.

Over the last few years there's been an explosion of interest in new languages, particularly functional languages, and I'm often tempted to spend some time delving into Clojure, Scala, Erlang, or the like. But my time is limited and I'm giving a higher priority to another, more significant shift, that of the DatabaseThaw. The first drips have been coming through from clients and other contacts and the prospects are enticing. I'm confident to say that if you starting a new strategic enterprise application you should no longer be assuming that your persistence should be relational. The relational option might be the right one - but you should seriously look at other alternatives.

One of the good things about software is that people seem to want it, and want it quickly. It's usual for organizations to ask teams to speed up production of software and from time to time the organization seeks to help in the way that really shows its commitment - by spending money to add more people to the team.

From the very beginning of when I started to talk and write about refactoring people have asked me how it should be incorporated into the wider software development process. Should there be refactoring phases in the software development lifecycle, what proportion of an iteration should be devoted to refactoring tasks, how should we figure out who should be assigned to refactoring duties? Although there are places for some scheduled refactoring efforts, I prefer to encourage refactoring as an opportunistic activity, done whenever and wherever code needs to cleaned up - by whoever.

goto (formerly known as JAOO) has long been a favorite conference of mine. They've done a great job over the years of keeping a high standard of content combined with an efficient and friendly organization. So while my over-consumption of conferences has generally led to conference-phobia, I still feel a sense of pleasant anticipation when heading off for the somewhat complicated trip to Aarhus.

Making and editing video used to be an expensive exercise, but now cameras and editing software are cheap. As a result many loud-mouths like me have got into making videos to help spread their ideas. There's many reasons to do this, it's a medium with lots of possibilities, it suits people like me who talk well on stage, and there's good evidence that people will pay for video - which is good both for one's income and as evidence that people take it seriously. Despite these reasons, so far I've not taken the plunge.

A while ago Cindy and I, together with a couple of neighbours, began a long quest that who knows if we will finish. The quest is to watch every play of Shakespeare, in every reasonably available video version. It's been a lot of fun, although we aren't able to cover as much as we'd like as I'm so often traveling. We are doing them in rough chronological order, and have just finished with A Midsummer Night's Dream.

When people start an enterprise application, one of the earliest questions is “how do we talk to the database”. These days they may ask a slightly different question “what kind of database should we use - relational or one of these NOSQL databases?”. But there's another question to consider: “should we use a database at all?”

10 years after we wrote the agile manifesto, we authors were invited to a special event during the Agile 2011 conference to celebrate the anniversary. Fifteen of the seventeen authors came along and we ran a park bench panel answering questions and comments from the audience. I think we were all surprised by how good it was to meet again and how easily we fell back into a comfortable collaboration and discussion. Our discussion included some background to the writing of the manifesto, looking at things over the last decade that we were pleased and unhappy with, future developments in agile, and the relationship between agile and lean.

I think almost everyone I know in the software development field has a deep hatred for patents and the way they've been used in our field. I've had a post on my todo list for ages about this and have finally been moved to write about it after a particularly good piece of investigative journalism by This American Life. The short form of my post is that while patents (even software patents) are a good idea in principle, in practice they have turned into an unmitigated disaster and would be better scrapped.

A few weeks ago, a friend asked for recommended podcasts. It's taken me a while to answer, but I thought this would be a good opportunity to suggest what I like listening to.

Those who hear my colleagues and I talk about FeatureBranch know that we're not big fans of that pattern. An important part of our objection is the observation that branching is easy, but merging is hard. One argument we hear from time to time is that modern VersionControlTools make merging sufficiently easy that feature branching is worthwhile.

I've been poking around in JavaScript recently and one thing that's struck me is the habit of using the same function name for a getter and a setter. So if you want to find out the height of your banner in jQuery you would use $(“#banner”).height() and if you want to change the height you would use $(“#banner”).height(100).

This convention is familiar to me, as it was used by Smalltalk. You might get a value with banner height and change it with banner height: 100. Knowing it was a smalltalk convention is enough to expect me to like it, since I have an distant but abiding love for that language. But even the best things have flaws, and I can't hide my dislike for this coding style.

One of my favorite soundbites is: if it hurts, do it more often. It has the happy property of seeming nonsensical on the surface, but yielding some valuable meaning when you dig deeper

CQRS stands for Command Query Responsibility Segregation. It's a pattern that I first heard described by Greg Young. At its heart is the notion that you can use a different model to update information than the model you use to read information. For some situations, this separation can be valuable, but beware that for most systems CQRS adds risky complexity.

Recently, via some blog, tweet or other ripple in the internet stream, I came across The Presentation - a free book by Andrew Abela on extreme presentations. It's a short and breezy book that outlines a particular style of doing presentations. I liked the approach he outlines. I think it's worth a look if you are interested in presentation technique and particularly if you are giving a presentation in order to persuade a small group to take an action.

LMAX is a new retail financial trading platform. As a result it has to process many trades with low latency. The system is built on the JVM platform and centers on a Business Logic Processor that can handle 6 million orders per second on a single thread. The Business Logic Processor runs entirely in-memory using event sourcing. The Business Logic Processor is surrounded by Disruptors - a concurrency component that implements a network of queues that operate without needing locks. During the design process the team concluded that recent directions in high-performance concurrency models using queues are fundamentally at odds with modern CPU design.

For a while I've been happy about my lens setup for my DigitalSLR: a Sigma 18-200 as a general on-camera lens, Canon 10-22 for wide, Canon 50 f1.8 and 100 f2 for low light portraits and narrow depth of field. It's a good set up that's helped me take lots of photos that I like.

But, as most obsessive amateurs like me know, there's always that nagging desire for better equipment. I hear about how a consumer-grade lens like the 18-200 can't be as sharp as something a bit better, that I can get a lens that will auto-focus faster and quieter, maybe my longer tele shots are a bit softer than I think I ought to be able to get?

I wasn't cool enough to be in the first wave of invitations, but I have now got onto Google+, the Maybe Next Big Thing in social networks. It seems somewhat appropriate to mark this Momentous Event by writing a little bit about how I've used social networks so far, and some uninformed speculation about the impact of Google+

A common question in IT departments is whether to provide a capability by building custom software or by buying a package. For longer than I've been programming the debate has raged about how to make that choice. My base position on this is founded on the UtilityVsStrategicDichotomy. Boiled down this means that if the business process you are supporting is part of your competitive advantage you should build custom software, if not you should buy a package and adjust your business process to fit the way the package works.

Despite the clear excellence of my opinion, not a lot of companies seem to do this. Often they neglect the dichotomy, which is one problem. But the problem I want to focus on here is the common trap when they buy a package.

In this video (12 minutes) Mike Mason and I talk about the perils of Feature Branching and its alternatives.

I recently decided to upgrade my home MediaServer and got an HP N36L. So far I'm happy with it.

A flag argument is a kind of function argument that tells the function to carry out a different operation depending on its value. Let's imagine we want to make booking for a concert. There are two ways to do this: regular and premium . To use a flag argument here we'd end up with a method declaration along these lines:

Three talk segments: non-determinism in tests, economics of software development, 10 years since the agile manifesto.

A common problem in people's presentation decks is that they make text and diagrams so small that only the people in the front of the room can properly see them. Here's one simple thing I do to reduce the chances of that happening to me - when I'm composing my presentation I set the view size to 50%. If I can't read it easily at 50%, then the audience will struggle too.

Thoughtworks is an unusual company, which is why such a corporate-skeptic as myself has hung around for a decade here. An important feature of Thoughtworks is that we take a broader view of our purpose than simply a commercial entity. Over the last couple of years we've been using a three-pillar model to describe the way we like to think of ourselves.

One of the benefits of using web services is that it helps you to decouple various parts of a system. People can work on separate code-bases with some degree of separation. Although you get some decoupling, you cannot eliminate the coupling completely because the services still have to communicate to each other through their interfaces. The sad thing is that many teams make this coupling much worse than it should be.

It's only just over a year since I got my first ebook reader. Now I only buy paper books when I really have to. I wrote my last book thinking of it primarily as a paper book, but that will be the last time, in the future electronic forms will be at the front of my mind. These changes will completely alter the landscape of books, but other than that, the next steps aren't that clear.

SD Times interview on 10 years since the agile manifesto

PowerPoint wasn't invented in the Middle-Ages, when knights rushed around battlefields in full armor. But the slide decks of today share a common characteristic with those knights of old. Both need to be able to clearly distinguish symbols from a distance. We may not have mud and dust, but many projectors aren't all that great at contrast.

With the rise of so many mobile platforms, each with a different UI, many people are looking at cross-platform toolkits. These allow you to write a mobile app once and then deploy it to a range of mobile devices. Are these toolkits worth using?

Yesterday I was poking around a code base, looking at the domain model part of the code. When exploring a code base, I like to take notes to help me remember what I'm learning. For some code bases, in particular domain models, I find it handy to sketch UML class diagrams.

The chances of a demo going wrong are directly proportional to the importance of the audience.

All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation.

-- Bertrand Meyer

Bertrand Meyer coined this principle in his highly-influential book Object-Oriented Software Construction.

The essential point of the principle is that if you have a person object and you ask it for its age, you should use the same notation whether the age is a stored field of the object or a computed value. It effectively means that a client of the person should neither know nor care whether the age is stored or computed.

We recently spend a week on vacation in the southern cities of Savannah and Charleston. I'd heard good things about both cities in terms of their beauty and historic interest - and I can confirm those good things. Both are well worth a couple days of wandering around.

An automated regression suite can play a vital role on a software project, valuable both for reducing defects in production and essential for evolutionary design. In talking with development teams I've often heard about the problem of non-deterministic tests - tests that sometimes pass and sometimes fail. Left uncontrolled, non-deterministic tests can completely destroy the value of an automated regression suite. In this article I outline how to deal with non-deterministic tests. Initially quarantine helps to reduce their damage to other tests, but you still have to fix them soon. Therefore I discuss treatments for the common causes for non-determinism: lack of isolation, asynchronous behavior, remote services, time, and resource leaks.

From time to time I get introduced as a “signatory of the Agile Manifesto”. Usually what they mean is that I'm an author of the Manifesto for Agile Software Development, and thus one of its initial signatories. But actually there are many more signatories than the 17 authors, when I last looked the count was up to 10,104. If you're so inclined you may join that list.

Many programs need to make use of resources that are expensive to create and maintain. Examples of these are database connections and threads. A resource pool provides a good way to manage these resources.

Most of my friends and colleagues are very negative about certification schemes in software development, a disdain that I share. This doesn't mean that I think that certifications in software are bad by definition, just that almost every one we see fails a basic test.

I recently decided to upgrade our home server setup. I posted some thoughts about what I was planning to do here, and now I've updated this page with what I did.

When I first made the move to a DigitalSLR I deliberately bought a cheaper camera - a Canon Rebel XTi/400D. I did this partly to put more money to lenses, but also because I knew that technology would move on and I'd be looking to replace the body in a few years.

I commonly come across developers who are frustrated because “management want more features, they don't care about quality”. I'm always sad when I hear this, because when I hear this I know that the developers, management and their customers have already lost. Their defeat has been caused by framing the situation in terms of the tradable quality hypothesis.

I use subcutaneous test to mean a test that operates just under the UI of an application. This is particulary valuable when doing functional testing of an application: when you want to test end-to-end behavior, but it's difficult to test through the UI itself.

Daniel Terhorst-North's recent blog post on software craftsmanship has unleashed a lot of blog discussions (which I summarize below, if you're interested). There's a lot in there, but one of his themes particularly resonated with me, hence this post.

Frequently I come across the claim that some technology will allow users to write their own software and not need programmers any more. When I hear this I like to remember that this was the aim COBOL - and we know how that worked out.

One of the most common cases of using a TestDouble is when you are communicating with an external service. Typically such services are being maintained by a different team, they may be subject to slow, and unreliable networks, and maybe unreliable themselves. That's why a test double is handy, it stops your own tests from being slow and unreliable. But testing against a double always raises the question of whether the double is indeed an accurate representation of the external service, and what happens if the external service changes its contract?

Most of this site, including this bliki, is built using an XML to HTML transformation process. I write the articles and bliki entries in my own XML vocabulary and then transform these sources to the HTML you read. When I stated back in 2000 I did it in XSLT. While I got pretty good at programming XSLT I came to the conclusion that I was not enough of a masochist to want to continue using it. After a short experiment, writing the bliki transformer in Ruby on a flight to Bangalore, I switched to Ruby using the REXML library. Now it's time to change that core library to Nokogiri

While we were in India we took a week's vacation in the Andaman Islands, primarily to indulge in some diving. We spent most of our time on Havelock Island, which is a couple of hours by ferry from the main centre at Port Blair. Here's some scattered things to share from our experience.