Subscribe to Rahul's Blog        RSS Feed
-----

Prototyping a hobby project

Icon 2 Comments
As all good software engineering text's say - build one to throw away! A prototype!!

And so in my long hard journey to mediocrity in programming, I stumbled upon a decent enough idea to get working on it right away. I started out with C, pure ANSI C. And then gradually and ashamedly added some GNU specific stuff. And oh it was a joy, till I realized I had coded two simple operations in a week. The good thing was - the code was good (after all its C), the bad thing was - it took so much time to do stuff alone that my interest started to fade. That's when I picked up my old friend - Perl.

Humor me if you will (specially the purist kinds) but I actually built what I had coded in a week in C in a day of Perl. Of course I used modules, but all of them came from the standard Perl distribution on Linux. So here's my plan - I build my prototype in the highest level language I can find and know well (Perl in this case) and if it all turns out purrfect, maybe I can get a couple of smart guys to work with me on this in C/C++/whatever. This maybe a flawed reasoning but here's mine.

1. If you're working alone on a hobby project and you have no real work pressures - build a prototype first. If you get too bogged down in the details, you'll lose interest.

2. Pick a high (preferably the highest) level programming language you can find - like Perl in my case. The language should be quick in churning out code for your ideas.

3. The prototype should be as simple as possible, but no simpler. (Thanks Albert!)

4. Write code comments on observations you think will be important when you code "the real thing".

5. Get some (smart) people interested in your idea and start working on it.

6. As far as possible, phase out the prototype code one at a time looking at the comments you wrote following point 4.

Note that its possible that after you code the prototype, you realize your idea is stupid (happens to me a lot) - but hey, good thing you didn't spend a year writing something that you don't believe in anymore. In all cases, the learning will pay for itself. :^:

2 Comments On This Entry

Page 1 of 1

mocker Icon

22 July 2008 - 09:11 AM
The fast prototyping method is good. I am curious as to why you associate C code with good code though? Do you think Perl(or another high level language) isn't good enough for the 'real' program because of speed or some other issue? I think you might be surprised how fast interpreted languages are becoming.
0

rahulbatra Icon

22 July 2008 - 11:59 AM

mocker, on 22 Jul, 2008 - 10:11 AM, said:

The fast prototyping method is good. I am curious as to why you associate C code with good code though? Do you think Perl(or another high level language) isn't good enough for the 'real' program because of speed or some other issue? I think you might be surprised how fast interpreted languages are becoming.


Nah, I just meant good C code, not a flamebait for Perl vs C :D I work in a corporate culture where compiled languages are given more weight since they can be redistributed in a binary format. Plus the software I'm trying to build is closely related to a low level systems program (or will be if I ever am able to).
0
Page 1 of 1

Trackbacks for this entry [ Trackback URL ]

There are no Trackbacks for this entry

Search My Blog

1 user(s) viewing

1 Guests
0 member(s)
0 anonymous member(s)