Lessons from a decade of software development
Today marks exactly a decade since I began professionally crafting software. Back then, Sparksuite was “Next Step Webs” and it designed websites for local small businesses. Here’s a not-so-flattering screenshot of its very first company website, circa 2009:
Next Step Webs, now Sparksuite, has come a long way since then (thank goodness). Most prominently, we’ve completely changed our business model to building software companies instead of providing website design services. I myself have gained a tremendous amount of experience over those years. Which is good, considering the original website literally stated I was fluent in HTML, but could only “read jQuery.”
To celebrate this milestone, I figured I’d share a few of the most notable lessons and truths I’ve learned from spending the last decade developing software and building software companies.
Lesson #1: Design with scalability in mind
It can be really tempting to cut corners in this area, especially if you work on projects as a one-person team. I’m guilty of having done this with early iterations of several of our software projects. And while it may save you time and effort at the outset, my experience has been that the growing pains down the road are almost never worth it.
With everything from choosing the technologies you’ll use, to organizing the codebase, to designing the workflows, keep in mind how a new project will scale in two major ways: more users and more team members.
The second is sometimes overlooked, especially if you’re working on your own. How will your Git workflow work with additional engineers? How will your team communicate as you expand to additional locations or hire remotely? How will multiple team members work on the same codebase with minimal conflicts?
We’ve invested a great deal of time on several occasions refactoring non-scalable designs to support growing userbases and growing teams. This slows down the release of changes your users will appreciate more, like new features and improvements.
Many of us are familiar with Paul Graham’s famous Do Things that Don’t Scale mentality. While it’s sound advice for many areas, don’t let that mentality carry over to areas that should be designed to scale.
Lesson #2: Be ambitious, yet patient
I’ll be honest, this is a challenging one for me personally. There’s a delicate balance to strike between ambition and patience. On the one hand, ambition and the desire to innovate is, in large part, what separates a visionary from a business owner. On the other hand, runaway ambition can lead to overextension of your finite resources.
For example, Sparksuite publishes several open source projects that it’s struggled to maintain over the last couple of years due to time constraints on our product teams. While I’m proud of the initial accomplishments, we haven’t had the capacity to maintain those projects going forward. (We’ll soon be hiring an engineer to focus on that, though…)
It can be easy to look at larger companies and feel a strong desire to mimic what they’re doing. But patience is key for balancing this ambition. Maintain excitement for where you’re headed while carefully selecting what you’ll give your focus to and you’ll avoid having to choose which commitments you’ll do mediocrely.
Lesson #3: Set a vision and stick to it
This is particularly true for software products, where scale permits the possibility of tens of thousands or even millions of users trying to pull your product in every direction imaginable. It can be incredibly hard to say no to a user’s request for a change, but it’s imperative you do if it doesn’t align with your product’s vision.
Which therefore means you need a vision. Establish one early and don’t let it sway too easily. Although your vision doesn’t need to be 100% unyielding, the core tenets of it should be pretty darn close.
A great idea is to publish your vision publicly, when appropriate. For example, I’ve published HOA Express’s design philosophy and Sparksuite’s culture goals where customers and team members can easily view.
Final thoughts
There’s so much more that I’ve learned, like the importance of launching products early, of doing what you love, and of chasing the right metrics, but those topics have been written about in abundance. Above are the lessons I rarely read about that I wish I’d internalized earlier.
Here’s to the next decade of building mighty fine software!
