So you want to talk about creation and evolution…

We’ve had a bit of an uptick of interest in this particular subject at church in recent months, so I thought I’d better say a few things about the matter and give a word of caution to anyone who’s thinking of rushing into the fray.

This post is intended to be a must-read for every Christian thinking about getting into the creation and evolution debate. You may not agree with my exact position on the matter, but you do need to know that there are pitfalls to avoid, and that rushing headlong into the debate with all guns blazing can cause much more harm than good. I all too often see well meaning but badly informed Christians doing precisely that, only to prove to everyone in earshot that they haven’t the faintest idea what they’re talking about, and it just makes all of us as Christians look unnecessarily bad.

1. Make sure that you know what you are talking about.

It’s very tempting to read a whole lot of material by Answers in Genesis or to watch some videos from and come away thinking that you know more about science than “secular scientists.” But this is like thinking that reading Let’s Parler Franglais gives you a sufficient command of French to work as an interpreter in the European Parliament.

The same is true of any source of information about science. It’s also true of the Guardian, New Scientist, and Physical Review Letters. Science is not like art or English literature, where you can make it up as you go along, or like journalism where you can just “science it up a bit to make it sound convincing.” It is an exact and rigorous subject with strict protocols and stringent standards. It relies heavily on measurement and mathematical modelling—skills that can only be learned through hands-on experience. It uses very precise and carefully defined terminology. In some areas of inquiry, if you get your science wrong, even in seemingly minor and nitpicking ways, you can kill people. Even in the “historical sciences” bad science could cause a lot of damage. Get your radiometric dating results out by a few million years and you will send oil companies on a wild goose chase spending a fortune drilling for oil only to find that it’s either too young or too old and they can’t get it out of the ground.

If you don’t properly understand this, you will get things wrong. You will end up attempting to refute a straw man caricature of science that bears no resemblance whatsoever to what real scientists do. You will argue against claims that nobody is making with rebuttals that don’t make sense. You will quote people as saying the exact opposite of what they are actually saying. You will cite arguments that even the YEC ministries themselves tell us not to use. You will tell demonstrable, easily fact-checked untruths without realising that you are doing so. You will just end up confusing people.

On top of that, you will end up being confronted with questions, objections and evidence that you did not expect and that you are thus not able to answer coherently.

If you’re going to discuss creation and evolution—or science and faith in general—make sure that you know what you don’t know. Don’t be afraid to admit that something is beyond your area of expertise: you’re not going to win any converts by claiming to know all the answers when quite clearly you don’t. In particular, if you want to teach in your church on creation and evolution, you should really have a degree in a relevant Natural Sciences subject, such as biology, geology, paleontology, or physics. If you are a pastor, you would do well to insist on this. Try to find a biology teacher or a petroleum geologist if you can and ask them to advise you.

2. Make sure that your facts are straight.

If you believe that the Bible demands a young earth or non-evolution, and that you must therefore reject the scientific consensus, please be honest in how you approach it. Rejecting science may be faith, but misrepresenting science is a completely different matter. Claims that are easily fact checked and easily shown to be untrue, or misleading, or nonsensical, will undermine your credibility in the eyes of anyone who happens to check, or who is otherwise confronted with indisputable evidence that contradicts you. At best, you will end up looking clueless and ignorant; at worst, you will end up looking dishonest, and in so doing you will bring the whole Gospel message into disrepute. Next time you’re tempted to say, “Evolution is only a theory” or “There is no evidence for evolution,” remember that most of the people you’re talking to have smartphones, and can fact-check you on Google as you speak.

This means that if you are going to refute scientific techniques such as radiometric dating, you need to make sure that you are refuting what scientists actually do in real life, and not some kind of straw man over-simplification of it. It is dishonest to claim that scientists make untestable assumptions and presuppositions when they do not, or that they use circular reasoning when they do not, or that they otherwise work in ways that they do not. For example, the claim that “fossils are used to date rocks and rocks are used to date fossils” is untrue: fossils and rocks are dated first and foremost using radiometric dating.

