Good vs Great Software

Development for self

In the movie “Megamind”, the protagonist attempts to create a super hero to duel with after displacing the previous hero and taking over a town. When the poor choice in new “super hero” backfires and starts acting like a common thug, they start fighting the protagonist for “best bad guy.” During a witty exchange, the protagonist exclaims, “Oh you’re a bad guy all right, but you’ll never be a super villain!”. He goes on to explain later, that the difference was…Presentation.

My initial foray into writing code was to solve mundane problems that I was experiencing. Example: I built a python script to create a completely static, JavaScript free HTML site to share photos of my life in the Philippines. The tools were designed for me to use and they were not going to bring any kind of commercial success.

As I started thinking about developing “real” applications, I had a bit of a naive view that these companies creating applications were using bespoke code to do any and all tasks. It was daunting to think about creating some of the basic libraries that most web applications depend on in the day to day. It was a self-made myth that perpetuated for much longer than it should.

When I finally got into proper product development, I began to understand how to look through the fancy facade’s and see most applications for what they are: a pretty cover over a ton of string and duck-tape bringing libraries and tools together. At least for the security world, this was and has been true for a long time.

Now, my initial response to this revelation was disgust/dismay. I thought it quite unfair that these tools, which do amazing things, were not getting their fair piece of mind-share despite the fact that they were the true innovators behind products being purchased and sold. And I don’t think I’m alone in having that kind of reaction.

Here’s the thing, though.

I no longer see it that way.

Development for Others

At the end of the day, customers are going to use what works most intuitively for them and/or aligns most with their needs. Ideally, the solution hits home on both points. If you create a neat TUI tool that requires comfort in a terminal, you’ve shot your opportunity in the foot for most people. Your geeky peers might like it, but even they tend to be a finicky bunch (and there’s open wounds all over the internet to prove it).

Taking the time to design the User Experience is equally important as taking the time to design tool functions. A powerful tool encumbered by an awful experience is only going to cause pain in adoption, maintenance, and customer support tickets. A well executed customer experience might give you the opportunity (and runway) to make a well executed back end.

Pick your path

Not all development is meant to be shared. I have tons of little functions and scripts I’ve written to make my life easier and I have no intention of bringing those things to market. I have other projects, though, that I think should be adopted and can really help others. Over the last two months, I’ve reflected on this quite a bit and I have already seen it change how I approach development.

So to you, fearless person who read this far down the blog, I say think about who your audience really is when you go to build something. Not everything needs a clean polished look, but some things do and the earlier you can divine which approach applies, the more likely you are to meet the needs of your intended audience.