Structure

An ideal software development environment would be, among other things, reliable.

Currently, systems use tests to keep expectations and reality linked to some degree. Compilers for example, can somewhat also test the code, but only to the extent that is syntactically correct. But there are at least 3 kinds of errors: syntax, runtime and intent. The first two are familiar, the third one signals a disconnection between user expectation and running code. A bug.

I've been working for a while on what I see as The Software Engineering Problem. You know, programmers that are demotivated, project managers who are stressed, designers who are frustrated, etc. I come from a classical engineering background: Mechanical, electrical, automotive. As such, I am often taken aback by the things happening in software that would just not fly on meatworld. There's a great article on Linux Journal.

This is where the system I envision fits: connecting human expectations with computer execution, with minimal explicit human interaction. It is what robots did for Detroit: automate lower level tasks to free resources for higher level planning, with much higher quality results.

For the time being, the intent behind this prototyping UI environment is to minimize the time spent cranking functionality. This time can be cut by making for example a meta-testing program, which can collaborate with the developer to write unit tests automatically; or by making it easy to write interfaces so people with a more visual skill don't need to also know a great deal of programming or rely on someone else (and the quality of the communication between them) to write a mockup or prototype. This bit could amount for several months saved per small feature.

By focusing on human intent, computer systems can be built that are much more optimal, because the name of the problem is Human-Computer-Interaction. Much more if we are aiming for the birth of Artificial Intelligence, or the emergence of a hive mind. Previously, the idea had been to focus on the user but it seems that engineers were left behind there. "The CLIENT is who we focus on, not the lowly developer. You do what you have to do to rake in the money." Not so much.

I don't know if there's even such a place, but I'm just glad it's not really like that for me. That doesn't mean that it couldn't be improved.

Finally, "capture requirements in the user's terms, and then to try to create an implementation language as isomorphic as possible to the user's descriptions, so that the mapping between requirements and implementation is as direct as possible" --Language Oriented Programming

How to make engineers quit

1. Put them to work with tools that are inefficient. Good examples are: spaghetti code, slow or unneeded compiles and server restarts, infinitely complicated instructions and a billion systems that only a true god could figure how to make them work together.

2. Inundate them with feature requests and bugs, making sure that the deadlines sound reasonable for an optimal environment. After all, their time should be well accounted for.

So far, you already have a winning recipe. Your engineers will be swamped every time they want to do something because, ideally, it should take as long as they estimated in the first place, not really knowing the state of the underlying code.

Of course, you can't know the state of the code until you actually try working with it. If the engineer is not experienced enough, he or she can't figure out that it's not supposed to be this hard in the first place. This makes the engineer feel stupid.

There's more ways to make this more fun:

3. Reward those who are eager to write code, but inexperienced. This ensures you get a lot of features at the cost of exploding code. Tell yourself that as long as something is documented, then that's all it needs.

Remember, users never come first. A good and often used example of this is ignoring that any code that is written is supposed to be used by another, different human. Make sure you don't design for simplicity, but something that is more tangible, like page load speed.

4. Don't pay attention to engineers warning about the state of the tools. If the young'uns can deal with it, then clearly that's just an excuse to slack off.

Stay tuned for your next issue: How to lose your business to your ex-employees in a few years. Hint: it has something to do with being able to push features faster.

Anonymous Construct Pattern

I've been furiously working on "the red pill"... this is the latest

JavaScript. A powerful language, misunderstood.

So many people have tried to tame it with libraries. Many have failed, some have succeeded.

The idea behind a library either local, company-wide or open source, is to abstract imperfect parts: Not all browsers behave the same and it's extremely difficult to tame them. Gathering all this knowledge into a library saves a lot of time.

Many have tried to put some structure into JavaScript, but have only succeeded in creating only Java-ish. Classes, supers, the works.

A good abstraction is one that we don't have to think about. It just works and it's easy to use it.

Let's say that we want to make the powerful in JavaScript more friendly for kids that shouldn't play with fire. Let's tame closures for them and offer the scopes they are familiar with: private and public. Classical inheritance is sack of potatoes: heavy (when full of potatoes) and old school.

Let's say we create a translator for the rest.

Part I: Construct

An anonymous construct does not pollute; it is humble. Only its UID is exposed.

Construct's instance and static (immutable) scaffolds:

/**
* @constructor
*/
(window.Construct = function(){
 // instance
}).prototype = new function(){
 // static
};

Private members, public members:

(window.Construct = function(){
 this.private = {};
}).prototype = new function(){
 this.public = {};
};

Closures:

(window.Construct = function(){
 var closure = {};
 this.private = function(){
  with(closure){
   // private, with access to closure objects  
  } 
 };
}).prototype = new function(){
 var closure = {};
 this.public = function(){
  with(closure){
   // public, with access to closure objects  
  } 
 };
};

The time is coming

Will you miss out?

new Date(1234567890123);

This is why I don't get any work done

(function () {
    var lyrics = [];
    ['badger', 'mushroom', 'snake'].forEach(function(word) {
        window[word] = function(){ lyrics.push(word); };
    });
    function repeat(f, n) {
        for (var i=0; i <= n; ++i) {
            f();
        }        
    }
    repeat(function(){
        repeat(badger,11);
        repeat(mushroom,2);
    }, 3);
    repeat(badger,11);
    repeat(snake,4);
    alert(lyrics.join());
})();

I'm sure you remember the song.