The Old Blog Archive, 2005-2009

Study-Oriented Development

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.

One Response to “Study-Oriented Development”

  1. on 24 Aug 2007 at 9:15 pmtransient proofreader

    putting out fire