Strides Interactive

So cool, it’s frozen!Filed Under: Weekly Tuesday Dose of goodness

Dear all,

This week I’ll address an issue that is common in developers who have the power to decide what goes in and what doesn’t in an application.

While many developers have lamented at the technical ignorance of their managers who had made certain decisions beyond technical comprehension and always seemingly appears to be an act of stupidity, technical naivete or even worse, a decision taken on their behalf; if something goes wrong, the developer is responsible.

So… what has this gotta do with “cool”?

Well, let’s begin with looking at developers who make the decisions. To know more, read on…

Introduction

First of all, we need to understand how decision makers think in order to anticipate the likely actions they’re going to take. Of course, there’ll be exceptions, special cases or even illogical or unexplainable decisions made from time to time but there’re a few things that always happen.

When we talk about “cool”, it’s usually associated with the “coolness” of a particular feature, be it graphical, audio, input, network or anything that is on the technical side of things.

Definition of “cool”

We have to ask ourselves, why does a particular feature appear to be “cool”?

The answer lies in the characteristic, role and mind set of the decision maker. If the decision maker is a technical person, then very likely, the definition of “cool” would be one that can make his/her technical capabilities shine and proven due to the success of implementing this feature.

However, if the decision maker is a management person, then the definition of “cool” will be probably refer to the ability to better manage his/her team.

Lastly, if the decision maker is a sales person, then the definition of “cool” will be the ability of this feature to increase the sales revenue.

In short, everybody has a different perspective when it comes to “cool”. The crux is whether this notion is applied correctly so that the project doesn’t freeze.

A project freeze refers to issues, bugs, regression errors and other related errors that causes the project to stall for an indefinite amount of time until those problems are resolved. This of course, isn’t good for the technical, management and sales people.

Constant truths

Before we even think of adding a cool feature into an application, we need to know several constant truths. Here’s a few of them in general:

1) You or your company is running a business.
2) You’re working on a project which has a finite scope and time frame.
3) Your company needs funding to survive and pay you.
4) Your company will eventually need to sell a finished product. Whether it’s a product to be given to a client or in-house developed product for general consumers.
5) Your project must be workable, deploy-able and usable.

So, does your cool feature have the potential to disrupt any of the above-mentioned points? If the answer is yes, then you’ll better think thrice before committing the changes.

Does size of role matter?

The quick answer is - no! Size does not matter in roles that help develop the application. The reason is very simple. If everyone has the power to affect the outcome of the project, then everybody is responsible.

If a developer is given the power to introduce any features or libraries as he pleases, then this developer must be matured and rational enough to consider the impact factors before committing the changes.

Let me give you an example.

Traditionally, C++ programs mostly use standard libraries and near-standard or de-facto libraries such as boost to help, in fact, boost the productivity of the whole team.

However, there’re cases where such libraries are not used due to specific reasons.

In this particular case, a developer actually introduced the use of boost library in the middle of a project which has its own capabilities. While the intentions are good, this developer forgot to measure the costs of linking the application to such a huge library.

As we know, boost is not a trivial static library. It’s alive with templates as well as other preprocessors to start up the entire library.

As a result, the application’s final execution binary size shot up to nearly 200%. On top of that, compilation of the entire application now takes twice as long. Worst of all, he only used like 1% of the boost library’s functionalities.

Although this isn’t a case where it’s cool but it froze the project, it’s a good example to demonstrate that such careless and reckless change or addition will inevitably affect the project progress.

When progress is affected, all the truths I’ve mentioned will be affected as well.

Boost library is cool as long as it’s used right from the start. It may not be suitable if an existing boost-like framework/library already existed. You’ll probably end up with 2 copies of similar functionalities instead.

Conclusion

Finally, I’d just like to say that the only thing that is cool is when the application is developed, finished, polished and published.

If a team even reaches a stage where their application reaches the stage of publication, then it’s a big step forward because by selling the product, it gives the team the extension required to build even better, greater and more efficient applications.

Otherwise, if a developer decides to selfishly fall back on his/her own comfort zone by introducing features that are familiar only to him/her, the project progress may suffer badly or even stall in the process of fixing the issues created by this decision.

Some may argue that they can rollback with a source control. Agreed, however it’s still not a trivial task. Don’t forget that you need to test as well. Regression testing, stability testing, coding standards and so on. How do you even know that the rollback itself was done correctly?

Therefore, a feature, no matter how big or small, simple or complicated, must go through a proper process of identifying potential impact issues, design issues and effort estimation in order to frame this feature up into something that can be contained.

While I’d want to continue, which I’ll probably do in the next few articles, it’ll probably be best for me to sign off for now.

Therefore, have a great week ahead!

Signing off,
Jeremy