Practical Differences Between Functional and Imperative Programming

I previously talked about what functional programming is by comparing it to other programming paradigms. This post expands on that post to talk specifically about practical differences between functional programming and the paradigm most of us are intimately familiar with — imperative. This post is punctuated with some quotes from the book An Introduction to Functional Programming Through Lambda Calculus. It’s worth noting that each of these practical differences are enabled because of the power of referential transparency. [Read More]

Why Functional Programming? The Benefits of Referential Transparency

Having covered what functional programming is, I wanted to spend a minute or two discussing why I want to learn functional programming in the first place. I’m sure we have all heard vague things about “side-effects”, “immutability”, and “composition”, but I wanted to dive a bit deeper on the topic to describe what — to me — is important about functional programming. Referential Transparency The key differentiating feature of (pure) functional programs is that they provide referential transparency. [Read More]

Overcoming Optimism with a Premortem

I’ve been reading the excellent book Thinking, Fast and Slow by Daniel Kahneman and came across a strategy for dealing with a common human behaviour problem that has direct impact on software development: overconfidence. According to Kahneman’s research, “overconfidence is a direct consequence of [how we think] that can be tamed — but not vanquished.” In other words, our brains are wired to make overconfident predictions and forecasts. [Read More]

What is Functional Programming?

I’m documenting my journey from functional neophyte to (hopefully) functional programmer by writing a series of blog posts on the topic. This is the first post describing what, exactly, the word functional programming means. Functional programming is a programming paradigm that lives alongside other programming paradigms. None of these paradigms have a precise, unanimous definition or standard, and there is not real agreement on which paradigm is better or worse for building particular types of software. [Read More]

Improving Test Coverage Using Exploratory Outcomes

In general, developers test features by focusing on the positive outcomes — the so-called “happy paths”. Unfortunately, this optimism can blind us to the less obvious or less probable outcomes that can cripple an application. I found one way to counteract this tendency is to try and “go beyond the happy path” by exploring the outcome of unhappy paths through a feature. I came across this idea in the excellent book Fifty Quick Ideas to Improve Your Tests by Gojko Adzic, David Evans, and Tom Roden, and expanded upon the book Writing Great Specifications by Kamil Nicieja. [Read More]

Bulk Generating Cloze Deletions for Learning a Language with Anki

tldr; Looking to learn a language using cloze deletions and Anki? Click here. One challenge in learning a second language is the sheer amount of vocabulary required for fluency. For example, one study has shown that the average eight year old knows 8000 words, while the average adult might know somewhere between 20,000 and 35,000 words. University graduates might know upwards of 50,000 words depending on their specialization. As an adult learning a second language, exposure to a lot of different words in their context is one of the best ways to learn vocabulary. [Read More]

Building Empathic Software Using Specification by Example

In most organizations, software development is split between two groups — product management and engineering. Product management is focused on building the right system. This requires product managers to meet with users, try and understand their needs, and develop solutions that meet those needs. To actually develop the solution, product managers must involve engineers who are focused on building the system right — writing the code, making it stable, and supporting it in production. [Read More]

How Fast Does it Need to be Anyways? The QUPER Model of Analyzing Non-Functional Requirements

We all know that a page that loads in three seconds will provide a negative user experience. But does having every page load in less than one second make a meaningful difference? How can you tell? When is enough … enough? Non-functional requirements such as performance are often not precise enough to be specified as discrete numbers. Rather, they work on a sliding scale of acceptability. Would slightly better performance be significantly more valuable from a market perspective? [Read More]

What is CQRS?

Bertrand Meyer first introduces the principle of Command Query Separation in his book Object-Oriented Software Construction. The principle states that a well designed object should have methods that are either commands or queries. A command changes the state of an object, but does not return any data, while a query returns data and does not change any state. By dividing methods into these two categories, you will have a better understanding of what does, and what does not, change the state of your system. [Read More]

Dissecting SQS FIFO Queues — Does Ordered and Exactly Once Messaging Really Exist?

At first glance, Amazon’s First-In-First-Out (FIFO) message queues provide an excellent feature set for business-critical scenarios. With FIFO, the order in which messages are sent and received is strictly preserved. With exactly-once processing, message duplicates are not introduced into the queue, and consumers control when a message is made available for redelivery. Reading past the marketing hype, how well do FIFO queues work in the real world? This article takes a deep dive into SQS FIFO queues to test the claims of message ordering and exactly-once processing, paying particular care to the conditions under which these claims hold. [Read More]