Strides Interactive

Psychology of building applicationsFiled Under: Weekly Tuesday Dose of goodness

Hi all,

This tuesday was a special day for me and therefore I couldn’t make a post.

So I’ll make up by posting today for a rather different topic. This time I’ll share my experience regarding the weird feeling I felt during my development using C++ codes versus my development using Strides scripts.

A lot of people usually think that build times are long and unnecessary, including myself as well.

But… there was once I had a terrible burnout and as a result, I couldn’t even organise my thoughts properly when developing using my very own Strides Octopus.

Why is that so? Read on…

To understand this whole story better, let’s begin with by understanding what’s good or bad with the normal compilation and linking times when building an application with C++ (or any language).

Advantages of builds

When I talk about builds, they are usually separated into at least 2 stages, compilation and linking. This of course applies only to programming languages that has these 2 steps. As for langauges like Java, say, using Ant build, probably the 2 stages would be compilation and Jaring up the JARs for deployment into the server.

Most people will think that these advantages are:
1) Compilation automatically identifies parse and syntax errors
2) Compiler warnings help reduce the possibility of a logical bug (that’s if you read them)

In my opinion, the true advantages are: (on top of the ones above)
1) Gives the developer a mental break
2) Allows the brain to rest and reflect on whether the changes made conforms to logic and requirements
3) The delay allows the developer to hatch a solution for a possible problem

Disadvantages of builds

1) Long waiting times, incurring additional costs to the company
2) Might encourage and cultivate a habit of taking breaks everything the whole system rebuilds
3) Might demoralize developers who are rushing to finish the project
4) A single break in the build requires a lot of effort to fix, along with possibilities of regression errors and so on

Is Build times really necessary?

We’ve covered the different stages of a build. Now let’s talk about the different types of builds. Naturally, there’ll be a few:

1) Incremental build
2) Rebuild Project
3) System Build

The obvious difference between each type is the amount time required. System builds are usually done nightly or per quantum (ie, 2 hours) basis based on the parameters of continous integration tools used.

Incremental builds are required whenever a module is being developed. A good developer knows how to divide and conquer and knows when to develop what. Therefore, incremental builds help such developers to reflect and understand whether they’ve done the right thing or not.

Rebuilding projects, in my opinion, is the worst case of building an application. It may not take as long as system builds, but it takes up the developer’s time. While the developer can reflect on their changes, they’re effectively helpless until the next rebuild.

In short, build times are required for a break, a milestone mark or progress update. Such delays do not break one ’s train of thought if that that person is well-organized in the first place.

Burnout

I had a massive burnout when I was working on Jedi Wing 2 once. In this projects, there were no Jedi Wing 2 codes involved at all. Instead, all the code components come from the game engine and the respective technology DLLs.

So how did I do it? I developed Jed Wing 2 using Strides Octopus. It has the capability to build games without the need for any compilation.

This is due to the fact that Strides Octopus runs on a Script designed specially for such orchestration.

Sounds too good to be true? Actually, no, it’s really so. There’re no strings attached.

However, on the pyschology side of things, since there’s no compilation or build, I find myself working constantly, producing a lot of scripts and had a lot of progress. However, soon I realise that I’m running out of “brain space” to think of what I’ve done and what to do next.

There seems to be no break in the momentum since there’s no build required. Therefore, after a while, I was out of breath, somewhat crippled by the very momentum that drives me forward. In short, there was too much to swallow.

In the end, I had a burnout.

After a week or two, I went back to the Strides Octopus project to make improvements to the usability (since I had the idea that it was the usability flaws that led to my burn out), I realised that it’s much simplier working on codes compared to working on scripts. This is nothing short of feeling confused.

So I took the time and slowly began to understand why it was easier. I went back to StridesLib and made some improvements to some of its components. I got the same feeling as well.

Does that mean that I’m destined to be a coder? That’s what I thought so at first.

But as I recovered from my burnout, I realised that I’m actually reflecting on my changes everytime I press on F7 to build. After a while, I realised that this is it.

The compilation delays helped me reflect and take a mental break from the work done and sort of gave me the space I needed.

Conclusion

My next thought would be, what should I do to Strides Octopus? Here’re a few things:
1) Make static analysis free in Strides Octopus and make it compulsory to run everytime the user tries to press Ctrl+F5 (which is to run the game application)

2) Build an application to monitor progress and tasks. Of course I can use open source or freeware if possible. But I have a few features that might not be found on these wares. For example, the ability to scan and notify regression impact per change.

3) Plan my work properly and carefully on paper. That’ll be the cheapest and easiest way to resolve this problem for now.

I realised that the simple solution listed in point 3 can easily resolve my problem. This is indeed disturbing as I’ve always prided myself as one that plan my own work and work my own plan.

Does it mean that Strides Octopus is so easy to use that one ignores the importance of milestone and scope planning? We’ll discuss about that in the next article.

Regards,
Jeremy