There is no such thing as “historical science” which relies on untestable assumptions. The very bedrock of science is testable hypotheses, and once you start relying on untestable assumptions, you are no longer doing science, but philosophy or metaphysics. In fact, “historical science” can easily be tested simply by cross-checking different studies whose assumptions are independent of each other. This is the same principle as the Biblical one that “every matter must be established on the testimony of two or three witnesses.” (Deuteronomy 19:15; Matthew 18:16; 2 Corinthians 13:1). One example is the cross-checks between rates of continental drift as determined by radiometric dating and GPS measurements.

Don’t exaggerate the significance of error bars and discrepancies, as you see in this video at 0:28 seconds for example. Fifty million years may sound like “rather a lot” in human terms, but it’s an error of just one percent. The idea that errors of only a few percent could justify claims that all radiometric results must be consistently out by a factor of several hundred thousand is, quite frankly, absurd.

Make sure too that you don’t make false claims about the evidence itself. The findings of soft tissue remnants in dinosaur fossils are one example where I see a lot of misinformation, though no doubt some of that comes from clickbait-y headlines in the popular press. Mary Schweitzer did not find intact blood cells, nor fresh dinosaur meat, nor unfossilised skin, and at most only tiny traces of DNA in quantities far too small to be sequenced. (Schweitzer’s paper is here; you can find a video explaining the problem and what exactly she actually found here.) Incidentally, the absence of sequenceable DNA from dinosaur fossils is a major problem for the young earth timescale: in a 6,000 year old earth—and certainly one where Noah had dinosaurs on the Ark and where the Flood was followed by an ice age—we should expect to find large quantities of high quality dinosaur DNA sequences all over the place. But we don’t.

Don’t quote people out of context to make them appear to be saying things that they are not. The young earth creationist industry has a very bad reputation for “quote mining.” To be fair, some of the examples that I’ve seen could plausibly be explained as simple misunderstanding, but at the same time, there are some massive facepalms out there. Take for example this article, which claims that scientists are now acknowledging that all species appeared on earth at the same time. In support of this claim, it cites a paper in Science magazine (“Fossil recount limits diversity.” Science, 25 May 2001, page 1481). Here is the paper in question. You will see that in addition to getting the title of the paper wrong, the paper actually says the exact opposite to what they are claiming. So be careful.

3. Don’t blindly assume that young earth organisations get their facts straight.

Most of us who work as Christians in science, technology or IT have very serious concerns about the quality, integrity and even honesty of what the young earth creationist organisations are touting as science. Please make sure that you properly understand what these concerns are and why we have them, and that you can provide us with a coherent and satisfactory explanation of why our concerns should be unfounded, before you start accusing us of “compromise” or “apostasy” or calling us “faithless so-called Christians.”

Young earth creationists often tell me that science must fit Scripture, and not the other way around. That’s fair enough, but fitting science to Scripture means first and foremost that it must be honest in the way that it handles weights and measures (e.g. Deuteronomy 25:13; Proverbs 11:1). It must be free from arithmetic error. It must not fudge or cherry-pick the raw data. It must neither exaggerate nor downplay the significance of uncertainties and discordances. It must not take shortcuts. It must verify its integrity by testing against controls where appropriate. It must not misrepresent the extent or nature of the evidence. It must not quote mine. And it must not be resistant to reasonable critique.

These are basic rules of honesty and quality control. To break them in order to “fit Scripture” is neither scriptural nor scientific.

I’m sorry to have to say this, but I’ve seen far too many claims of evidence for a young earth that fall far, far short of these standards. Absurd new laws of physics, such as accelerated nuclear decay on a scale sufficient to vaporise the earth, are proposed on the basis of tiny sets of cherry-picked data with huge error bars. Vast swathes of rigorously cross-checked, high-precision radiometric and astronomical data are rejected in favour of very low-precision, highly variable metrics such as the amount of salt flowing into the sea. A small fraction of discrepancies of just a few percent are held up as evidence that all dating methods must be in error by a factor of up to a million.

