Strides Interactive

Software Quality - Part 13 (Backtracking time?)Filed Under: Weekly Tuesday Dose of goodness

Dear all,

It has been quite some time since I’ve posted. And I must say, I’ve been thinking through about the next set of software quality parts and I do not feel very comfortable posting them here. The primary reason is due to the fact that those articles are highly subjective and debatable. It’s unlike the first 12 parts where all of the components described are actually in practice.

Thus for the next few weeks, since my 2nd set of software quality isn’t ready for release, I’ll try my best to share my other experiences too.

This week, we’ll talk about a small change that can lead to a very irritating development cycle. So what’s that?

Read on…

Introduction

Many a times when we’re coding using 3rd party libraries, sometimes these assholes actually have a time limit as to when you can or cannot use it.

Thus once this time limit is reached, your application grinds to a halt.

So what’s next? Well…. either you get the full version or you try to set the date back to “give” yourself more time. Well-protected shareware libraries will tend to guard against time back tracking to prevent such scenarios from happening.

However, others may be kind enough to allow you to do that.

So you’ve managed to change the time. The project builds fine and it runs alongside the 3rd party as though as it’s still under evaluation. What’s the problem then?

Problem

The bloody problem occurs when you back track time. In IDE (Integrated Development Environment) such as Visual Studio, it’ll be kind to check your object files as well as your executable to see if they need to be rebuild. This is also known as the “up-to-date” checker.

So what happens when you try to build again? The IDE will rebuild virtually, your entire project. Don’t think it’s trivial. In a standard project size, around 300,000 lines of codes, this can be a nightmare scenario.

You’ll start to wonder what on Earth have your IDE gone wrong and probably the first thing you’ll do is to restart your machine.

Guess what? It doesn’t do a thing!

Thus you’ll have to endure your project rebuilding every time even when you didn’t make ANY changes at all!

Worse of all, you may have forgotten that you’ve changed your date or worst of all, you don’t even know you changed your date.

This problem is very apparently in the older Windows XP where if you open the calendar in an impromptu manner, ie, a singe click on your date time and then you select a date some time before, this becomes the set date.

Conclusion

This is a very short article by the way. Hopefully it’ll ease the pain of having to read so much. I’ll probably do the same over the next few weeks for my articles too.

Anyway, the conclusion is very simple. You’ll have to manage any time changes if you ever must change your system date. If not, this should be one of the things you should look out for if your solution keeps rebuilding itself even when there isn’t any changes introduced.

Everybody have a great week ahead! Signing off for now!

Regards,
Jeremy