Yes, We Can Build Better Software

I’ve spent a good 18 years building software and I’m so grateful to have found something that matches both my interests and skills. To even say that aloud is wild! And although a ton of things have changed there have been an equal amount of things that have stayed the same; some things more welcome than others!

Among the more welcome (and exciting) things that have changed are the introduction of new and more powerful languages, technologies, and platforms that are enabling more people to build solutions faster than ever before.

The tools have also gotten better and the rise of “frameworks” and discrete methodologies have allowed the conversion of ideas into real software to become even more resource efficient. For instance, these things have allowed me to dip my toe into the “indie” software development world deeply and I’ve been fortunate to have some of those projects do quite well!

But even with the growth and emergence of all of these newer and more powerful tools it is still just as hard as it ever has been to build a thriving business through software. In other words, although we can build all the software that we’d ever want and hope and dream for, our ability to transform those products into money-making companies is still very much of a challenge.

You see, what I’ve come to realize is something quite profound: There is an ever-widening gap between “good” (or mediocre) software and “great” software, where the latter are the types of software that customers will use and enjoy and who will express their appreciation through purchase (and continued financial support through monthly & yearly subscriptions).

One part of the “gap” is the connection between engineering productivity and verifiable business metrics. I’ve seen this in large enterprise companies as well as the young, early-stage startup, as both a leader and as an engineer / individual contributor.

In both cases (and from all sides), everyone simply wants to know whether the engineering work being done is actually moving the ball forward; if the amount of productivity was helping the business simply make more money.

This is especially poignant for the engineer since I always wanted my work to “count” and to make a difference. It just wasn’t enough that I built such-and-such technology or contributed to such-and-such product: I wanted to know that I was really helping the company build financial velocity and momentum. There’s nothing more depressing than not knowing if my work was really making an impact (and not having great engineering work noticed or accounted for).

And, on the flip-side, as I grew from individual contributor to technical manager and then senior leader I wanted to know how to best manage and support my technical and engineering teams and individuals.

To be honest, as I take a moment to reflect on my previous roles as manager I have to admit that a lot of my management decisions were based on “hunches” or educated guesses around productivity and not on concrete facts or real intelligence.

So I’ve begun investigating and hacking on some ideas that might be able to fill the gap(s) of information, that may fill the void of engineering intelligence, and enable individuals, teams, and organizations build better software.

And that matters, a lot. If better, more powerful infrastructural tools can be created that help developers, software teams, and organizations as a whole know, with certainty, the relationship between engineering work and business metrics, then everyone wins.

The result(s)? Companies will build better software. Engineers will know that their work matters and be motivated and incentivized better and build better software. And customers will encounter and purchase better software (and stick around longer).


So, that’s the mission: Build Better Software.

I’m calling this project “Pinpoint” for now but I imagine this will change as I get more feedback and as the project and product gets more fleshed-out.

I’d love your feedback, support, and thoughts around this topic! Please subscribe to the email newsletter, follow on Twitter (@WhatisPinpoint), and ping me any time.

Oh, and “Hello World”.

Also published on Medium.

2 Replies to “Yes, We Can Build Better Software”

  1. I’ve been trying to build better software since the 80’s. Like you, I wanted to know my work was making an impact, but over the years, the kind of impact desired has changed. What I build now needs to help people (the end user) in truly meaningful ways. Simply helping an employer do better financially is no longer rewarding, unless that employer is myself as an indie, and even then it’s a secondary goal.

    1. Scott, thanks for being the first-ever commentor! *BOOM*

      Second, I’ll spend a bit more time fleshing this out (or asking for people’s specific perspective and advice) but what I want to do over the next few weeks is think through the tooling that we currently have available and the gaps that still exist.

      In other words, what would YOU build for developers like yourself? What do you need the most so that you can do a better job of building better software?

Leave a Reply