End in a black box, or begin in a white one

Different ends of the spectrum

There always seems to be some learning up for grabs when two worlds collide, the strength and benefit of difference as ever it seems.

The current overlap is between having to write code for a game in the console world, and building an application for the internet.

One it would seem is a mad burnout sprint to an arbitrary dead line invented by marketing, or some other external force ..... which you then walk away from dead or alive.

The other is a preparation for a marathon, where the foundations of the future are are laid.

Get them mixed up at your peril.

Black Box

Knowing that there is no future, that the code does not have to touched ever again and the perceived "value" of the product is the external behaviour, then console and sold product coding is black box (patches and updates aside, which in a way prove the point I'm making).

Design, planning and execution typically happen all at the same time in a Colombo style of execution "Oh just one more thing" and "I want to to just add X, that's easy right", the perfect burn out recipe for programmers (who I've found in this field are held in quite low regard, basically contempt it seems, by producers and seniors "who know better"). Pre-production concept work aside.

Now I've happened to of seen quite a lot of this kind of code and the vast majority of it is mental carnage; hacks on bodges and work-arounds on changed ideas near constantly. I make for perfect college examples of "how not to do it".......... though in this field it's a constant (industry enforced & suit enjoyed) fire fight of change and bug hunting to "blame the programmers".

It's basically sickening and so far removed from a healthy way of creating something it beggars belief.

Luckily I haven't directly experienced it, and you could never pay or coerce me to ! Though over the few years I've been in Vancouver I mingled with loads of the industry at all levels.

Though what is likely most important here is that if a programmer survives to the end of the product and it is launched, they will likely never had to see or touch that code again, the hack it out at the 11th hour is done.

Time to sleep and recover until the next boot is applied to the back of the head for the next project !!

White Box

Now given that the development work for the internet starts with planning what to get done before launch it's a wholly different approach.

The quality of the process here will define the ability for the product to be maintained, grow, be stable, be profitable, be supported and adapted by different people though out the life of the application (game or what ever, they are all the same behind the scenes, 0s and 1s flying around).

Good things you would of thought .......

Hence why I describe it as white box, as there are going to be all kinds of people (i.e. other programmers) looking inside it to see what is going on.

So there better be architecture, planning, coding standards, documentation, integrated development, comments, operation tools, etc. The real basics of programming that are there for the big picture and long game.

The insistence of short sighted people to bypass this "because they know better" or under the believe that the code they are writing will never be touched again, have no place in a professional environment that deals with the internet or an ongoing product.

Technical Debt

Technical Debt
Make poor choices now or hack it out in the short run, and you will pay for it dearly in the future in support and low productivity; it is only very short sighted or instant gratification driven organisations that typically take this route.

Ironically offsetting the poor choices onto engineering "to fix".

So ?

Remember there is nothing more important than the employees of the company, nothing. Doesn't take a degree in psychology to know what the ultimate outcome is of not remembering that.

Remember which environment you are in and what is the true cost of what you are doing.

Do it properly or don't do it at all. Properly isn't some academic dream or waste of time, it's how great companies emerge and awesome products become a joy to work with.

Tis is any wonder that the majority of successful tech companies on the net are run by people which a lot of technical knowledge who don't compromise on quality of approach ?


  1. Too true .........

  2. "Elegance is a combination of power and simplicity.

    Elegant code does much with little. Elegant code is not only correct, but visibly, transparently correct. It does not merely communicate an algorithm to a computer,but also conveys insight and assurance to the mind of a human that reads it. By seeking elegance in our code, we build better code. Learning to write transparent code is the first, long step toward writing elegant code - and taking care to make code discoverable helps us learn how to make it transparent. Elegant code is both transparent and discoverable."

    The Art of UNIX Programming - Eric S. Raymond

    Says it all, and backs up what you say Jeremy

  3. Standard survival practice I'd call it as well. Be flexible and adaptable while inflexible companies are constantly fire fighting and laying off good resources (people) they force into a corner to stagnate. Good to remember that 90% companies are very very young that we see as giants and they are paying for mistakes constantly right now. Be the few, the best, that don't leave it to chance and have no limit on how they can grow.

    Good write up. Always respect the builders!


Post a Comment

Popular posts from this blog

How to create SugarCRM graphs

Burnout and how to deal with it

Virtual Teams and Remoting Working; a research based perspective