Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Nothing is forever (repost from my blog)

by zby (Vicar)
on Jul 20, 2009 at 09:56 UTC ( #781580=perlmeditation: print w/ replies, xml ) Need Help??

I have been writing about the scaffolding metaphor before - but after some conversations with my colleagues I realized that I did not do a good job there. I did not conduct well the main idea: nothing is forever. No library and no program is forever and we should not shy off from writing libraries that are useful only at some phase of the application construction. It is still valuable if you can quickly get to the point of having a preview, a simplified prototype of the functionality you need even if eventually you'll remove all of that prototype code from the project. This is very 'agile' and it is also 'worse is better (if you can have it early)' and those libraries, those tools that you use only temporarily, I call the scaffolding.

Now one would ask why write a library that is useful only temporarily? Why not include at once all the parts needed in the final product? There can be several reasons:

  • something that is only a part of the scaffolding in one project can stay in the final solution in another one
  • the author of the library might not yet fully understand the problem, and it can take years to reach the right abstraction
  • the distribution of possibly needed modification can be so uniform that there is no reason to concentrate on one of them more than on another one and it is virtually impossible to cover them all
  • and finally: nothing is forever - you never know where a project will go in the future and what you'll need to change
A good example (of the third point) are code samples from manuals - you copy them to quickly get something working - but later you modify it and sometimes you change every character from the original. Another one can be the scaffolding code in Rails - you can debate if it fits the first or the second or other points - but it was useful to a lot of people.

Every library can be used as scaffolding - so why not accept this and help the developers in using it that way?

Comment on Nothing is forever (repost from my blog)
Re: Nothing is forever (repost from my blog)
by zentara (Archbishop) on Jul 20, 2009 at 15:25 UTC
    I'm in a somewhat meditative mood right now, and would discuss the node title....nothing is forever .

    Is that some sort of deep psychic statement about the nature of the material universe?

    Only nothing (non-material essence ? ) can withstand the waves of Time that pound us daily. Atoms just get washed away eventually.

    There is hope in zero. :-)


    I'm not really a human, but I play one on earth.
    Old Perl Programmer Haiku
      Is that some sort of deep psychic statement about the nature of the material universe?
      I have the impression that in the literary critic circle the notion of a privileged author interpretation is long dead. Your interpretation is as legit as mine - so I don't see why there is a question mark at the end of that quoted sentence :)
        Your interpretation is as legit as mine - so I don't see why there is a question mark at the end of that quoted sentence :)
        Because “Is that some sort of deep psychic statement about the nature of the material universe!” is ungrammatical, privileged author or no. :-)
Re: Nothing is forever (repost from my blog)
by mr_mischief (Monsignor) on Jul 20, 2009 at 19:34 UTC

    To use the scaffolding metaphor more completely, I'll just make some notes about actual construction scaffolding that can be applied to the discussion. Scaffolding is usually something designed to be easily built up, torn down, reconfigured, and reused on future projects. Sometimes, though, a project is outside the norm by so much that custom scaffolding is required. The custom scaffolding is still cheaper and makes the job easier than working without it. If there's no need to reuse it then it's sometimes cheaper to make the scaffolding a one-off than to make it reusable and reconfigurable for the next job. The materials can at least be recycled.

    In code, your reconfigurable, reusable scaffolding might include things like test suites, IPC code, and commonly used modules. Some custom libraries might be bolted on here and there, and then those can be binned once this project is through with them. Perhaps some parts of those custom bits can be salvaged, but there's no reason to engineer them for indefinite reuse like the rest of the scaffolding because chances are your next job or the next phase of your current job will require something completely different. For the parts that really make sense to make reusable and generic, go ahead and do that piecemeal as those bits get used. For the parts that don't, don't bother with the up-front investment for very little return. Just do what gets you to the next part of your current project, and save notes on any really innovative bits in case you do need to replicate them. Tear down the scaffolding when you're done and the project is self-contained, and keep around the truly globally applicable bits on your truck.

    If it makes sense for your project to contain an exact copy of some of your scaffolding upon completion, leave it in there. If not, just use the scaffolding to support you while you build something more permanent. Sometimes you want to build something grand that stands the test of time, but sometimes you just need to assemble a place to stand while you build that.

    I've written this whole thing thinking about using scaffolding in construction and remodeling. If it sounds like programming, that's just the strength of zby's choice of metaphor. :-)

      Thanks! To be precise the scaffolding metaphor not mine - it is taken from Rails - I only observed that it can be used more broadly than for code generators.

      I am now thinking about writing Catalyst packages (code name CatalystX::Elements - playing the chemistry metaphor) that would add simple features to Cat apps. This has been tried many times - but now I'll try to make them really simple implementing only that much as to satisfy the basic needs - and leave ways to replace them.

        Please remember to use the CatalystX namespace or pick another name entirely once you pick a real name the code will inhabit.

      For the parts that really make sense to make reusable and generic, go ahead and do that piecemeal as those bits get used. For the parts that don't, don't bother with the up-front investment for very little return. Just do what gets you to the next part of your current project, and save notes on any really innovative bits in case you do need to replicate them. Tear down the scaffolding when you're done and the project is self-contained, and keep around the truly globally applicable bits on your truck.

      [emphasis added]

      Excellent advice which I felt should be highlighted. I'm always (it seems) struggling with this part, not so much because I don't create the notes, but because I have trouble locating them later.

      HTH,

      planetscape

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://781580]
Approved by moritz
Front-paged by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (12)
As of 2014-08-29 18:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (286 votes), past polls