Today we’re exploring some common struggles we see founders experiencing at different stages of their project development. Talking us through these hurdles are Mike Scott and Dave O’Reilly, CEO and CTO of Nona respectively.
Dave has been programming since ‘91 and has worked with some of the world’s leading brands on a massive range of projects across many industries and technologies. Between the two of them, they have a wealth of knowledge in the software development space, including managing software builds.
These men are the perfect pair to take you through the tumultuous ins and outs of software management, so let’s dive right in.
Managing your software development
The first hurdle is software quality. “In the earlier days, we spent a lot of time trying to explain to people what the difference is in getting a $20 an hour developer, and a company like us who charges considerably more,” says Mike.
So, what is the difference? It largely depends on what your requirements are.
How to determine software quality
“A lot of the time, the quality of the software is obviously quite inextricable from how well it fits your purpose,” says Dave. “Part of it is determining what you’re going to use that software for. And that’s obviously not just the function it’s going to perform immediately, but what its whole life cycle is going to be, where it’s going to sit in your business plans, and how you see that changing over time.”
Thinking about your project in its entirety is so important. A common misstep that we see in our industry is when founders want to build something and get it out quickly, for reasons such as needing an MVP to show investors. “They’ll be quite convinced that it doesn’t really need to be perfect, or even particularly good or reliable, because the whole thing is going to be rebuilt in three or six months anyway,” remarks Dave. “But then three years from now a large part of your company rests on something that was only meant to be a short stopgap that existed for a brief while.”
So the questions you need to ask yourself before you build your software are:
- How long does this piece of software need to exist in my company?
- How much work and modification will happen to it in the future?
- If I need to make changes, can I make them quickly?
How to manage technical debt
Another aspect of software quality is the amount of technical debt you accrue. Tech debt indicates the implied cost of additional rework caused by choosing an easy solution now, instead of using a better approach that would take longer. Dave illustrates this concept with an example:
“Say you’re building up a particular site from scratch, and that site needs to send an email, welcoming new users. You have two possibilities in the way you would build that part of the site. One way is to say, all we’re going to build is something to send out the welcome email. We’re literally just going to code exactly this, and be done.
The other part would be a safe choice, to say, okay, probably in the future, we’re going to need to send out other emails. So you take a bit more time and build a slightly more general system that is capable of sending out a variety of emails, and doing other things that may potentially be required. So it’s capable of putting images in the email, and some formatting, maybe embedding a tracker.”
While it would’ve taken longer at the time to build the general system than the one-off welcome email, it’s the better option as it’ll take you even longer to add on all those requirements now. Spending that little bit of time earlier on saves you from tech debt later down the line.
Unfortunately, there is no real way to avoid technical debt completely. If you’re not a technical person yourself the best way to manage tech debt is to get a technical co-founder or a CTO to oversee your build. Outsourcing an expert team is another viable option.
How to tell if your software is in trouble
“Many of the projects that we work on at Nona start off because somebody contracted a poor software team, whether it’s internal or external, and this team built their tech, but the project is now in trouble,” explains Mike. “And their request is essentially to rescue or to rebuild the project because it’s run into too much trouble. It’s not really salvageable with the current developers.”
Having to repair this kind of damage is massively expensive in both time and money, but it’s, unfortunately, something we see founders struggle with often. Dave details the signs you should look out for:
When you notice it takes more time to see new features
“If a project is being managed properly, and the team has found their rhythm, you should generally expect to see the same amount of new development happening constantly, ” explains Dave.
When the software is unreliable
“A big red flag that you will often see,” says Dave, “is that as time goes on, you’re hearing more and more excuses like yes, that screen’s blank because this isn’t done, or that button is meant to do this, but that’s not in right now.”
When you haven’t seen new software in a while
“You should be getting software regularly to look at. Another really big red flag is if you haven’t seen anything for a few weeks, or a month, or two months, but you are constantly being told don’t worry, that feature’s nearly done, this is going to be great. In that case, I will almost certainly say, and you won’t see it, or it won’t be great,” says Dave.
When the tech team doesn’t understand why they’re building something
“I guess it’s more of a feeling,” Dave starts, “but you should feel that the technical side of the business understands the point of the stuff. Are you frequently getting a feature back? And then when you look at it, are you saying, no, this isn’t it, there is no point to this, this isn’t what I wanted? Because then there’s obviously quite a big communication problem.”
Managing software quality is clearly a constant, time-consuming job. If you’re looking for an expert team of honest, reliable software developers, get in touch at email@example.com today.