In many branches of real-world science and technology, if you adopted this kind of approach, you would kill people.

I’m not so well placed to judge their arguments about evolution, on the other hand, since I’m not a biologist. All I can say in that respect is that while I never found the “traditional” evidences for macroevolution and common descent—the fossil record, embryology and so on—all that convincing, there has been a lot of evidence coming forth in the field of comparative genomics and computational biology in the past twenty or thirty years or so that I haven’t yet seen adequately addressed by them. (Much of this evidence comes from the Human Genome Project, which was headed up by an evangelical Christian, Francis Collins.)

In the end of the day, the only way that the earth can be less than ten thousand years old is if it were created with the appearance of age and with evidence for 4.5 billion years of history which never took place. Personally I don’t believe that this approach is Biblically necessary in the light of Scripture verses such as 2 Peter 3:8 and Psalm 90:4, and in fact it seems to me to be inconsistent with the character and nature of God (Romans 1:20; Psalm 19:1), but if you see it differently I’ll leave it with you. But to claim that the scientific evidence supports a young earth, or that it can be reinterpreted to support a young earth, or that we only get old-earth results because of old-earth worldviews and assumptions, is simply not an honest option.

4. Don’t automatically assume that those of us who accept an old earth—or even evolution—are “compromisers.”

One of the more troubling aspects of the main young-earth organisations is their extreme dogmatism about the subject. They teach that the authority of the entire Bible stands or falls on our ability to read Genesis 1-11 as if it were a scientific paper in a peer-reviewed journal, that their Literal Six Day Young Earth Creationist approach is the only Biblical one; and that any old-earth alternative is “compromise” if not outright apostasy. Answers in Genesis even denounces the Alpha Course as “undermin[ing] the entire authority of the Scriptures” because it acknowledges a diversity of opinion among us as Christians as to how we approach the subject.

This despite the fact that there are old-earth approaches to the Bible, such as the day-age interpretation and the Gap Theory, that are every bit as literalistic (dare I say “fundamentalist”?) as their own.

I’m sorry, but when there are two valid approaches to the Bible, one of which fits with science and the other which does not, demanding that we all go for the one that does not, and raising accusations of apostasy against anyone who disagrees with you, is being anti-science for the sake of being anti-science, and choosing conflict for the sake of conflict. In other words, it’s divisive.

Colossians 2:8 has this to say:

See to it that no one takes you captive through hollow and deceptive philosophy, which depends on human tradition and the elemental spiritual forces of this world rather than on Christ.

Note the last four words say “…rather than on Christ.” They do NOT say “…rather than on the age of the earth and non-evolution.” Making a Literal Six Day Young Earth Creation the foundation of your faith means you are making something other than Christ the foundation of your faith. We are Christians, not Adam-and-his-pet-T-Rex-ians, for crying out loud!

Those of us who are untroubled by the scientific consensus recognise this fact. We may not have all the answers, but we realise that the questions are only of secondary importance to the Bible’s primary message of redemption from sin through Jesus Christ. Don’t damage the witness of the Gospel by tying it down with unnecessary absolutes, and don’t pollute it with dishonest scholarship. Remember that in Acts chapter 15, the Council at Jerusalem declared that they should not burden Gentile believers by demanding that they should be circumcised. Don’t put heavy loads on people’s shoulders that you don’t know how to carry yourself.

Don’t buy into the misconception that “natural” processes and God’s action are mutually exclusive. The Bible talks about God forming us in our mother’s womb (e.g. in Jeremiah 1:5) but I’m sure you’re happy with the idea of reproduction and babies being formed in their mother’s wombs as a “natural” process and that you don’t see any kind of conflict there. In any case, there’s nothing about science that says that miracles are impossible. Personally I believe that miracles serve a specific purpose—namely, God communicating with us (the Bible refers to them as “signs”)—but some may see them more frequently and in other contexts as well. That’s fine—it’s perfectly okay to have discussions such as that.

