![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.martinfowler.com%2Fbliki%2Fbanner.png)
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.martinfowler.com%2Fbliki%2Fmf-name-white.png)
PresentationSmells
9 February 2012
tags:
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.
Sentences on slides. I could say bullet points here, as that's the most common way to misuse slides by turning them into Slideuments. But I think the real rogue is the sentence. My approach with slides is to treat them as a VisualChannel, following this it's important that the audience is listening to the speaker for the flow of words. Reading sentences breaks that up.
Floodmarks. Lots of slides have repetitive elements on the slide master that show up on every slide, these include corporate logos, legal boilerplate (such as copyrights), occasionally even tag lines. The audience either tunes out the floodmark (which makes them useless) or is distracted by them (which is worse). I recommend you only put logos and the like on the first and last slide, that's quite enough to get them noticed, but not enough to be distracting. You only need a copyright statement on one slide - and even then I'd argue you don't really need it.[1] Are your slides really so amazing that you'll lose a fortune if someone copies them?
Repetitive Pointer Movement. It's wise to always carry a laser pointer when giving a talk - indeed I suggest a combined remote-clicker laser device. But if you find yourself pointing to the same sequence of things every time you give the talk, then you should put that pointer sequence into the slides themselves. This may be as simple as an arrow or a highlight on the existing slides, or it may be rethinking the slides themselves to help bring out the point better.
Backtracking Slides. If you find yourself going back to a previous slide, that indicates the slide sequence isn't right. Instead you should copy the slide so that you keep going forwards through the deck. Once you've copied it, you can then think about whether it should be a true copy, or whether it should look different when used again in order to highlight how you are using it in the further sequence.
Slide Titles It seems to be mandatory that every slide has a title - but ask yourself if the slide's title is really needed. I've found I've often improved the visual channel by consciously removing slide titles.
Having said all this, the most important thing is your content. If the content isn't solid, or you don't really care about it, then even outstanding slidecraft isn't going to save you. Conversely an audience will forgive all sorts of crummy presentation techniques if you have interesting things to say.
1: In many places there is implied copyright, even if you don't have a statement on a document. Even so, it's wise to keep one on the document somewhere to make it easier should you need to enforce copyright. I have to say, however, that I haven't heard of anyone suing anyone over copyright infringement of a slide deck.
CharityCodeJam
25 January 2012
tags:
Over the last couple of years several of my colleagues have been organizing code jam[1] 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.[2]. (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.
The first thing is to find a suitable effort to contribute to. We look to contribute to projects producing open-source software for NGOs - the open source model fits well for such organizations. The two that we've built up most of a relationship are RapidFTR and OpenMRS. RapidFTR is a system designed to help reunite families after a natural disaster or other calamity. It allows people to quickly input information about either a lost child, or a child found without parents - then provide search facilities to match them up. OpenMRS is an open source medical records system, designed to support various forms of health care delivery work. It's used by many health care groups all over the world (and not just in the developing world).
Like New York, most of our code-jams begin as one-off events, a single evening or all day event. These days we advertise heavily, and hope to get a good sample of local developers to come along and take part. One-off code jams like this don't usually produce much useful software, since they are too short to really accomplish much. But they still have value. Firstly they generate awareness, exposing the local development community both to the specific project and the notion of working on open-source efforts for NGOs. More directly they can be the seed for an regular code jam, so it's useful to put together activities that will encourage getting back together later.
A regular code jam gets together on a schedule, with core of people who come most weeks. Such a group can make some significant contributions to a code base. People come because they get to work on some different technologies, with a different group of co-developers, to an audience that (unlike most open-source projects) isn't just other developers.
To make meaningful progress, you need someone to prepare for each code jam by breaking down work-items into something small enough that people will be able to finish them during the time at the jam. Whatever people may say and hope, they'll rarely work on the project outside code jam hours, and the schedule is too infrequent to want half-done things hanging over. Small tasks allow teams to make perceptible progress each jam - which helps keep motivation high. We like to put these tasks online before each event so people can prepare if they want to, or just get a feel for what we're working on. We also set up a mailing list to keep up regular communication on the jam and support anyone who does contribute outside of the jam.
Our regular code-jams succeed best when the group has a couple of champions who take the lead in organizing the event. It's best to have more than one champion, to cope with the work load and provide some resilience if they are absent for a while.
We try to ensure the development environment is set up to allow people to come in quickly and become productive. Much of this is the same kind of thing that we do on projects anyway to enable continuous integration - make sure that installation and build are automated so people can quickly install the code base and get it working. It's important to mention this in the advertisements for the event - people are often put off from coming due to a concern that they'll never get started due to these issues. Even so, make sure that each event has at least one person who is familiar with the code base and build environment, she can then help others find their way around. Often someone will give a short overview of what the system does and how it works for new people at the start of the jam.
We usually provide food to each event - that's an easy thing for us to do as a corporate contribution. As any XPer knows, sharing food when working is an important part of gelling a team.
So, if the idea of a code-jam appeals to you, why not give it a try? Find a suitable project to contribute to, a group of a few people to act as a core, and spend a few sessions to get things going. (There are developer guides for both OpenMRS and RapidFTR to help you get started if those projects appeal to you.) If you get going on a stable basis - post in a blog somewhere so we see what code-jams are avaialable and learn more about how to get them going.
1: "Code-jam" is a problematic name for these events. As far as I can determine, the term "code-jam" was originally used for competitive events where programmers would try to best their peers in some programming challenge. The events I describe here are the utter opposite of this, on many levels, but have attracted the same name.
2: When one of the team went down to our Porto Alegre office, he got a group contributing there too.
AggregateOrientedDatabase
19 January 2012
tags:
One of the first topics to spring to mind as we worked on NosqlDistilled 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 aggregate.
The rise of NoSQL databases has been driven primarily by the desire to store data effectively on large clusters - such as the setups used by Google and Amazon. Relational databases were not designed with clusters in mind, which is why people have cast around for an alternative. Storing aggregates as fundamental units makes a lot of sense for running on a cluster. Aggregates make natural units for distribution strategies such as sharding, since you have a large clump of data that you expect to be accessed together.
An aggregate also makes a lot of sense to an application programmer. If you're capturing a screenful of information and storing it in a relational database, you have to decompose that information into rows before storing it away.
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.martinfowler.com%2Fbliki%2Fimages%2FaggregateOrientedDatabase%2Faggregate-split.png)
An aggregate makes for a much simpler mapping - which is why many early adopters of NoSQL databases report that it's an easier programming model.
This synergy between the programming model and the distribution model is very valuable. It allows the database to use its knowledge of how the application programmer clusters the data to help performance across the cluster.
There is a significant downside - the whole approach works really well when data access is aligned with the aggregates, but what if you want to look at the data in a different way? Order entry naturally stores orders as aggregates, but analyzing product sales cuts across the aggregate structure. The advantage of not using an aggregate structure in the database is that it allows you to slice and dice your data different ways for different audiences.
This is why aggregate-oriented stores talk so much about map-reduce - which is a programming pattern that's well suited to running on clusters. Map-reduce jobs can reorganize the data into different groups for different readers - what many people refer to as materialized views. But it's more work to do this than using the relational model.
This is part of the argument for PolyglotPersistence - use aggregate-oriented databases when you are manipulating clear aggregates (especially if you are running on a cluster) and use relational databases (or a graph database) when you want to manipulate that data in different ways.
DiversityImbalance
11 January 2012
tags:
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. [1] But here I want to concentrate on a more fundamental question - does it matter?
One point of view I hear fairly regularly is that these diversity imbalances are natural - because women don't have the aptitude or inclination for programming. This point of view upsets a lot of people but I think it's important to treat it seriously. I think of it as a hypothesis, which I'll call the natural balance hypothesis. It needs to be treated seriously because there's plenty of people who feel it explains the current situation - but I argue that it has two serious flaws, which mean that I must vigorously reject it.
The first flaw is a simple one of evidence. There are (roughly) 50% women in the world, so we should expect the ratio for women in computing to be 50% - unless there's real evidence that some other ratio is natural.[2] So far there's no such evidence. Sure, it's obvious that there are biological differences between men and women, and there is evidence that there are differences in brain function between the sexes. But there is no evidence that indicates that the skills that make people better programmers are more common in men.
The only evidence that seems to occur to people who promote the natural balance hypothesis is the fact that there are less female programmers.[3] Personally I find it troubling when software professionals, who ought to be good at logical thinking, can reach so easily for such circular logic.
It is the second flaw in the natural imbalance hypothesis that brings the heat into the discussion. Men have spent centuries using this kind of argument to deny women equal rights in all sorts of fields. Over the last century we've seen tons of evidence that this isn't true elsewhere, so why should it be true in software? As far as I'm concerned this shoddy history should make us doubly wary of the any suggestion that a diversity imbalance is natural. Unless someone comes up with decent evidence that there is a relevant biological difference, we must operate on the assumption that women are equally well suited to programming.
You'll notice above that I said "inclination or aptitude". I've noticed a lot recently that advocates of the natural-balance hypothesis say less frequently that women have less aptitude than men for programming, instead they say that women don't want to do programming. But making statements with inclination is little better than with aptitude - there's still no evidence and it has just the same shoddy history.
So, accepting that there is no good reason for a diversity imbalance, does such an imbalance matter? That is, given we have a unnatural imbalance, is it a problem that's sufficiently serious to spend energy on fixing it? I think there are many reasons why it matters to tackle our imbalances. First and foremost, there's a moral argument. I'm a strong meritocrat, who believes that we should strive for a society where everyone has an equal opportunity to fulfill their potential. A diversity imbalance suggest that there are many women, who would have good careers as programmers, who are not getting the opportunity to do so. I agree with Eric Ries's view that diversity imbalances suggest we are not as meritocratic as we like to think we are.
This waste hurts our profession too. We need more and better software developers to produce valuable software that improves our lives. By not bringing enough women into the profession, we are handicapping ourselves. This will only become more serious as the demand for talent increases in the future. How can we say we are hiring the best people when we ignore significant chunks of our population. Critics of efforts to fix the diversity imbalance often fret that we risk failing to hire a well-qualified male, when we habitually fail to hire well-qualified females.
Lack of diversity is itself a problem. Different people think differently, and consequently come up with different ways to solve problems. If you have a bunch of people with the same background, they miss lots of ideas - leading to inefficiencies and lack of innovation. A diverse group is usually more effective.
This lack of diversity also contributes to our marginalization as a profession. We are already in the situation where the opinions of programmers aren't taken as seriously as they should be by people outside our profession. We see this regularly in our discussions with business people who dismiss us as mere nerds. A diversity imbalance makes us look even more like some marginalizable outsider.
Left to themselves, these kinds of imbalances tend to get worse. People have a natural, often sub-conscious, tendency to be around people like themselves. Consequently as a group becomes a smaller minority, they get excluded more. A warning sign is when people are turned away because they "won't fit in".
There is a great deal of good potential in the software profession. We have a strong tendency towards meritocracy, a natural first position with exploiting the power of computers to enhance our lives, a lack of historical baggage in how we organize ourselves and our work. As a result I think we could provide a model to influence other social groups and lead the way in demonstrating how humans can collaborate. Diversity imbalances are a cancer to that position - how can we claim to be forward thinking when our diversity looks it comes from where the rest of the world was a couple of generations ago?
Further Reading
1: I started writing this bliki post over two years ago but have been stuck because I don't have any profound things to say about how we can fix the diversity imbalance. As a rule I try to ensure that everything I write provides information that readers can act on, so this post sat in limbo. Eventually I decided that I'm just so tired of people saying things like "there aren't many women programmers because women don't have the aptitude/inclination" that I decided that this bliki was worth posting - just so I could give that argument both barrels.
2: I find it makes the discussion flow rather better if I use a concrete case, so I'm using the male-female diversity imbalance. The same arguments apply to most other diversity imbalances too - particularly those with a history of discrimination.
3: Although female programmers are rare now, that wasn't the case in the 70's. That shift is another argument against the natural balance hypothesis.
NosqlDefinition
9 January 2012
tags:
As soon as we started work on NosqlDistilled 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.
The term originally surfaced at an informal meetup on June 11 2009 in San Francisco organized by Johan Oskarsson. At the session there were presentations from Voldemort, Cassandra, Dynomite, HBase, Hypertable, CouchDB, and MongoDB. The term caught on rapidly and few people would argue that only the databases mentioned at that meeting should be called NoSQL.
Indeed there's often a twist in the name itself: many advocates of NoSQL say that it does not mean a "no" to SQL, rather it means Not Only SQL. On this point I think it's useful to separate an individual database from the kind of ecosystem that NoSQL advocates see as the future. When we say "x is a NoSQL database" I think it's silly to interpret NoSQL as "Not Only" because that would render the term meaningless. (You could then reasonably argue that SQL Server (say) is a NoSQL database.) So I think it's best to say a "NoSQL database" is a "no-sql" database. You should separately interpret the NoSQL ecosystem as a "not only" - although I prefer the term PolyglotPersistence for this usage. [1]
Even with this matter out of the way, it's still not easy to define a NoSQL database. Does any database that doesn't use SQL qualify? How about older database technologies such as IMS or MUMPS? How about a relational system that didn't have SQL (such as the early Ingres)? What happens if someone manages to bolt a SQL interface onto one of the original septet?
So for our book we took a view that NoSQL refers to a particular rush of recent databases. Some characteristics are common amongst these databases, but none are definitional.
While I'm used to the blurry lines of definitions in the software industry, I confess my heart sinks at yet another one. But the important thing is that these databases provide a important addition to the way we'll be building application in next couple of decades. A lack of a clear definition will be no more than a gnat bite on their future successes.
1: If we take the "not-only" interpretation, then we should write "NOSQL" rather than "NoSQL". I almost always see it written as "NoSQL".
NosqlDistilled
4 January 2012
tags:
Over the last few months[1] I've been helping my colleague Pramod Sadalage work on a book on NoSQL technologies to be titled NoSQL Distilled. (You may know of Pramod's work on refactoring databases and evolutionary database design.) In the last year we've been doing a few projects that have used NoSQL technology, and we think it's going to play an important role in the next few years of software development.
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.martinfowler.com%2Fbliki%2Fimages%2Fpramod2.jpg)
Pramod Sadalage
We're writing this book as a brief introduction to help people understand the issues involved in using this technology. As you might expect by the "distilled" in the title, it's modeled on the style of UML Distilled - a short overview aimed at giving you enough information to get started, providing core concepts and orientation for further study should you get deeper into it. Our target is a book of 100-150 pages, and we intend to be pretty firm on the upper limit.
It's a ill-defined and volatile field, which makes it tricky to decide what to include. This problem is exacerbated by the fact that we want a book that will be of lasting value - so we have to try and pick core concepts that span the various NoSQL systems out there and will continue to be important as they develop over the next years.
The current contents include such topics as aggregate-oriented data models, consistency in distributed data, and database evolution. We also have short example chapters that look at databases such as MongoDB, Neo4J, and Riak.
As I write this we are getting close to a first draft for technical review. We hope to reach a final draft by spring this year at which point there will be an electronic rough-cut available. The physical book, and production ebooks, should appear early this summer. I'll post here as we make progress, and I have a few related bliki posts brewing in the brain too.
1: I haven't talked about this during our work over the last few months because I don't like announcing a book project before I'm pretty sure it will ship. Now it's looking good, so it's time to reflect on the fact that it's a go.
Slideument
19 December 2011
tags:
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.
The main reason they fail is due to the amount of words and detail you need in the deck. If you want a stand-alone document you need enough context to make sense without the speaker being there. This requires a lot of words. But if the speaker is there, and speaking, then the audience ends up both reading and listening - and usually not concentrating properly on either. A good slide deck is a VisualChannel, it provides an accompaniment to the spoken words, reinforcing but not duplicating what is being said.
If people want a stand-alone document, then you can provide them with one - but it should be a different document, one that's designed for reading and not speaking.
The most sensible argument I've heard in favor of slideuments is that audience expects them, even if they are useless and never read later. I've a lot of sympathy with this argument, as it goes back to my first major presentation - a tutorial at OOPSLA in 1992. Since this was a big deal for me I decided to work hard to provide an extra-special contribution. So instead of the usual copies of slides, I wrote a special document to support the talk - about 40 or so pages - and provided that as a handout. That document was a much better coverage of the topic then the slides would be. But on the day I got lots of complaints becuase I didn't provide a copy of the slides. I am forever grateful to Rebecca Wirfs-Brock, who was the tutorial chair that year and backed me up.
People do expect slides, even when they don't really make any sense, and often it's easiest just to run off a pdf. I think that ideally you should try for more. My approach in later tutorials was to give out both the document and the slide copies. These days I give people my TalkNotes URI that points to relevant articles I've written on the topic of my talk.
Slideuments shouldn't be confused with Infodecks
Further Reading
The term Slideument seems to have been coined by Garr Renolds (author of Presentation Zen). A couple of worthwhile posts by him:
There's also an argument against slideuments from my colleague Sumeet Moghe
