Can you improve on emptiness?

A while ago Google published what they called the "Google Aptitude Test", and one of the questions they posed (#9 I believe) involved improving on empty space. After reading several answers to this question, I thought that the correct answer should have been "nothing", for several reasons.

In terms of how it relates to Google, it appears to be one of their desired design goals. All right, simplicity might be the actual design goal, but you cannot achieve simplicity when you have a cluttered interface. Either way, as you look at the applications they have published (search, gmail, gtalk, etc), it all has a very simplistic, very small interface. Contrast their search homepage with that of Yahoo's. Google is very much interested in becoming a "portal", as gmail and talk both attest to. Yet, their homepage remains ever so sparse. So, I think its the right answer because it follows what Google is already attempting to achieve.

However, if we diverge into the more philosophical, I feel there is another reason that the answer of "nothing" is correct. Back when I was playing guitar more regularly, and I was reading a lot of guitar theory, one of the books I was reading, either the Advancing Guitarist or the Heavy Guitar Bible, they mentioned that when soloing, it is often the rests in-between notes that make the solo interesting.

So it is with other things as well. The space between words and thoughts becomes the emphasis. If you have a blank page, you can write anything on it. It is blank, it can become anything, it is completely malleable. However, once you begin writing on it, it loses that potential. The page then is forced to represent an idea, solve an equation, or otherwise complete what has been started. It can no longer be anything you imagine.

Just so I can tie this to software somehow, it is similar to an undefined variable; it can be anything, at least until you assign something to it.

Rather then clutter up empty space with some complex math proof, or some essay, why not sit back and think about all the things that could go into that space. Therefore, the answer of "nothing" gives way to all that could be written or displayed on that empty space, without actually committing to anything. It gives us a chance to do what we do so rarely in life:

pause,

and

think.

Of course, by typing this all out, it kind of goes against what I just discussed, so I'll end this here, but I'll leave something more important to think about:




















...

Why testing doesn't occur in strongly-typed languages

This isn't meant to be an answer, or even truthful, more just something to think about, again, its just me ruminating on various floaties in my head. Maybe its true, maybe its not, I don't have the visual landscape to know for certain, and should not be taken as such. Think of it more as dinner conversation, in a one-sided sorta way.

Anyway, I was thinking about testing in loosly-typed languages, and how at the last company I worked for, where I only wrote in loosly-typed languages (Perl), that having tests written for our software was not only a Good Thing, but a necessity. There were many, many problems we caught via tests that we would not have caught until they bit us in a production environment.

However, most of C++ and Java code I've seen recently doesn't have any tests, nor with the complexity of the system could you test everything. Even without testing, the software runs, perhaps better then I expected. Although high quality software has been written without tests, so having tests is not a requirement for high-quality software, but that's not the point...

The point is more a comparison between strongly-typed an loosely-typed languages. In strong typing, the compiler does a lot of the checking work for you, even though in languages like C++ and Java, you have to be explicit about the type (which I find revulting, personally), so many of the tests you might write are already covered by the compiler.

In comparison, with Perl, you won't find out if you can call a method until run-time. This forces you to create tests that confirm that your code, can indeed, call the methods you want to call, on the objects you want to call them on.

So, in effect, part of your test suite becomes a simple-compiler, checking for certain things that strongly-typed languages have already checked. This poses a strange question, are you coders writing tests, or fixing a "broken" compiler? Is the compiler that broken to begin with?

Apparently, I'm not the first person to have thoughts like this (http://www.artima.com/intv/strongweak.html), but I'm no Guido Van Rossum, even on my better days.

Can software "Get Big Fast"

I recently joined a certain company as a software engineer, and during one of the discussions I was having, someone mentioned that it was a certain mentality (Get Big Fast), that allowed this company to thrive. I was pondering, as I often do, about how one could apply that to developing a software product, and if that is a reasonable software design model.

Moving to a software development standpoint, this means that the focus of the software product should be meeting the customers needs, and that all other concerns are secondary.

This means that things like adding new features, and cleaning up the interface, are more important then the condition of the underlying code. This does not mean that the underlying code is not important, it is just less important.

As an real-world example (the project which I am attempting to use this strategy on), say you have a system that parses FPS log files and generates static .html pages based on the data. This system isn't very large (about 6k lines of Perl), and its already partially broken up into several objects (~15).

Say that you now wanted to track a particular type of event that only occurs in one or two types of FPS logs, but not in all of them. Not only that, but on the reports, you do not want to display information that is possibly not tracked by that logfile.

Our example is a headshot, where a player shoots another player in the head. This is only tracked on games that log what location a player was hit in, some do, while others do not.

The "correct" way would probably be to have a set of attributes that each logfile has, and then have the reports only publish those attributes. But, there is nothing in the code that allows for this. Rather then create a larger scheme that will allow for future capabilities, you attempt to add that change in the fastest way possible. This allows you to get the new feature out to the customer faster, even though it may not be the best solution design-wise.

I believe that I can apply this thinking to an open source software project I am working on now (http://sf.net/projects/gamestats). I believe this software project is especially suited to this sort of philosphy. Its small enough that 1-2 people can wrap their head around the entire project, and easy enough to test the entire system that its possible to put out a release every day, given the time.

This sort of project can use the "Get Big Fast" design philosphy because you can keep track of all the little ugly 'hacks' you have put in. After you've gotten "Big", you can evaluate the code and refactor the appropriate methods.

Its a little along the lines of XP (http://extremeprogramming.org), but it advocates even less fore-thought, as code is secondary to customers. I do not know if this would work in a project of any real importance, but I belive MPlayer has adopted a similar strategy, where they do not concern themselves with the quality or the beauty of the code, and instead focus on adopting new formats as fast as possible.