Don’t worry about science stripping away the awe that you feel when watching a sunset by explaining how it works. Far from stripping away awe, science reveals new layers of awe underneath. Learning about how God’s creation works is an exciting journey of discovery.

5. Don’t be afraid to disagree, but do so constructively and graciously.

There’s nothing wrong with disagreement. We techies thrive on it—it challenges our presuppositions and spurs us on to learn new things. However, it’s important that you disagree constructively.

The BioLogos Foundation has some guidelines on their forums about how to debate creation and evolution—or indeed any other subject—graciously. These are:

  • Focus on a commenter’s arguments, rather than an assessment of their character
  • Contribute thoughts to the topic at hand, rather than veering discussion off-topic
  • Assume legitimate Christian faith on the part of other commenters, unless they identify otherwise
  • Show eagerness to learn from perspectives of others, rather than simply reminding others of the rightness of your own position.

Another important article that everyone should read before entering into the debate is “How to Disagree” by Paul Graham. In this article, he outlines a hierarchy of seven disagreement levels:

DH0: Name-calling “evolutionist” “compromiser” “faithless so-called Christian”
DH1: Ad-hominem “Of course he would say that. His job depends on him accepting evolution.”
DH2: Responding to tone “Aren’t you being a bit harsh in your assessment of creationism?”
DH3: Contradiction That is only your opinion. Evolution is only a theory.”
DH4: Counterargument Endogenous retroviruses are not evidence for evolution. There are other explanations.”
DH5: Refutation “Endogenous retroviruses are not evidence for evolution because they do serve specific functions.”
DH6: Refuting the central point (Insert your coherent non-evolutionary explanation, with evidence and links to your sources, that specifically addresses why identical endogenous retroviruses occur in exactly the same places in human and chimp genomes here.)

Try to keep your arguments as close to the eloquent and persuasive end of the disagreement hierarchy (DH5 and DH6) as possible. Name-calling will only get people’s backs up and be counter-productive. On the other hand, a coherent and well-thought-out explanation, with evidence, as to why we may have misjudged the YEC organisations, will be far more persuasive and helpful.

Above all, don’t be unduly hostile towards science in general and science-minded believers in particular. Anti-scientific attitudes in many churches are having a thoroughly toxic effect on many branches of Christianity today. In 2011, Barna Research published the results of a study in which they learned that one of the top three reasons why young Christians feel disconnected from their churches, or even leave them altogether, is that churches come across as being hostile to science. For some of us, science and technology is God’s calling on our lives—our mission field, if you want to look at it that way. Make sure you can support us in that calling, not drive us away or undermine us because you’re afraid of it, or because you don’t understand it, or because you think you understand it when you don’t.

In the end of the day, how we relate scientific discoveries to the Bible is a complex technical subject to which we may never have all the answers. There are sincere differences of opinion between us as Christians about how we approach the matter, just as there are sincere differences of opinion as to whether there will be a pre-Tribulation Rapture or not. But we do need to make sure our discussions are informed and accurate. The Bible has far, far more to say about the need for honesty than about either the age of the earth or evolution, and in the current climate of “fake news” and “alternative facts,” we are called as Christians to be a bastion of honesty. We will do ourselves no favours if we are less than honest in our approach to the Scriptures and science.

How to keep lab notes as a software developer

My decision to start keeping lab notes, research scientist style, in my work a couple of months ago has started to pay off. By constantly writing down everything I do, when I run into trouble with what I’m doing, I am able to go back over my notes quickly and easily and see exactly what I did. As well as making for a much more disciplined approach to working, it’s helped to clarify my thoughts, and to avoid situations where I might end up spinning my wheels rather than getting to the heart of the matter.

Here are some tips.

1. Choose the most low-friction solution you can get your hands on.

It is very important, especially in the early days when you are just getting used to the discipline, that you choose a solution that is as frictionless as possible.

