When I rant on at my colleagues about the evils of Slideuments, I do hear a useful push-back. Many people now like to communicate through slide decks that aren't meant to be used for presentations, just to be read. People like me can snark about managers these days being unable to read anything that doesn't look like a bullet point, but there are advantage to these infodecks.

As I write this towards the conclusion of the US presidential election , there's a side debate that's appeared about the forecasts produced by Nate Silver. Many Republicans claim he's a shill for the democrats and his forecast of an 85% chance of an Obama win is bogus . Part of me wishes I knew more innumerate Republicans that I could make side-bets with. Perhaps a better wish would be that the polls were the other way around as I have more Democratic-leaning friends. In reality either way I wouldn't gain too much as most people I know are numerate. Sadly this isn't true in general - this side-show is an illustration of the deep illiteracy most people have for probability, which has some important ramifications for society in general and software development in particular.

Mobile applications have been a hot item in software development over the past couple of years. Like many software delivery companies, Thoughtworks get a lot of requests from clients asking us to build a mobile application for them. However most of the time a company asks us (or anyone) to build a mobile application they are starting off on the wrong foot. I'd argue that for most situations, even though you want users to interact with a mobile device, you should never think of building a mobile application. Instead you need to think about building a single application that presents across multiple devices: mobile, desktop, tablet - or whatever device your users might use.

The Retrospective Prime Directive is an important part of retrospective practice, and has been in integral part of retrospective thinking since Norm Kerth first launched the practice. Recently I read Pat Kua's new Retrospective Handbook, which is based on the extensive experience with retros that Pat has had as a tech lead at Thoughtworks. I find Pat's advice for the Prime Directive revolting, yet have to say he's almost certainly correct.

Twice a year or so, I get together with the Thoughtworks TAB - a selection of senior Technologists from our global organization. One of the main products of our meeting is our Technology Radar. The radar has got a lot of attention and raises some common questions, which this FAQ hopes to answer.

