Why do so many companies reinvent well-known CPAN modules badly and end up writing far too much code?
I'm a freelancer
I work with many different companies
Ten years Sixteen companies
A LOT of code
In many cases it's like they've never heard of CPAN
CPAN is good
CPAN is Perl's killer app
Modern Perl programming is (often) just plumbing CPAN modules together
Less code is good
Less code that you don't have to maintain is better
Well-tested code is good
Code that is  tested by hundreds of people on dozens of operating systems is better
Why would you ignore all that ready-written, pre-tested code?
Hold that thought
Is it really that bad?
A straw poll
Who doesn't use DateTime?
Who doesn't use DBIx::Class?
Who doesn't use Template Toolkit?
We are not typical Perl users
We read use.perl
We read The Perl Review
We go to Perl Monger meetings
We go to Perl Conferences
The average Perl programmer knows less about CPAN than we do
They aren't bad programmers
They just don't follow the Perl world as closely as we do
Perhaps their job involves using many different languages
Perhaps they have better things to do with their time than reading everything on use.perl
Perhaps they have a life
To return to our question
Why would you ignore all that ready-written, pre-tested code?
Reason 1: People don't know what is on CPAN
Reason 2: People don't know what is  good  on CPAN
Not everyone knows how to extract the jewels from the crap on CPAN
The Perl Echo Chamber strikes again
Be the CPAN expert in your company
Offer training sessions on CPAN modules
Draw your colleagues into the echo chamber
Resistance is futile
Reason 3: Not Invented Here
Some companies prefer their own code over CPAN code
“ CPAN code is unsupported”
Reason 4: Legacy Code
Newer modules didn't exist when code was written
Fair enough (of course)
But use the modern modules in new development
Refactor  when you have the chance
Reason 5: Older versions of required modules
Can't install DBIx::Class because DBD::mysql is three years out of date
Fear of updating key modules
Refresh your installed modules regularly
You do have a trustworthy testing environment I assume
(Tell management that the older versions are no longer supported)
Reason 6: Sysadmins
Some sysadmins don't like to install modules from CPAN
They prefer their operating system's own packaging system (deb, rpm, etc)
Find a repository that packages CPAN modules for your operating system
Learn to package CPAN modules for your operating system
Also Sysadmins like beer
Some vague and ill thought out conclusions
CPAN is good
Use of well-chosen CPAN modules can dramatically cut the amount of code you need to write
Use of  well-chosen  CPAN modules  can dramatically  cut the  amount of  code you  need to  write
Use of   CPAN modules  cut the  code you  write
Write less code
CPAN code will be better tested than your own code
Everyone needs help finding the good stuff on CPAN
Evangelise CPAN at your company
(I find DateTime is a good starting point)
Mention CPAN when talking about successes with management
Your sysadmin is your friend
(and often a good drinking partner)
Invite me to laugh at (and improve) your codebase
Dave Cross Magnum Solutions [email_address] http://mag-sol.com
 
Upcoming SlideShare
Loading in...5
×

Why do so many companies ...

2,165

Published on

Full title "Why do so many companies reinvent well-known CPAN modules badly and end up writing far too much code?

Published in: Technology, Art & Photos
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,165
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
25
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Why do so many companies ...

  1. 1. Why do so many companies reinvent well-known CPAN modules badly and end up writing far too much code?
  2. 2. I'm a freelancer
  3. 3. I work with many different companies
  4. 4. Ten years Sixteen companies
  5. 5. A LOT of code
  6. 6. In many cases it's like they've never heard of CPAN
  7. 7. CPAN is good
  8. 8. CPAN is Perl's killer app
  9. 9. Modern Perl programming is (often) just plumbing CPAN modules together
  10. 10. Less code is good
  11. 11. Less code that you don't have to maintain is better
  12. 12. Well-tested code is good
  13. 13. Code that is tested by hundreds of people on dozens of operating systems is better
  14. 14. Why would you ignore all that ready-written, pre-tested code?
  15. 15. Hold that thought
  16. 16. Is it really that bad?
  17. 17. A straw poll
  18. 18. Who doesn't use DateTime?
  19. 19. Who doesn't use DBIx::Class?
  20. 20. Who doesn't use Template Toolkit?
  21. 21. We are not typical Perl users
  22. 22. We read use.perl
  23. 23. We read The Perl Review
  24. 24. We go to Perl Monger meetings
  25. 25. We go to Perl Conferences
  26. 26. The average Perl programmer knows less about CPAN than we do
  27. 27. They aren't bad programmers
  28. 28. They just don't follow the Perl world as closely as we do
  29. 29. Perhaps their job involves using many different languages
  30. 30. Perhaps they have better things to do with their time than reading everything on use.perl
  31. 31. Perhaps they have a life
  32. 32. To return to our question
  33. 33. Why would you ignore all that ready-written, pre-tested code?
  34. 34. Reason 1: People don't know what is on CPAN
  35. 35. Reason 2: People don't know what is good on CPAN
  36. 36. Not everyone knows how to extract the jewels from the crap on CPAN
  37. 37. The Perl Echo Chamber strikes again
  38. 38. Be the CPAN expert in your company
  39. 39. Offer training sessions on CPAN modules
  40. 40. Draw your colleagues into the echo chamber
  41. 41. Resistance is futile
  42. 42. Reason 3: Not Invented Here
  43. 43. Some companies prefer their own code over CPAN code
  44. 44. “ CPAN code is unsupported”
  45. 45. Reason 4: Legacy Code
  46. 46. Newer modules didn't exist when code was written
  47. 47. Fair enough (of course)
  48. 48. But use the modern modules in new development
  49. 49. Refactor when you have the chance
  50. 50. Reason 5: Older versions of required modules
  51. 51. Can't install DBIx::Class because DBD::mysql is three years out of date
  52. 52. Fear of updating key modules
  53. 53. Refresh your installed modules regularly
  54. 54. You do have a trustworthy testing environment I assume
  55. 55. (Tell management that the older versions are no longer supported)
  56. 56. Reason 6: Sysadmins
  57. 57. Some sysadmins don't like to install modules from CPAN
  58. 58. They prefer their operating system's own packaging system (deb, rpm, etc)
  59. 59. Find a repository that packages CPAN modules for your operating system
  60. 60. Learn to package CPAN modules for your operating system
  61. 61. Also Sysadmins like beer
  62. 62. Some vague and ill thought out conclusions
  63. 63. CPAN is good
  64. 64. Use of well-chosen CPAN modules can dramatically cut the amount of code you need to write
  65. 65. Use of well-chosen CPAN modules can dramatically cut the amount of code you need to write
  66. 66. Use of CPAN modules cut the code you write
  67. 67. Write less code
  68. 68. CPAN code will be better tested than your own code
  69. 69. Everyone needs help finding the good stuff on CPAN
  70. 70. Evangelise CPAN at your company
  71. 71. (I find DateTime is a good starting point)
  72. 72. Mention CPAN when talking about successes with management
  73. 73. Your sysadmin is your friend
  74. 74. (and often a good drinking partner)
  75. 75. Invite me to laugh at (and improve) your codebase
  76. 76. Dave Cross Magnum Solutions [email_address] http://mag-sol.com
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×