You are establishing a habit. Those who study these things tell us that it can take several months for a habit to become established to the point at which it seems easier to do it than not to do it, and until you get to that point, anything that tempts you to take shortcuts needs to be resisted and ruthlessly eliminated.

For me, I find that Microsoft Word works fine. Our project manager tried to persuade me to use Jira, so as to have everything in one place, but Jira’s quirky markup syntax, combined with having to type into a tiny input field in a web form, made this a frustrating experience. It’s better to write it in Word and then copy and paste into Jira later if that is what is needed.

2. Write down everything you do, as you do it

Lab notes work best if you write down what you’re going to do before you do it rather than after the fact. In that sense it’s a bit like test-driven development: write your tests first, then write the code that makes them pass.

This has two benefits. First, it is more accurate and more complete, because you’re less likely to miss out details. Secondly, it has the benefit of forcing you to think clearly about what you’re going to do.

This also makes your lab notebook a record of your stream of consciousness. As such, you will be spending at least as much time in your lab notebook as you are in Visual Studio, or vim, or whatever your IDE of choice happens to be. This is another reason why you need to go for the lowest-friction solution you can get your hands on: even small amounts of friction will chafe at you, and will tempt you to ease off and take shortcuts.

When you’re waiting for a slow compilation or test run to complete, use the time to write down what you’re going to do next. This is a far more effective use of the resulting downtime than reading Reddit or Hacker News, and it’s also a whole lot easier to context-switch back to what you were doing once you’ve finished.

3. You can not be too detailed.

The purpose of lab notes, as with any other form of auditing, is to answer questions. For example, one such question that we all ask, time and time again, is, “I encountered this error before. What did I do to fix it?”

So for instance, if you encounter an error message, copy and paste the message into your notes. Write down exactly what steps you took when it happened. Write down exactly what steps you need to take to reproduce the error. Write down exactly what tests you carried out in order to troubleshoot it, and exactly what the error messages were. Write down any relevant Google searches, and copy and paste the URLs of the web pages that they led you to.

4. Write down your train of thought when you’re planning and designing your code.

Use your lab notes as a scratchpad to plan what each script, each method, and each command should do. How does it store state? How does it identify if it’s been run before? What should it prompt the user for, how, and when? What should the default values be? Why did you give things the names that you did?

It’s actually a lot easier to write code this way, because you’re holding less information in your head at once, and it’s much easier to pick it up again if you break off. It’s also easier to comment your code, because you can just copy and paste some of your design decisions into your source code or your wiki if necessary.

5. Don’t worry too much about making your notes look good.

You aren’t writing documentation, or a final report, or a thesis, or a sales pitch, or a blog post. You are only writing rough notes to remind yourself, or keep your colleagues up to date, about what you’ve done.

Just write it down in the first person (“I ran this command on the command line.”) There’s no reason why you should get all formal and write it down in the passive voice like you typically encounter in scientific literature.

6. Use a searchable text format.

I personally use a Microsoft Word document. Some people use plain text files, or a note-taking application such as OneNote or Evernote. You can also get specialised applications devoted specifically to laboratory note-taking. LabArchives is one such example—a web-based SAAS lab notebooking platform.

While you may be tempted to record error messages or other data as screenshots, bear in mind that you will almost certainly want to search for them again in the future. Record them as text wherever possible.

For the same reason, it’s best not to use a physical notebook unless you need to do so for legal reasons. Scientists often use handwritten lab notes for patent protection purposes, but this isn’t really necessary, since there are electronic solutions that can provide a dated audit trail if needed.

7. Make your notes append-only.

You may be tempted to go back and tidy up your lab notes afterwards, but this is a temptation you need to resist. They are an audit trail, not a design document, nor a presentation, nor a manual, nor a sales pitch. Tidying them up may make them look pretty, but it undermines their integrity, and besides, it’s a waste of time.

You may want to copy and paste from your lab notes into your presentation, your design document, your wiki, or your code, but the tidying up should take place in those other documents. What you have written in your lab notes, you have written. Just move on.

