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.