Following up on what eye said, you need to get clarification from the client about the particular attributes he wants to avoid, and which ones he would accept or prefer, when looking at possible (pieces of) solutions that are already out there.

It could very well be that "from scratch" just means "not a 'turn-key' package where all you do is change settings in config files and fire it up". I could appreciate a DBA's reluctance to accept such an approach, because it means that you are accepting someone else's "first principles" about how the system should work, which means you have to learn what those principles are, learn how many options and safeguards there are to be managed and what they all really mean, and adapt all your thinking to the constraints and world-view of this foreign framework.

Some people actually do view all that as being more work than coming up with your own first principles and coding to those directly. Sometimes, this might even be a correct and sensible perspective.

But the roll-your-own perspective will be less sensible as the time-line gets shorter and/or the system gets more elaborate. Given the amount of detail the client has already figured out about the back-end, and the time you are allotting for spec'ing out the front-end, you should be able to step through the components of the proposed system and say "module X::Y already handles this in a general, application-neutral way, and it has a stable API, so we can just plug that in here". Then, suppose it turns out that most of these modules you're talking about are part of something like Catalyst or Jifty,,,

The point is to try to make sure (and make the client see) that the existing tools you want to use are fairly generic, fairly easy to figure out, and non-constraining. Maybe the most important thing is to arrive with a good, fluent working knowledge of the tool kit, and present it to the client in a way that makes it fairly easy to understand.

But beware the possible pitfalls: if, after work begins, the client ever hears you say something like "well, it turns out that implementing this detail will be hard, because module X::Y doesn't work that way, and I'll have to refactor...", you'll lose some serious cred. Say something like that more than once, and things could turn sour. I've seen it happen.

In reply to Re: "I want a shopping-cart but I want to do it from scratch" by graff
in thread "I want a shopping-cart but I want to do it from scratch" by locked_user sundialsvc4

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.