The last couple of months have been heavy on the travel (towards the end of it I calculated that I'd spent 40 out of the last 44 days on the road) which is why my website has been quiet. Now I'm back home again and can reflect on some of it - and the goto conference is always full of things to reflect on.

At goto Aarhus, we had a track on some practical experiences with NoSQL. I was asked to give an initial talk to explain the basic principles of NoSQL datastores. I talk about the origins of NoSQL, forms of NoSQL data models, the way many NoSQL databases consider the problem of consistency, and the importance of Polyglot Persistence.

One of the tracks at goto Aarhus gave NoSQL vendors the chance to talk about their various tools. At the end of the track the various speakers were put on a panel to discuss some of the common issues involving NoSQL. Although I wasn't involved in the track (my talk came a couple of days later) I was involved on the panel.

When we designed the book, NoSQL Distilled, we concluded most chapters with some summary key points to act as a refresher for people re-reading the book. We've included these on the website as another way for readers to remind themselves of these key points.

The positive effect modern mocking tools can have on our ability to work with legacy code and the possible negative implications of using those tools.

Can Google’s new BigQuery service give customers Big Data analytic power without the need for expensive software or new infrastructure? Thoughtworks and AutoTrader conducted a weeklong proof of concept test, using a massive data set. The tests showed consistent query performance on a 750 million row data set in the 7-10 second range. We used the REST APIs with Java, JavaScript and Google Charts to create a web front-end with interactive visuals of query results. The entire exercise was conducted with three people in five days. The verdict: BigQuery performed well, and could benefit organisations with Big Data and smaller budgets—especially those without a data warehouse, or whose data warehouse has restricted use.

With the growing interest in data analytics and visualizations, we're seeing more effort put into interesting visualizations that allow people to draw insight from data floating around in an organization. Most of these dashboards are aimed at individual usage, but there is a growing tendency to use them for a more communal purpose.

It can be finicky business to keep a production server running. You have to ensure the operating system and any other dependent software is properly patched to keep it up to date. Hosted applications need to be upgraded regularly. Configuration changes are regularly needed to tweak the environment so that it runs efficiently and communicates properly with other systems. This requires some mix of command-line invocations, jumping between GUI screens, and editing text files.

The result is a unique snowflake - good for a ski resort, bad for a data center.

One day I had this fantasy of starting a certification service for operations. The certification assessment would consist of a colleague and I turning up at the corporate data center and setting about critical production servers with a baseball bat, a chainsaw, and a water pistol. The assessment would be based on how long it would take for the operations team to get all the applications up and running again.

Mobile devices are increasingly important as a platform for customers and employees to use software services. Lots of people are busy building mobile applications, but also lots of vendors are busy building mobile devices. This range of mobile devices presents a challenge - how do you support lots of mobile devices?

Pramod Sadalge led the development of agile database techniques which we now use habitually at Thoughtworks. SE Radio interviews us about how we use these techniques to evolve the design of a database iteratively together with applications that use it. We discuss how to incorporate databases into a Continuous Integration system, how to make database changes through repeatable scripted migrations, and how database refactoring works.

The sudden and rapid explosion of mobile technology in the past five years offers huge opportunities. While it seems likely that a number of mobile platforms will continue to thrive, mobile customers are demanding a very high quality of user experience from their applications. This article presents two strategies for implementing a mobile channel that will assist in balancing user experience and platform coverage while also providing a path forwards for your apps.

While I was at the QCon conference in London a couple of months ago, it seemed that every talk included some snarky remarks about Object/Relational mapping (ORM) tools. I guess I should read the conference emails sent to speakers more carefully, doubtless there was something in there telling us all to heap scorn upon ORMs at least once every 45 minutes. But as you can tell, I want to push back a bit against this ORM hate - because I think a lot of it is unwarranted.

The test pyramid is a way of thinking about how different kinds of automated tests should be used to create a balanced portfolio. Its essential point is that you should have many more low-level UnitTests than high level BroadStackTests running through a GUI.

In my conversations with Thoughtworks project teams over the last year or so, a regular theme has been the growing impact of content management systems (CMS). They aren't usually seen as helpful, indeed there is a clear sign that they are becoming a worryingly invasive tool - used for more than their core purpose in such a manner that they hinder overall development.

Amongst the other irritations, a common failing is that they keep one copy of each article. This single copy is edited as part of creating the content and published to readers (usually on some kind of state-change flag).

Our keynote at QCon London 2012 looks at the role data is playing in our lives (and that it's doing more than just getting bigger). We start by looking at how the world of data is changing: its growing, becoming more distributed and connected. We then move to the industry's response: the rise of NoSQL, the shift to service integration, the appearance of event sourcing, the impact of clouds and new analytics with a greater role for visualization. We take a quick look at how data is being used now, with a particular emphasis from Rebecca on data in the developing world. Finally we consider what does all this mean to our personal responsibilities as software professionals.

From time to time I hear people asking what value of test coverage (also called code coverage) they should aim for, or stating their coverage levels with pride. Such statements miss the point. Test coverage is a useful tool for finding untested parts of a codebase. Test coverage is of little use as a numeric statement of how good your tests are.

I've given lots of presentations, and since I go to a lot of conferences I see a lot too. This means I see a lot of problems, where people are doing things that reduce the efficacy of their talks. I've not tried to come up with a comprehensive list, so the ones I'm raising here are just a few things off the top of my head. Like most smells, these aren't always wrong, but should always make you think.

An infodeck on the future of data storage in the enterprise, written primarily for those involved in the management of application development. Explains why relational databases have been the dominant, why NoSQL is challenging this assumption and sketches out the future of Polyglot Persistence, where multiple data storage technologies will be used for applications depending on their varied needs.

I'm joined by Thoughtworks CTO Rebecca Parsons, who was a contributer to the DSL book, to talk with Markus Völter about DSLs. We talk about what DSLs are, the differences between internal and external DSLs, and when you should (and shouldn't use DSLs).

Over the last couple of years several of my colleagues have been organizing code jam events where developers get together to write software for charitable causes. A good example is a regular code-jam in New York that works on RapidFTR. Chris George, a ThoughtWorker based in New York, helped organize a one-off event in New York in August 2010. The group didn't get as much done on the day as they had hoped, but in a bar afterwards decided to try to get together more regularly. Since then they've been meeting every week. It's a small group, still mostly ThoughtWorkers and friends, with a core of 3-4 people rising to a dozen when we've had a big project in town.. (Chris is happy to have more people join the group, so if you are interested drop him an email.)

Many people have found these events to an enjoyable way to use our skills for purposes that we find rather more fulfilling than many day jobs, and a way both to learn new skills and learn from a different group of people. So I thought I should share our thoughts on how to set one up.

One of the first topics to spring to mind as we worked on Nosql Distilled was that NoSQL databases use different data models than the relational model. Most sources I've looked at mention at least four groups of data model: key-value, document, column-family, and graph. Looking at this list, there's a big similarity between the first three - all have a fundamental unit of storage which is a rich structure of closely related data: for key-value stores it's the value, for document stores it's the document, and for column-family stores it's the column family. In DDD terms, this group of data is an DDD_Aggregate.

Although it's easy to become accustomed to it, it's pretty obvious the software development world has some serious issues in diversity. By this I mean that we have some notable differences in proportions of people compared to the general population. One of the most obvious differences is the low proportion of women, which is true all over the world (albeit noticeably less so in China). In the US, where I spend a good chunk of my time, the lack of African-Americans is also obvious. There's a lot been written on why such imbalances might exist, and what might be done about it. But here I want to concentrate on a more fundamental question - does it matter?

As soon as we started work on Nosql Distilled we were faced with a tricky conundrum - what are we writing about? What exactly is a NoSQL database? There's no strong definition of the concept out there, no trademarks, no standard group, not even a manifesto.

When we leared that Pearson, our publisher, was a supporter of the controversial SOPA legislation, Jez Humble and I wrote an open letter of protest. A hundred other Pearson authors co-signed the letter after it was published.