Hi and pleased to meet you!

My name is Steve Butler and I’ve been creating software professionally for the past two decades.

Over my career I’ve avoided specializing in any one area, and have been lucky to experience many facets of this crazy business of Software Development. I’ve overseen projects spanning enterprise, desktop, and mobile development. I’ve built efficient back-end components for high-volume enterprise systems as well as sophisticated, intuitive, and engaging User Interfaces. I’ve scripted build systems. I’ve led several teams in delivering software that’s high-quality and on-schedule. Last year I joined on as CTO and co-founder of Trot With Spot Inc., an early-stage start-up company. Working with this team has been an opportunity to flex my full range of technical skills towards building a project I deeply believe in from the ground up, and I love it!

I created this blog as an outlet for my thoughts on Software in general, and to showcase projects of personal interest. To kick it off in style I created the WordPress theme, which you can read about here.

I’m currently situated in Toronto, Canada, and always interested in meeting people with new ideas and perspectives. If, after looking around the site, you think that we’d collaborate well on a project, then let’s talk!

My Approach

Over the years I’ve found myself growing into a certain perspective on development, which you’ll find reflected in the posts on this site. That perspective is perhaps characterized by some core beliefs:

1. “The end-user experience” === “software quality”
2. Software Development is a craft, and methodologies are the tools
3. Good software is more about people than machines
4. Trading off quality for development speed is usually not worth it

More on these principles below.

In recent years much has been written on the importance of focusing on User Experience and Usability. I was very glad to see these fields coming to the forefront of the conversation on software, because the end-user experience has always sat at the crux of my approach to development, although earlier in my career I’m sure I didn’t have the language that exists now to elucidate my feelings on the subject. Just as “the truth will set you free”, as developers nurturing a focus on the user’s experience will set us free…it has a beautifully clarifying effect on our oftentimes-mind-boggling jobs! When your end-users are happy, you’ve done your job….period! Software that delivers a satisfying experience IS high-quality software, period! Isn’t that simplicity itself?

Of course, because we are analytical people we love to componentize, fragment and over-complicate this simple truth until the next thing we know we have back-slid into talking about quality as a deliverable within a development lifecycle, and experience issues as some kind of future-improvement work or something to be tacked-on to a release as an afterthought.

In this day and age my view is that an enlightened approach to development must hold the best-possible understanding of the end-user centrally in its focus at all times throughout the process. This is of course easier said than done, but the good news is that there are many techniques available to a team nowadays to help achieve this goal.

I am often dismayed by what appears at times in our industry to be a prevailing obsession with the persona of the child genius who pours out a daily deluge of code. In other words: young, brilliant, with a supremely analytical brain which is highly-optimized for the production of “working” code in massive volume. While such people undeniably exist and have value, a mature industry should recognize many, many other roles and archetypes that add value to a software project. A failure to do so can in fact do serious harm to a software organization and its culture.

In my view organizations achieve better effectiveness by focusing on building great teams, rather than chasing the rock-star coder. Number of lines of code produced in a day is as inappropriate a metric for evaluating a team member’s value as whether the number of daily chairs produced measures the mastery of a furniture maker. This approach fails to ask some basic questions: how good are the chairs? and, are chairs even what people want or need?

In my experience some of the most amazing developers I’ve worked with do not fit the mould of the hyper-caffeinated teenage genius but are more akin to the master furniture maker, who over time has incorporated many, many different considerations and techniques into a mature, refined craft. The software builder’s craft is in essence a highly-optimized and well-tested process that has reliably delivered quality results when applied to a variety of projects, environments, and contexts. Like the master furniture builder, the best developers take a huge amount of pride in the quality of their work, take the time to make things right, AND typically achieve efficiencies allowing them to produce a high volume of work to boot. As such, developers in this mould are usually the most valuable contributors to a project. After all, isn’t that what you’d expect from someone who has poured their blood, sweat and tears into a personal pursuit of excellence over many years?

Another hallmark of the master software craftsman is a mind abstracted from whatever technology stack is being employed in a particular project. Development methodologies and design patterns are the aspects of software that keep cropping up again and again in projects of all varieties, and an experienced developer will have encountered and studied and internalized many of these patterns over time. The end result of those experiences for a mature developer is the cultivation of perspective and good judgement that a less experienced developer might not have. These hard-won qualities are what enable such developers to effectively asses which technique is best suited for the job at hand, whatever it may be, taking into account the full real-world context of the project for which it is being done. This judgement can be far more valuable to a development team than specific knowledge of a particular technology, which is often easily Googled.

This principle is related to my first point about user experience being the same as software quality. As a developer the code you write is being consumed in multiple ways: by the end-user via its functionality, but also by many customers internal to your team now and in the future. These people are using your code for various purposes: maintenance, re-purposing, configuration and release management, product documentation, customer support, etc. As a developer you should be taking some responsibility for the experiences of all of your customers. In addition to always keeping the end-user in mind, you should also be considering the experience of the next guy or girl who comes along and has to interact meaningfully with the section of code you are writing.

For most types of development, solutions that are obscure but marginally better-performing are rarely worth the increased costs they represent to these downstream customers, especially if you are making no effort to communicate your intentions to these people. The reality is that many bugs are written by people under extreme time pressures who do not have time to fully understand the section of code they are working on. If the original developer has made no effort to minimize this potentiality is it fair to lay the blame for these bugs entirely on those developers’ shoulders? Those that would choose to do this are in fact hurting the team’s work, not helping it.

And so I feel that it is another myth in our industry that good developers must be machine-like themselves. Human qualities like empathy and intuition play a huge role in software development for the simple reason that all code is ultimately written by humans, for humans. All things being equal, if two code components pass the same comprehensive test suite, then it is the more intuitively-written of the two that is the better component. Of course there are exceptions to this rule, such as when extreme run-time efficiency is a core requirement, but generally-speaking the human effects of code are second only to the proper functioning of the code itself. In some cases a buggier component that is easily fixed is better than a highly efficient component that can’t be touched for fear of breaking it, because all code needs to be modified eventually if it is to be called a valuable asset.

In our manic industry we developers often find ourselves being pressured to cut corners in order to meet aggressive deadlines. If you accept that there is some truth to my first point, that quality equals user experience, then it stands to reason that cutting out quality in some way results in a worse end-user experience. So we must ask ourselves, is it true that our stakeholders want to shove a visibly sub-standard piece of software out onto the market? Unfortunately there are situations where this may be the case (especially since the advent of the update manager!), however if projects are being properly managed we hope this is not the typical case in most company environments.

The truth is that bad quality hurts everyone! It hurts the end user by causing them stress and wasting their time (at a minimum). It hurts the organization when those angry end-users form an association between their current frustration and the brand that incited it. And it hurts the project team member’s reputations as people who can produce good value. While many pressures can be brought to bear in an organizational environment, it is the developer’s (among other peoples’) role to stand up for quality over speed.

The other ironic side of things is that by compromising quality on a regular basis, a team can actually train itself to produce poor quality work! When this occurs the team is in a downward spiral of racking up technical debt (in other words, expense!) with every deliverable it puts out! This situation can only be bad for the members of that team as others will take notice, sooner or later. On the flip side, the team that commits itself to always delivering uncompromising quality will not only help to protect its own reputation, but will often discover ways to achieve efficiencies within its own environment that will allow it to meet aggressive deadlines anyway! In other words, I believe strongly that developers only skimp on quality at their own peril.

…Well, there you have it! Now that you have an overview of how I see the world I hope that you are able find something of value in what I write on this site.

Steve