What you need to discover is where the DBA draws the line between acceptable and unacceptable high level software layers and why that line is drawn. When you discover why, you'll know what objections are reasonable and what objections must be overcome. If possible, I would approach the issue as a negotiation of where the line should be drawn to meet the DBA's requirements.

Oh, he did a very thorough and well thought-out schema diagram... Like I said, “he's no slouch.” :-) Which is good.

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.

With the plethora of open-source software available today one would wonder why companies employ software engineers anymore.. surely all a company needs is a few deployment engineers and someone to set up the configuration files?

And yet a lot of businesses have unique requirements. Such that a generic package doesn't quite do what is needed, or does too much and places the company at risk by having excess functionality that could be abused or affect the core function in an unintended manner.

A number of questions come to mind. What objections does your client have to a pre-packaged solution? What experience has he had with other applications that come to your mind? What experience have you had with other similar applications?

Beyond the technical there also lies other questions: are you being paid contract rates to develop the custom application (the more work the better)? Are you a permanent and your overriding concern is maintenance three years down the track (and hence use of an off-the-shelf product may be easier)?

Perhaps this company wants to sell the product you develop to other companies later on and they require exclusive ownership of the product.. There are many questions to be asked, both of yourself and of the client.

Easy: give him cost and time scales with and without using CPAN. A factor of between 10 and 100 seems likely, although it could be a lot more than that!

Good heavens, no! He might say yes! :-)

But that's good! Just study the prior CPAN art, perform the task in 1/3 the time it would take from scratch and pocket the difference (don't show him this node though). ;)

---

Perl's payment curve coincides with its learning curve.

But you could start by asking him what he means by "from scratch". And, after he explains it, ask him why he has those reasons. If you want to be cynical, ask him whether you should create your own database, programming language, and perhaps even the OS from "scratch", or whether it's ok to use existing software.

If you have a perfect data schema the app will practically write itself. Put it on disk and dump the Schema classes with DBIx::Class::Schema::Loader, tweak with some object inflation magic and the rest is just sessions and shipping tables. :)

Well, not really, but if you have an ideal data model, everything else gets drastically easier.

To convince him to bring in CPAN stuff, trying pointing to the communities. You can ask a question on the CGI::Application or Catalyst or DBIC or Rose::DB lists and get answers right away that would cost $500 from a contractor who had to look at custom code. All the popular projects have good churn on docs and bug fixes too. Plus, a post for "Convoluted Custom Perl Code Guru Wanted" is not going to be able to compete with "Catalyst Expert Wanted" in a year when he wants to extend it; both in responses and the ease of vetting candidates.

Wow, that sounds like a fun project and assured income for the rest of your life! Crafting initial tools from flintstone, putting together a computer without the aid of industrially premade parts, I'd reckon it'd take you several decades at least before you even get to the software stage. By the time the project is finished the singularity will have come and gone and rest of us will have to bring up the Wikipedia page to remember what a shopping-cart even is, but you'll have been in bread and butter for all that time.

Snide jokes aside, unless the client has some really concrete technical reasons for not building on existing software, you should dissuade him. A good tack (in my experience) is an emphasis on maintainability. If you get hit by a bus tomorrow (Dog forbid!), the client will have a much easier time finding someone else to support a system that is written using well-known components than a completely hand-rolled one. No matter how clear-structured your own code is, a large user- and developer-base with forums, wiki-docs etc. will always be more help in finding and solving problems.

If the client does have concrete reasons, find out what they are and do some research. Maybe a solution exists that your client just hasn't come across? Or you may have to write a bit of "glue" to help fit together his notions with an existing solution? This is all a bit vague, but you haven't really given any concrete problems for which one could suggest a solution.

Now I'm not recommending that you use this...it uses all flat files dbs, has limited admin features, and you pretty much need to know the code inside and out to change anything. BUT..... if you want to use it as a demo to show your boss the ugly side of do-it-all-yourself, feel free to download Perlshop-z

Personally, I would use it if I had small store, but it would be a bear to keep up with shipping cost changes, printing invoices, mail labels, possible new state taxes on internet sales, etc

1: Ask him why he's nervous. Then you can answer those reasons, instead of whatever you think they are.

The other posters have given some good answers for a few reasons, but let me point out another: Because if you use a good toolkit there are less likely to be mistakes. The toolkit authors will have spent more time and effort than you are likely to in writing it, and the other users have spent more time testing it in more unique ways than you would ever be able to think of.

So, a toolkit is more likely to make it work, and work correctly, then anything you are likely to write.

Using CPAN and other packages/libraries increases the chances of all three being satisfied.

Mission accomplished!   Thanks to you all!

Would you mind expanding on that a bit? It'd be great to know which advice helped the most and at what level of preexisting tools the project will actually be built.

A surprising number of customers want something written from scratch just so they own the code and don't have any licensing hassles. With works under the GPL or Artistic License, I find customers are usually okay with reusing them once the licenses are explained.

Other customers want things written from scratch because they don't want their competitors to be sold their business logic in the form of the software you develop for them. For this very reason my standard contract states that business logic and general utility code will be kept separate. Any existing utility modules remain the property of their current owners, of course. I retain the rights to improve and reuse any non-specific utility modules I bring in from my private repository or develop for the project and license it to the customer royalty free forever. Anything that has to do with the customer's actual business operations is a work for hire and I can't reuse it.

Some customers just don't know how customizable or even simply configurable existing software can be and assume they need something new.

It's nice to know what objections a customer raises for what reasons. It's even nicer to know how certain objections have been removed through communication.