8. Use your notes as a source for documentation, commit summaries and pull request descriptions.

A well maintained set of lab notes will make it much easier to compile a detailed commit summary, or a wiki page, or a pull request. Just copy and paste, and then edit to tidy up as necessary.

I frequently draft out a first version of documentation in my lab notes themselves. That way all I have to do is to copy and paste.

9. Share your notes with your whole team.

Your colleagues should all be able to refer to your notes should they need to. For example, a git bisect session may reveal that Alice was the author of a commit that introduced a bug in your payment processor on a certain date. If you can refer back to Alice’s notes on that day, you’ll have a much better idea of why she made the decisions she made, and you will be able to see how to fix the problem without breaking the new features she was working on herself.

Having said that, I’m not all that keen on the idea of having a single set of notes for the entire team. It can easily get unwieldy if everyone is working on different parts of the codebase, so it’s generally better for each individual to have their own set of notes that they write to. All in all, your mileage may vary on that one.

10. Don’t make your notes public.

If you are working on private, closed-source code, your lab notes will contain a whole lot of proprietary information. They will give your competition the heads-up about what you are working on, allowing them to beat you to market. They may also be of legal importance if your company is ever involved in a patent dispute.

Even if you are working on an open source project, there is another good reason why you should keep your lab notes private: security. They will contain a record of the exact details of any security vulnerabilities that you investigate, and any steps that you take to reproduce them. If hackers get hold of this information, you’re asking for trouble.

11. Learn from your mistakes.

If you ever find yourself asking a question about what you did last time, and your lab notes don’t answer it, that is an indication that there was some kind of information that you didn’t write down because you thought it was too trivial.

If this happens, make a note of exactly what kind of information you hadn’t written down that you should have, and write it down in future. Don’t assume that you won’t need the same kind of information again a third time. If you’ve needed it twice, the chances are pretty high that you will.

Keeping lab notes may come naturally to some programmers, while on the other hand, for others it may require considerable effort. But in the end of the day, practice makes perfect. The more you do it, and the more critically you examine your approach to it, the better you’ll get at it and the easier and more natural it will become.

SQL injection is the FizzBuzz of web security

FizzBuzz is the (in)famous interview question designed to filter out totally unqualified candidates for a programming job at a very early stage in the process. The kind who can’t solve even the very simplest programming problems and who would be wasting your time and money if you called them in for an interview after the phone screen.

You can—and should—do something similar for web security. Take a look at this snippet of Python code:

def check_password(username, password):
    db = MySQLdb.connect(passwd=DB_PASSWORD, db=DB_DATABASE)
    c = db.cursor()
    c.execute("SELECT password from tblUsers " +
        "WHERE username = \"" + username + "\"")
    row = c.fetchone()
    if row:
        return row[0] == password
        return False

Did you spot the problem? If you have any significant experience at all as a web developer, it should stand out to you like a sore thumb. You should be able to spot it in seconds, even if you have never used Python before in your life. Even if you’re the kind of .NET-only developer who insists on being spoon-fed by Microsoft and believes that Python is a dangerous heresy, it should still be glaringly obvious to you.

A couple of years ago, I used a similar question to this one on a number of interview candidates—some of them with twenty or more years of experience at a variety of impressive sounding companies. Yet it shocked me just how many of them required very heavy prompting to see it.

If you’re interviewing a candidate for a software developer role, show them this snippet of code. If they can’t tell you in seconds that it contains a SQL injection vulnerability in line 5, don’t hire them. If they can’t tell you why it’s a SQL injection vulnerability, don’t hire them. No exceptions, no excuses.

SQL injection vulnerabilities are quite frankly inexcusable. Out of all the different kinds of security vulnerabilities that you can get, they are the easiest to understand, the easiest to spot, and the easiest to avoid. Anywhere that you see user input being smashed together with any kind of instructions—SQL, SPARQL, LDAP queries, whatever—it should raise a massive red flag. A candidate who can’t spot security vulnerabilities will write security vulnerabilities (or more likely, copy and paste them from the Internet)—and if they can’t spot the simplest vulnerability of the lot, they’re going to have trouble even understanding more complex ones. And that’s before you even get started on other aspects of programming such as data integrity or performance.

