Freelance Software Development Mistake # 7 – Not Testing Early, Often, or Correctly

Testing is one of the most important, yet often overlooked activities on a software project.

How the test process is handled can make or break a project.

Here are a few “golden rules” of software testing.

Programmers can’t test their own work. It is the same as proof reading a letter you write, you just don’t see the mistakes that others find.

All software has bugs, some are just not found yet. Some bugs have been found, but not worth fixing because they are minor annoyances that are hard to fix, or will very rarely be seen (we just end up calling those “features” ;-).

In the process of fixing bugs, even the best programmers for hire can introduce new bugs.

This is why a feature that worked in the last version may not work in a new version. Your test plan must account for this, it’s a fact of life with software.

It does not matter how simple the change was or what the programmer tells you, fixes introduce new bugs more often than not.

The earlier a bug is found in the project cycle, the cheaper it is to fix. Here’s an example:

John finds a missing feature while writing up his project description (one could argue this is a bug). To fix this, he simply adds another sentence or two to his description.

That was easy!

Two months later, John finds that one feature has a bug that makes it cumbersome to use with another feature. Since both features are already coded, changes must be made to two places in the code.

The changes will introduce new bugs and the code that was “done” will have to be changed again.

That was somewhat painful.

Two months after that, one of John’s users finds another bug. Now the program is in production. There is “live data” managed by the program and the shipping department is totally dependent on the program for their operation.

Now it is risky to make the fix, down time has to be scheduled, new freelance programmers may need to be hired, and they will need time to learn the original freelancer’s unique programming quirks.

Now it’s really painful!

As time passes, pain and expense to fix a bug increase.

Lesson: Test early, test often, test everything!

Testing is not as effective when done haphazardly. You really need to create a test plan and follow it for each version.

Your test plan should focus on the most important features of the program.

You should account for which areas of the program are changing with each release and which features are ready for testing for the first time. These areas should get most of your attention when testing preliminary versions.

You need to track what you test. Keep notes as you test so you will be able to refer to them when a problem occurs.

The most important thing to tell the programmer is what you did right before you saw a bug. This is very important in helping the programmer locate and correct issues.

Bottom line: Test early, test often, test everything you can on every preliminary version, and keep a log of your testing.

That’s it for the seven mistakes. I hope you won’t be making any of those mistakes on your projects!

I’d really like to hear from you. If you don’t mind, take a minute to leave a comment┬átelling me what you think of the Seven Mistakes series and what other topics you’d like to see covered in the future.

Freelance Software Development Mistake # 6 – Letting the Programmer Manage the Project

Freelance programmers like to do programming – most of them dislike project management. Someone needs to manage the project, so that’s gonna be your job.

Most people that make this mistake do it by default. They don’t seem to realize that there is a manager role in the deal.

No matter how uncomfortable managing a software project makes you, the reality is it has to be done, and it has to be done by you.

Some non-technical people are very scared by this. Remember, you don’t have to understand the technology, you just have to understand the problem you are trying to solve and know whether the problem is solved by the program delivered. It’s the programmer’s job to understand how to use technology to solve the problem.

That is why you hire freelance programmers, to get skills you need but don’t have.
“After I described the program I need and I hire a programmer, what else is there to do?”
Plenty!

  • You need to make sure the programmer interpreted your description the way you intended.
  • You need to make sure the programmer delivers what you asked for.
  • You need to set expectations and inspect the programmer’s work to make sure it meets your needs and quality standards.
  • If something turns out to be much harder than expected, or does not work out exactly as planned, you might need to decide which of several paths the project should take.

Here’s why freelance programmers should not manage projects:

  • It is your project! You have the final say about what the project is. Giving that job to the programmer is like letting the fox guard the hen house (no, I’m not saying that programmers are sly like foxes, many just need to be properly managed).
  • Programmers do not know the intimate details of your business, your users, etc. You have to provide direction, programmers create software from that direction.
  • An old expression says you only have the right to expect what you inspect. You have to be involved in the project to make sure it delivers what you need.

Bottom line: You are the project manager, you must take on the responsibilities that come with the job.

That’s all for now, next time we’ll cover Mistake #7, the common mistake that causes project problems to go unnoticed.

Freelance Software Development Mistake # 5 – Rushing Through the Planning Stages

Starting a new project is always exciting. There’s lots of anticipation and hope for great things to come. There also tends to be a good amount of optimism at the beginning of a project.

Sometimes a bit too much optimism!

Some people tend to get caught up in all these emotions. It seems like nothing can go wrong.

This makes it a very dangerous time.

All the feelings mentioned above tend to cloud thinking and lead people to rush through the early project steps.

This is a huge problem, because the beginning stages of a software project are critical to its long term success.

It’s like laying the foundation of a building; seems boring and slow, but it’s incredibly important to get it right.

As a project progresses, your options become more limited, so the best time to make choices is at the very beginning. The choices you make at the very beginning are usually the hardest to change later.

Here’s an example that shows why software projects work this way.

Imagine you are starting a new software project. There’s a great feature that will make a big difference in your project, but you haven’t thought of yet.

Watch how much more painful it gets as you discover the need for the feature later in the project.

  • Imagine you think of the feature while writing your project description. This is pretty easy, you just add another paragraph or so to describe the feature.
  • Imagine you think of the feature after putting your project out for bid. Now you have to change your bid request and get programmers to look at it all over again.
  • What if you’ve already selected a programmer? Now you have to renegotiate the new feature with your programmer (no bidding, just you and him).
  • What if your programmer is already half way through the project? To add the feature, he may have to re-write part of the program to add the new feature, so you’ll pay twice for that part of the program.
  • What if the project is finished and already working? Let’s imagine it’s up on the web, working beautifully. Now you have to describe a completely new project to get the change done. Worse, you have to account for upgrading the system, avoiding any data loss during the upgrade, minimizing the downtime on the upgrade, etc.

Bottom line: don’t rush through the planning stages, getting it right the first time is much easier and cheaper.

Word of caution: you also need to avoid the other extreme; analysis paralysis (all thinking and no doing).

That’s all for now, next we’ll look at Mistake #6, which is easy to fall into, and hands control of your project to the wrong person.