Do You Have the Right Software Development Team?

There are literally millions of programmers in the world. How do you know that the ones working on your software are doing a good job?

When things are going well, it's easy. If your customers are happy, your projects are on schedule, bugs are rare and quickly dealt with, and new features are being implemented in a timely manner, then chances are you've got a pretty good team.

But what if things aren't going well? What if you're getting tons of bug reports, and bugs are going unfixed for a long time? What if all your new feature requests take much, much longer than you expect? What if all of your projects are running behind schedule?

Your software team may be telling you that the features you're requesting are particularly difficult, or that the bugs being report are particularly hard to track down, or that external circumstances or lack of resources are putting them behind schedule. And the thing is, they may be right. This is one of the challenges of being a non-technical business owner or manager: "How do I tell the difference between 'our problems are difficult to solve' and 'our software developers are not good'?"

If you're not a programmer yourself (or if you've been out of the trenches and in management for a while), you may not feel qualified to judge the work of the programmers you've hired. Or you may simply feel more comfortable with an outside opinion. Either way, a code audit is an excellent way to determine whether you're in the "hard problems" camp or the "we hired the wrong people" camp.

And the answer might be somewhere in-between. A code audit can point your team in the direction of improving their code so that all of your problems become easier to solve. Whatever the situation ends up being, you can't make a decision until you have the information.

Interested in a code audit? CodeWise can help!

Is It Time to Rewrite From Scratch?

Congratulations! You had an idea for a business. You hired a few software developers to implement your idea. You got your product out the door or started offering your service to the world, and it took off. Now that you've got a successful business up and running, it's time to think about growing and maintaining it.

Now you're faced with a crucial question: do you try to grow and maintain the version of your software that you already wrote, or do you throw it away and rewrite it from scratch?

It can be a tricky question, especially if the team which initially built it isn't around or if they're inexperienced. If you were in a hurry to get to market, you may have incurred a lot of technical debt. You may have hastily added and removed features as you learned more about your problem domain. Maybe you had to hastily on-board some new developers or consultants toward the end of the project to meet your deadlines. None of these are incorrect decisions, but one of their side effects may be a code base which is kind of a mess. And now you're wondering if the best course of action might be to rebuild everything from the ground up, cleanly, without the blind alleys and vestigial features.

Or maybe what you're operating off of now was a prototype that the original authors never intended to put into production; a proof-of-concept that isn't architected to be stable or scalable. You hired some developers to prove that your idea was workable so that you could take it to investors; now you're wondering whether you can turn that prototype into a production system, rather than incurring the costs of rewriting it.

If the code base is a completely unmaintainable mess, scrapping it might very well be the best course of action. But there are some pretty strong arguments to be made against throwing it all away and starting over. That messy code base has a lot of knowledge and bug fixes packed into it. But all that knowledge might be useless if it's inscrutable to new developers, or if the code is so tangled and brittle that making changes is difficult, risky, or simply impossible.

What you really need to know at this stage are two things:

1. How maintainable is it?
2. What will it take to make it maintainable enough?

If the original developers are still available and they are sufficiently experienced, they can probably give you an honest answer to those questions. I say "probably" because developers are human, and subject to human foibles. They can be overly optimistic or pessimistic because they're too close, too emotionally invested in the software. Or they may simply be loathe to admit mistakes. Or they may be overly eager to start from scratch and "get it right this time".

If the original developers are gone, or if they're simply not very experienced, you may just not have anyone in your organization who can accurately answer these two questions.

This is where a third-party code audit comes in. An unbiased assessment of your code by someone who has no agenda, no attachment, no stake in your decision. A code audit can tell you whether or not you have maintainability issues and recommend a course of action to correct any you may have.

Once you have that, you can make an informed decision about whether or not it makes sense to start over to or to continue with your current code base.

Interested in a code audit? CodeWise can help!