|The stupid question is the question not asked|
[development] Let's get it started quick'n'dirty!by blazar (Canon)
|on Sep 09, 2005 at 08:28 UTC||Need Help??|
This is not a meditation strictly about Perl, or computer programming. Or computers in general. It may easily be adapted to other areas of human activity in which one has to "produce" something, be it for his own entertainment or professional reasons...
In any case I think that due to the eclectic, multiparadigmatic nature of Perl, this discussion applies particularly well to it. Thus, consistently both with this fact and with our being at PM I will implicitly refer exclusively to it.
Well, suppose you have to write a program to perform a certain task. How do you begin? I generally try to plan in advance its general structure and the "size of the problem" - a bad defined quantity, admittedly. But this hardly ever works, and eventually what I do is a quick'n'dirt first "draft" that does only one thing, or a bunch of things, out of the ones it should.
Now you realize that you must provide for further flexibility, and that to add it you can't simply insert a few lines of code every here and there, but first or later you must refactor part of what you already wrote e.g. into subs.
Then you realize that your subs need to maintain a state or that there are plainly too many calling each other with no evident hyerarchical relationship wrt each other. So it all begins to be hard to read and maintain even for yourself, let alone others! And you need to further refactoring into suitable classes and objects.
But you're not done yet: your code after several rewrites still looks like a bunch of patches over the first draft, so that now that you have gained a much better insight on the nature of the problem, it all looks so bad to you... and you feel like you may rewrite it from scratch, avoiding all the gotchas of the first try.
Well, generally I do feel like that. And sometimes I do rewrite the program from scratch, taking into account the experience I gained in the meantime.
Whatever, I get the job done. I do waste quite a few "production cycles", granted. But I think I couldn't do it differently. What about you?
Otoh, whenever you're in a situation like that and you say "Well, at least let's get it started quick'n'dirty and we'll see how this thing will evolve!" someone will object "No, this thing must be thought accurately", "if we design it in advance we'll save precious time", etc.
If, if, if! Maybe it's just me, but if I insisted too much on the design phase, I suspect I would never get out of it. Trying one approach after the other provando e riprovando you can eventually understand which one is the "best" for your application and of course for you.
Just my 2 Eurocents...