Mizblog

This week I delivered the third of three online learning modules. I built them as I was building the framework that they use, so the process was very dangerous and difficult. Actually, due to the rapid development rate, there are many many known problems with the code, but hey it works and that’s what’s important right now at this moment.

I’ve already started on my next coding project, which is another experiment on how to teach kids to measure things. I think with the new framework available it shouldn’t be much of a problem.

One of the general development problems I keep running into stems from the conflict between creating new code quickly and maintaining older versions of the code. Here’s what happens:

We get a new job that’s a lot like the job we’re working on now, except instead of wanting it to be delivered yesterday, they want it last week. Okay, we’ll have to make quite a few changes to the existing project in order to implement the desired features, but since the existing project doesn’t require those features, and we don’t want to break that project in the process, we create a new copy of everything and add the features to that (just to be safe).

Now while we’re working on this new project, we also fix a bug in code we copied from the original. It’s difficult to realize that we should immediately stop and apply the same fix to the original (and of course test it thoroughly in case it has unintended consequences) so in most cases we don’t apply the change to the original. Later, however, when we’ve delivered the original and someone notices the bug there, we’ll get to go back and fix it there too. Multiply this by several projects and it becomes very tedious.

One way around this is to utilize shared library files. This way, when you fix the library file, everything that uses it benefits from the bug fix. The tradeoff is that if the behavior of the library file changes, all the projects that use it suffer. If different projects implemented different workarounds for that bug, they’ll all need their own individual debugging sessions. Gah! Also tedious!

Another option is to use some kind of source control and try to merge versions. This so-called automated function usually requires at least as much effort as debugging all dependent projects after a library change, because you have to test them anyway, even after you figure out how to incorporate the changes from source control. Also tedious!

I guess what it comes down to is that developing several related projects at the same time is tedious. It involves a balancing act between code sharing and code separation, and it demands testing of every project after every change to library files. This is where automated testing is very beneficial. It lets you spit out a test command and collect results of all your tests. Unfortunately, I haven’t got automated testing down for GUI code. People can come up with so many odd behaviors that I’d never think to write a test for.