Alastair Smith

You’re writing code that works, and is covered by tests; if you’re not also clearly expressing the intent of your code, though, you’re only doing half your job. Programming languages are like any other language — a communication tool — and they can be learned as such.

Using the Four Rules of Simple Design as a starting point, this talk will cover the implications of those rules, why you should care about them and review your code against them, and how they naturally lead to more expressive code. We’ll look at examples and anti-examples of expression in English and code. At the end of the talk you will be able to use your programming language to clearly express a program’s purpose and stop writing the programming equivalent of legalese.
[who-for]

“Startups don’t have time for that TDD nonsense!” “We might not be here in 3 months’ time, let’s just hack it in.” “There’s no point putting in that extra work because we might pivot – remember the YAGNI principle”

Start-ups are fast-paced, thrilling, and exciting. They can also be highly pressured, with encouragement to cut corners to complete something faster. That encouragement is common in a number of development shops, but more accepted in start-ups when the very survival of the company is on the line. The XP practices adopted by the Software Craftsmanship movement such as TDD and CI/CD, rather than being something slowing down delivery, in fact can be the lifeblood for the continued success of a start-up.

Since September 2016, I’ve been working for a start-up and have found the principles and practices of Software Craftsmanship more important than ever. We’ll look at how the perfect is the enemy of the good, how the easy is the enemy of the simple, and why “good” and “simple” are things start-ups really should be aiming for.

[who-for]

Human error is the greatest cause of software project problems and every software project is an exercise in managing complexity. What can we learn from successes in other fields to better manage complexity in our own projects?

Complexity arises in a number of professions, including surgery, aircraft flight, and construction. The first test flight of the Boeing B-17 “Flying Fortress” in the 1930s resulted in disaster. The highly-experienced pilot had made a simple error, forgetting to release the plane’s flaps before take-off, resulting in the death of two crew members. The B-17 was the most complex aeroplane yet developed, and the disaster occurred because the pre-flight procedure had too many steps to remember. Boeing, in conjunction with the US Air Force, investigated the crash and determined a deceptively simple solution: a checklist. Other professions caught on to this idea, and checklists are now used daily in surgery and construction to save lives.

In this talk, we’ll explore how to find and manage complexity effectively in software with our own checklists.

Software is eating the world, but few apps are useful without a database behind them too. As such, we want to ensure our database code is well-designed and tested. Test-Driven Development (TDD) is a good tool for software design, and as SPROCs are as much code as classes and methods, we can apply the same principles to unit test our database rather than integration test it via the app.

This talk will cover how to write unit tests for your database, which parts you should (and shouldn’t!) test, and how to run your tests automatically on a CI server, after which you will be able to write unit tests for your own SQL code and enjoy database development again!
[who-for]