Listen to this post
Reading Time: 5 minutes
image_pdfimage_print

A software development philosophy guides every developer throughout their career. Some adhere to prevailing philosophies that are written down in books or written down in code. Some invent their own beliefs based on their view of the software world.

My philosophical influences come from the likes of Domain-Driven Design, Test Driven Development, the Agile Software Development Lifecycle, and a multitude of others.

The following prose is an account of my software development philosophy.

Invest Lightly

When using distinct technologies, I try not to get wrapped up into the details. Technology changes constantly; light strategic investments provide more long-term value. I invest lightly with my keystrokes, so I have less code to maintain down the road.

Stay Liquid

I avoid technical debt like the plague. A technical debt mountain is no laughing matter; it will threaten the longevity of your business. I recommend paying the debt now, so you don’t pay more later. It’s frighteningly common to see million-dollar software development projects get scrapped and built for millions again. It’s more often cheaper to pay technical debt than it is to rewrite software.

Everything changes

When building code, I assume change is coming and sooner than expected. I craft solutions that are easy to change in the future to more economically address new business requirements.

Simplify Security

I create layers like bastion hosts to protect data rather than using software configuration files and leave configuration files permissive to reduce confusion about access rules. I often remind myself that the only secure computer is a dead computer, and you better be sure it’s dead.

Use the Right Tool

Languages are simply programming tools that exist to help us arrive at a solution. I think clearly about which tool will best handle any job.

In software development, many people cling to one tool and master it. It can be a great approach to master one tool; it will pay off big for some developers. I prefer to learn many tools and learn them enough to be productive.

follow the 80-20 rule when learning new tools so I can quickly get up to speed with its use cases.

Use Cases

It is of paramount importance to limit the use cases of software. Command-line utilities are easy to restrict use cases with while user interfaces are not. I do not attempt to handle every use case to avoid introducing a diverse collection of bugs. If a solution is fulfilling too many complex use cases I consider creating a new solution.

Writing down a clear definition of use cases sets a clear contract between myself and users. When people use software outside of an intended use case I use documentation to help determine if I have discovered a valid use case.

If I am creating general-purpose software, I limit the use cases as much as possible to general-purpose features that can be extended.

Versioning

When building software, my philosophy is to version most things. I keep versions pinned, so upgrades don’t happen without a developer’s knowledge and seek a balance between keeping software up to date for security reasons and letting sleeping dogs lie. I abide by the rule; if it’s not broke, don’t fix it.

Naming Things

When naming variables, I name them in ways that make it easy to rename them. I call things exactly what they are and avoid overloading or overusing the same variable name.

Tracer Bullets

I make heavy use of tracer bullets to punch a hole in the walls between myself and a solution. I’ll pick a requirement that exists far away from the end solution and meet it head-on. I’ll use scattershot shotgun methods to prove use cases, theories, and the viability of a solution before investing time and money in building robust solutions.

Driving Business Value

Everything I build has the end-user requirements placed front and center in my mind. Having a fancy contract with a lot of complexity won’t help sell more products than a simple one. If I can’t rationalize why a feature provides the highest value at a given time, I’ll raise my hand or simply change course on my own.

Single Responsibility

I keep software components isolated with a single responsibility and create user interfaces that have a single responsibility to reduce complexity. I keep tools divided from one another in a way that is logical for users and other software developers, and I follow SOLID principles when creating object-oriented software solutions.

Be Empathetic

I work diligently to understand what people need to do with the software I build. I ask why five times to understand the real problems and keep the big picture in mind. Empathy for people is a cornerstone of a robust software development philosophy.

Automate Everything

Automation

I automate tasks religiously. If it’s hard to automate something and it will cost a fortune to automate, I consider a different solution.

Decouple Everything

When tight couplings exist for no good reason, I will decouple them. I summarily dismiss software libraries that aren’t dependency injection ready. I refactor tightly coupled code to reduce complexity and prepare it for change.

No Perfect Solutions

I know that picking the best solution, at the moment, with all the facts laid out, is the way to avoid analysis paralysis.

I don’t believe in the Nirvana fallacy and make the best decision possible at The Last Responsible Moment, yet at the same time, I take big architectural choices very seriously.

I know that solutions can’t be fast, cheap, and good at the same time yet strive for the center of all three.

A Software Development Philosophy Evolves

My software development philosophy is evergreen. It changes after learning new things. This account of my development philosophies is nowhere near complete, and it never will be. As always, a great magician never reveals all his tricks.

I refine my software development philosophy regularly in the spirit of continuous improvement.

Develop your own philosophy

Here are a few books that will help you develop your own software development philosophy.

Share this post