A Software Development Philosophy
I fell into software development sometime in the middle of the first .com boom when the web was still young and sexy and it felt like a new frontier of possibility had opened up.
If I’m honest when I started I didn’t really know anything about programming, I’d played around with BASIC as a kid but had never really been bitten by the bug, but armed with some elementary skills gained through night school and a lot of enthusiasm to do something (anything!) with the web, I walked into my first proper job as a web developer.
I grew into my role, acquiring skills and experience as I went but not really having anything to glue it together. You could say this was because I’d not come from a proper computer science background but I met plenty of people who had who weren’t doing anything differently. Skill was judged by the languages you knew, the certificates you’d gained and the minutia of detail you knew about obscure technical points as opposed to how readable your code was or how much it aligned with the Domain you worked in.
I’ve always liked reading philosophy, I was an eclectic reader even as a young kid and I’d worked my way through various philosophies and philosophers both eastern and western as I’d grown up. Gradually I met people who thought differently and I realised there was a wealth of information that wasn’t just focused on the next new release of C#, this information opened up a depth to writing code I hadn’t realised existed.
TDD and BDD, Design Patterns, Domain Driven Design, Agile, Lean, all taught me something. The problem was that even armed with these methodologies, how do you tie them together into a coherent whole? When you have a hammer everything looks like a nail, when you’ve just read a book on design patterns everything looks like it needs an adaptor or a strategy.
Writing a few tests does not make your code better and safer, really understanding Test Driven Development and how it relates to Domain Driven Design and User Stories will. The whole is greater than the sum of its parts, but only if you look past the mechanics of technique to what binds them together.
As I’ve grown in my experience I’ve tried to construct my own theories that allow me to place these things in a wider context, so what I’m sharing here is my current philosophy, one that I feel gives a wider meaning that is greater than each thing on its own.
I’m not the first to do this and I don’t expect everyone to share the same views, but I hope you find value in the approach and that by sharing these thoughts you’ll be inspired to reflect on your own practice and perhaps think more deeply and find your own philosophy.
Foundations
Writing software is fundamentally about making decisions, that’s what we do, we take a problem and find a creative solution by making a series of decisions.
So for me the overarching theme is what can I do to make my decisions better and more informed? This boils down to two things: language and constraints.
Language gives structure to our ideas, clear language equals clear thought and that leads to better decision making.
Constraint can mean many things, we’re constrained by the programming languages we choose (maybe not as much as you’d like if you’re using javascript), we’re constrained by our infrastructure and the hardware we use, but we can also constrain our behaviour. Consciously choosing our constraints can shape us in new ways, force us to think differently and ultimately improve the decisions we make.
Language of Magic, Magic of Language
The term ‘magical language’ may conjure (pun intended) fantasy grimoires, bearded wizards and the ‘Wingardium Leviosa!’ Latin of Harry Potter, but all language has real tangible magic. The ability to conjure vast worlds in peoples heads, transmit information from one time to another, move another human to tears or laughter remotely over vast distances of time and space
When we look at the language of computer code we are probably the closest to fictional magic as we ever could be, this is the language that can invoke actual action at a distance after all. Our inscribed words cast as spells into strange engines to create bound entities to do our will.
The famous Arthur C Clarke quote ‘Any sufficiently advanced technology is indistinguishable from magic’ is probably over-quoted but still very true, we live in a world where no one is going to call their child ‘Alexa’ anymore because the name has been changed into a magical incantation to summon spirits and a poorly trained AI feels scarily like sorcerers apprentice, magnifying the ill-thought commands of the spell caster.
So language in software is important but often I’ve found we developers focus on the programming language, C#, Java, Typescript etc, etc and not the language language, what words can we use to convey the most meaning and carry the most context.
This is why for me language is at the core of a development philosophy because it serves two purposes, it is instructions for the computer and a narrative for the developer. A story conveying the software’s meaning, context, and purpose. Good software should speak in the language of the business and domain it exists in, it should tell its story. Unfortunately a lot of thought is often spent on the communication with the computer, not with the humans.
I remember listening to a radio programme years ago where a group of poets were reading each other their work and then trying to improve it, at the time I thought it was massively pretentious as they spent half an hour debating what words they should use in excruciating detail, it was only afterwards it struck me that it wasn’t any different from a group of developers spending an hour debating the domain concepts in a piece of software.
Coding is poetry, the words we use are important.
We apply them in a tight structure to deliver the maximum whilst using the minimum. Think Haiku as opposed to Greek Epic.
Constraints
The second principle that underpins my philosophy is constraint. If the language is how you convey meaning then using constraints helps you pick the best structure to convey that meaning in.
Sometimes our worst enemy is the freedom of choice, the use of constraints are common in creative arts as a way to limit choices to provoke a creative solution within certain boundaries. Every famous style of painting used some form of constraint to both identify the style and focus the creativity, similarly blank verse in prose and Dogme in film are ways of using constraints to focus by limiting the options available.
TDD, Design patterns, ‘GIVEN, WHEN, THEN’ these are all techniques where we limit our options in order to make us think and apply creative solutions.
This only works however if we really take the time to explore and understand what each of these methods of constraint teaches us and how they can be used in conjunction with each other. Otherwise they become mechanical patterns applied without thought.
Take something like Object Calisthenics, rigidly applying that to everything you write all the time because ‘it’s the rules’ would not necessarily make your code better. Instead if you spend time really working with those (self-imposed) limitations in order to understand them you’re forced to think about and justify each of your decisions in a way that you might not have done before. And because of that it will have an effect on everything you do afterwards, whether you are strictly adhering to the rules or not.
Creativity comes from where our desire to achieve runs into the constrictions of our environment, the rules we operate under or the limitations we have chosen to observe. It’s this restriction that forces us to think of problems in different ways.
Conclusion
Over the next few articles I’m not going to introduce anything new, pretty much all of the concepts have been around for 20 or 30 years, but what I hope to offer is a way of framing them as part of a greater whole, highlighting the connections that run through them and bind them together.
Like taking disparate threads that have often been collected over years and weaving them into a tapestry together, we end up with something stronger and more resilient both in the code we produce and the way that we think.
