Your SlideShare is downloading. ×
Why do so many companies ...
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Why do so many companies ...

2,088
views

Published on

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

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,088
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
24
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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