All the Perl that's Practical to Extract and Report

Alias on being a CPAN goon and building from components

scrottie on 2007-03-30T20:32:51

Alias replied to my last post with this gem. It was too good to just leave buried in the comments. The "or else..." line was mine, the rest is Alias' reply. Enjoy.

> or else Java goons come in and build the whole site out of componets

Hmm, I'm a CPAN goon that comes in and builds the whole site out of components :)

I keep saying this over and over again, but in the long run I find the only way to create large amounts of functionality over a period of time is by pretending that it's all eventually going to end up on CPAN.

I can skimp on the docs a bit (as long as the POD's there for the primary APIs) and I can skimp on the tests a little if I have suitably thorough empiric-type practical test scripts and become a perfectionist when it comes to regression tests.

But the basic structure of making most or all functionality as a CPAN-like distribution does seem to be the only way I can avoid the debt.

And once I got into that rhythm I've found I can generally found that it's not TOO hard to sell to management that it's better that we build most or all code in reusable "components" so that it can be used by people for other projects.

It takes longer the first time, granted, but there's no second time, and you can maintain development at a reasonable pace indefinitely.

Muah!

scrottie on 2007-03-30T21:01:49


There. Now that's unburied I can comment on it >=)

I took a half hearted stab at the black hearts of those quasi-programmers, the increasingly popular sort who only deploy modules.

You set me right. It's not over-willingness to deploy modules that causes me suspicious for their dedication and management's judgement in hiring them. Deploying modules is a safe route for the reasons you listed. Make the module test itself pretty well and then it's much less unit level testing the whole application has to do. It's almost cheating. But why not both write modules and deploy them? You're the author and the implementer. You wear two hats. Half of the time, you're concerned about the general problem as it applies to everyone or most people (reusable code); the other half the time, you're working on the suber sekret company specific business logic (deployment).

Without rationalizing it, I've done this, and other people in the company have before me. And it makes sense to minimize how much business specific business logic is in the code as this stuff changes. A lot.

This company has a "we own the code you write while you're on the clock" contract, which is a hell of a lot better than "we own all the code you write while you work here". I'm finding myself not invoicing for a lot of hours because I spent those hours working on a CPAN module. I don't think I can ween myself off of this. I think I have to stay contract. Or, more correctly, they need to offer me a bridge to this dicotomy if they want to take me perm.

So, it'll be interesting to see how this plays out. I'm taking a strong position for module based development. Will they accept and embrace it? Will they make it worth my while? Or will we just be at odds over it?

-scott

Re:Muah!

Alias on 2007-03-31T05:34:42

Well, so far my solution for the second problem (of getting companies to release stuff on CPAN) is basically.

"If the code is part of our secret sauce we have to keep it secret. If it's NOT, and just general functionality, then by releasing it to the community we get other people to test our code free of charge. And people that find bugs will often fix them for us, and we don't have to pay them for that either!"

(or situation-specific variations on that theme)

The second, and frankly easier, part of this is to make sure that the company agrees from the beginning that if I have to spend time working on EXISTING CPAN/Open-Source modules to bug-fix or improve them, then the company doesn't own that.