The Most Important Lessons I've Learned In 10 Years Of Building Software

I recently decided to build my own home.

But I’ve never done it before—so I needed to find someone with experience to help me. Fortunately, I have friends who used to own a home construction company.

As we discussed the process, what can go wrong, and my many options, I was surprised by the number of parallels I noticed between home construction and my own field of expertise: software development.

Successfully building a home and successfully building software both rely on the same key approach: being thoughtful and intentional from the very beginning. You have to be specific about what you want, how much you will spend, clearly understand and negotiate all of the details in the contract, and have a framework for how you’ll make decisions as things develop.

While this is my first time building a home, I have been building software for over a decade. And I know the lessons I’ve learned from doing many things right and many things wrong. These have been incredible experiences that help me and my clients navigate the potential pitfalls of software development while creating the best possible product.

These are the most important lessons I’ve learned in 10 years of building software:

1. You need to understand precisely why you’re building a piece of software.

Consider the 80/20 rule, which says that if software does 80% of what you need it to, it’s worth purchasing and using. There is a tremendous amount of great software available that solves many of the challenges industries face, but not always.

If I reach the point with a client where we decide, “OK, we’re doing this—let’s build brand-new software,” I always make sure they fully understand why we’re doing it. That means clearly laying out what the end result will be, what problems we’re going to fix, and exactly what functions we’re implementing.

2. Too much automation can be a bad thing.

I’ve seen a lot of clients over the years push for software to do as much as possible, with as little human intervention as possible. This seems like the holy grail, but is very risky, as over-automation can cause more headaches in the long run. Because it’s rare that software can handle an entire workflow without human engagement.

If you build in too much automation, processes become rigid, and the software ends up unable to respond correctly to unusual situations. Then you end up having to create workarounds because the automation doesn’t “understand” certain issues.

It’s important to create touch points for humans to step in and either assess or fix a situation. And ultimately, it’s a balance of embracing automation, while also being flexible enough to handle the rogue situation.

The goal is to implement as much automation as makes sense, just not so much that it ends up limiting what the user can do.

3. Always define acceptance criteria very clearly.

In order for a developer to fully understand what they’re building, clearly defining acceptance criteria is key.

Essentially, acceptance criteria, or acceptance requirements, are the conditions that a software product must satisfy to be accepted by the client. In simpler terms, it means the developer must do their due diligence to understand what the client really expects the software to do.

When developers fail to appropriately lay out these conditions with a client, it can cause endless headaches for both parties: false assumptions, unexpected increased costs, unnecessary revisions, delayed timeline, etc.

Communication between developer and client is a delicate balance and somewhat of a dance. It’s the developer’s responsibility to thoroughly discuss every aspect of the project—from cost to functionality—with the client while remembering most clients are not software developers. And it’s the client’s job to not make broad assumptions, but instead, ask lots of questions and ensure they really understand what is going to be delivered. Then, most importantly, all of it needs to be documented so that it’s easy to reference.

4. Consult with someone who’s done it before if you want to take your software to market.

A successful software development project requires more than just a client who knows what they want and a team with the technical chops to build it. Especially if you’re planning on taking a product to market, which is a whole other realm some developers won’t know a thing about.

Look for a partner that has commercially released software before and can provide insight into the business end of things: product marketing, strategic planning, researching competition, release management, sales structure, and more.

A newer term in the industry is a Product Development Outsourcer, or PDO, which is a development firm that specializes in the entire process—from creating new software to bringing it to market and selling it. Even if you don’t use a PDO, look for a firm that has built its own software companies from the ground up in the past.

5. Nothing is ever going to go exactly as planned.

Building software is an imperfect, trial-and-error, back-and-forth process.

Code-writing itself is fairly straightforward—but it’s usually the only straightforward part. There are a million other moving pieces, and when you’re also dealing with tight deadlines, an even tighter budget, and high expectations, things can quickly spiral out of control. If both parties aren’t on the same page, the software gets developed and it doesn’t do what the client wants, which leads to change requests, more development work, scope creep, and all that fun stuff.

These risks can be mitigated, to a degree, by platforms as a service (PaaS) like Salesforce. With these platforms, the foundation already exists. This provides a helpful starting point, gives the developer and client a shorter race to the finish line, and, ultimately, results in fewer hiccups due to fewer opportunities for them.

6. The mark of great software is that it solves a need and is simple to use.

I always use this example, because it’s simple: the iPhone. It’s the most user-friendly, seamless, powerful smartphone by a long shot. The amount of technology it contains is incredible, but you don’t have to read a lengthy user manual before using it, because the way it works simply makes sense.

All software should, from a broad perspective, be like an iPhone: simple, reliable, and functional in a way that makes clear sense to the user.

The most impressive aspect of iPhones, though, is that even with each new update and the new features that come with them, the iPhone maintains its simplicity. As companies update existing software and add new features, interfaces often become complex and cumbersome. The technology becomes difficult to use, and the initial vision is eventually lost entirely.

As you update and improve your software, never lose sight of its simplicity, initial purpose, and the vision behind it.

7. No two developers are the same.

And no two software development companies will deliver the same results. That’s why, when you’re scoping a project, focus not just on the cost of the project, but on the entire offering and the company’s experience. You are not just looking for someone who can write code—more importantly, you’re looking for someone who really understands what the broader business need is and how to leverage the software to achieve it.

From a management standpoint, the best software development teams are well-balanced, with a mix of skill and experience levels across a company. You should see a blend of backgrounds ranging from strategy to support, and everything in between.

8. Make sure you define the user interface (UI) from the very beginning.

Too often, software does everything it needs to—just not easily enough.

For this reason, it’s important for developers to understand not only the desired output, but also the workflow and how a client will actually use it. Designing the UI and UX is as important, if not more important, than the underlying code that drives it.

If this isn’t clearly defined, users may end up not taking advantage of certain software features, because they’re too difficult or time-consuming to use, too hard to find, or not something a user needs.

9. It’s amazing to create software.

When you bring something entirely new, unique, and useful into this word, it’s a pretty incredible feeling. But ultimately, whether you’re the client, developer, or an advisor, seeing all the hard work pay off at product launch is truly special.

This is the most important lesson I’ve learned building software—and why I still love it 10 years later. Let’s hope my home-building adventure turns out the same.