fiat lux

Lately I can find my way of developing an application is coming to its form. I call it “study-oriented development”. The thing is that before I start doing anything real, I do a great number of studies. For the past average Rails apps that I’ve done, the number has been 5 to 10. Usually the more study apps I’ve done, the better the result has been. For a Cocoa app, the number can vary more–but the safe bet is no less than 6. A project that has been the main theme of my past three quarters has already accumulated around 20 studies.

Interestingly, there’s another side of this discovery: if I’m not able to do studies (due to time constraint, or if an app has too many dependencies), then my output will generally… deteriorate, unfortunately.

Studies, or études in art talk, are luxury, though. It indeed takes more time than just working on the app / the problem itself, and you need many clean slates. Another issue is the “boilerplate” code (all the common initilization code, basic plug-in’s, config parsing, etc.) that you have to do in order to start a study. Fortunately for me no study is the same and I try to limit the scope of a study, preventing them, on purpose from growing into a fully-fledged app.

One thing that study shines is when you have a number of similar plug-in’s or pathways that achieve a given goal. Plug-in’s are a good thing, but they can be tricky as they are not necessarily easy if you want to pull them out. (For Cocoa/any C-related language project, it’s the pain of pulling them out of your source tree; for Rails projects, cleaning up generator-produced-then-manually-customized code can be a disaster.) Many plug-in’s can start grow into your code quickly. And then when a plug-in goes wrong, you find you’re putting out fire everywhere. A study on the different options can prepare me for an exit strategy.

lukhnos :: Aug.23.2007 :: tekhnologia :: 1 Comment »