With the rise of ransomware and other increasingly nasty exploits, you simply can not afford to be careless or blasé about IT security these days. As software developers, we all have a responsibility to make sure our knowledge and skills are sharp and up to date in this area, and as a recruiter, you can’t afford to take on anyone who isn’t taking this responsibility seriously.

Finally: there is a second glaring security flaw in this snippet, and candidates should be expected to spot it as well. I shall leave that one as an exercise for the reader.

Some thoughts on CQRS and Event Sourcing

CQRS and Event Sourcing have had quite a bit of a following among some developers in recent years, especially among the “passionate programmers” in the .NET ecosystem, who have been touting it as a Best Practice. They tell me that it can provide significant benefits when it’s done right, even on small projects.

This may or may not be true. The principles behind CQRS and Event Sourcing look fairly straightforward and the benefits seem clear enough. It does add some extra complexity to your architecture, but it does so in order to solve specific problems. If these are problems that the business is actually asking you to solve, and you’re taking care to keep the extra complexity under control, then you may well be doing CQRS right.

Unfortunately, I’ve more experience with projects that have got CQRS wrong than with ones that have got it right. Some of the worst examples that I’ve seen have been so bad that they made me think of Poe’s Law.

“Without a winking smiley or other blatant display of humour, it is impossible to create a parody of enterprise software best practices that someone won’t mistake for the real thing.”—Poe’s Law, Enterprise Edition™

The principles of CQRS and Event Sourcing may be straightforward enough, but the implementation is a different matter altogether. It’s very easy to end up over-complicating it, and combined with the tendency of many .NET developers to split up their solutions into far more projects and far more layers than necessary, the result can be borderline unmaintainable. I’ve seen one example that required thirty-six files to be edited in order to add a single column to a database table, and another that contained no less than thirty-nine projects in a solution consisting of a single three-page CRUD application that was only ever used by one person once a week.

One sure-fire way of doing CQRS and Event Sourcing wrong is failing to get your entire team on side with it. You may think it’s a better mental model, but the people who are going to maintain it after you need to think the same. This includes not only your domain modelling experts but also your infrastructure and DevOps guys, project managers, and anyone else who is likely to be affected by it. DevOps will want to know how you’re going to handle schema migrations, for example. HR and your project managers will want to know what skills to look for when recruiting, and how to interview for them or provide the necessary training.

I know one project that ended up being completely rewritten because the team of CQRS aficionados who built it failed to put any of this in place. They were all contractors who left without training up any of the organisation’s permanent staff in it. The result was that nobody was able to understand the codebase, let alone maintain it, and it ended up being rewritten from scratch as a conventional BOL/BLL/DAL application. The team who did so now automatically puts any CV they receive that has CQRS listed on it straight into the bin.

Another way of doing it wrong is as an exercise in CV driven development. Some people introduce CQRS and Event Sourcing into a project that they’re working on for no reason whatsoever other than to be able to list it on their CV. Don’t even think of doing this. Besides the fact that it’s stealing from the business, you’ll just end up misunderstanding it, building something that isn’t CQRS, that doesn’t solve the problems that CQRS is supposed to solve, and that over-complicates things without providing any benefit whatsoever. Ideally, you should have at least someone on your team with serious experience supporting and maintaining a legacy CQRS app in production before you try using it on greenfield work, so they can tell you what pitfalls to avoid. Like, for example, when not to use it.

I’ve no doubt that CQRS and Event Sourcing can provide significant benefits when used correctly. However, at the end of the day, any technique, tool or practice will have costs as well as benefits, whether in terms of infrastructure, training, support, maintainability, or general increased complexity. These costs need to be justified by benefits that the business is actually asking for, otherwise you will just be wasting everybody’s time and money.