VersiĆ³n en castellano

Tuesday 7 February 2012

Describing vs Coding

I like to start the development process just doodling some circles and lines in a blank paper page.I dont use formal symbols..and almost always, after two days, i really cant decypher what i was trying to express in it.

I think doodling is something many of us programmers do.What it's interesting, is that those doodles are the first bits of information about the system.Yes, very rough, too general, and too simplistic.But still, "information".

For me, this raises the question "The description of a system, is data, or code?".And, "If it's data, where is it?".The doodles are some sort of strange data.But, could it be possible to save that data in some way that it's usable for actually develop the system?

There are other ways to express the problem.If someone describes a website as having a menu, with 4 sections, one of them having a form where you can enter a comment, i bet that, with just that, you can already imagine a lot about that website.Because, implictly, the words "menu","section","form","comment" already have a lot of meaning.

Is it possible to actually start development with such information?

Ok, let's suppose we start developing the website, creating this file:



<?php
         $myWebsite=array(
                        "TITLE"=>"MyWebSite",
                        "SECTIONS"=>array("Home"=>"BLOG",
                                          "My Gallery"=>"GALLERY",
                                          "About"=>"PLAIN"),
                        "ALLOW_USER_REGISTRATION"=>true
                        );
         ?>
   


That would be a "doodle" written in php.I still don't know what the keys and values of that array really mean, or how they will be processed.But, i bet that, just reading that array, you may have an idea of what kind of website it describes.And that idea contains much more information than what it's strictly specified in that array.Intuition is being translated as "reasonable defaults" in computer programming.

Now, suppose you drop that file in the top folder of your project.Deeper folders will add finer detail.

Suppose we create then a "Sections" folder, and add the following file, Sections.php:


<?php
/*....*/
$sections["My Gallery"]=array(
     "GALLERY"=>array(
     "VIEW"=>"PictureList",
     "ITEMS"=>20,
     "OBJECT"=>"Picture",
     "SINGLE_ITEM_VIEW"=>array("VIEW"=>"PictureDetail", 
                               "ALLOW_COMMENTS"=>true),
     "HEADER"=>"DEFAULT",
     "FOOTER"=>"DEFAULT");
     /*.....*/
    


In the first file, it's specified that "My Gallery" is a section that follows a "GALLERY" pattern, whatever is that.It's still a vague notion, but it's safe to say it's some sort of listing.In this second file, we parametrize the pattern, with, again, more vague details.

In this file, i try to express that this gallery shows 20 Picture objects per page, and will use the "PictureList" view to render them.Also, if i choose to see a single item, i'll use the "PictureDetail" view to render it, and i allow adding comments to that item.

Still, i don't know how i'll handle all those "VIEW","ITEMS","OBJECT" concepts.I haven't decided what framework i'll use, what kind of database, if those arrays will be loaded each request, or used to generate code.I'm still describing the system, instead coding it.Iteratively, adding information about what the system is, in a format that is easy to manipulate and transform, so they really are *used*, they're not simply doodles in a paper.

Of course, the above examples are not really good examples for describing a website. In fact, it may be hard to express things in a php array (or xml, text..whatever) that intuitively you can see clearly in your mind.

I've been using this kind of approach for 5 years now, and use it almost anywhere, from model object definitions, to views, forms, pages,states,storage...Sometimes, the first time programmers in my team see those arrays, they are sort of surprised.But my experience is, once they understand the core of it (describe as much as you can, and code less), they seem to be happy with this "paradigm".

No comments:

Post a Comment