|Perl: the Markov chain saw|
The Hacker is hired into a team of about 50 other programmers (half local, half offshore). The Application the Hacker is working on supports about 20,000 users and handles a billion dollars per year. It contains about a million lines of code... some of it dating back as much as 6 years, but still under heavy, active development.
So the Hacker takes a quick look at the code of the Application, and gets upset. There's a small number of global variables in it, which are bad. It was also written for perl 5.005 (before warnings was a module), and doesn't pass -w. That simply cannot stand, as the Hacker knows better.
There are modules in the application which implement the same sorts of functionality as various modules on CPAN. Of course, it is true that these modules do slightly different things, or are integrated into the other modules in the Application. Also, most of them were written into the Application before they appeared on CPAN (remember that the Application is more than 6 years old in parts). That doesn't matter, though, there should be no date module other than DateTime. The Application may have a unit-testing suite, but it is not written for Test::More, so it doesn't count.
The hacker has is charge. He will set these wrongs right. First, He's gonna put my in front of those global variables, rather than use vars. He's also going to remove all the warnings he can find. The code passes perl -wc, so it must be right, right? So He submits His changes. Seconds later, the other 50 developers start shouting obscenities, as one of the global variables He myed was the database handle in the startup module. So, not a single page in the application works anymore. It also turns out that many of the warnings were removed in ways which subtly changed functionality, which comes out later on in regression testing.
Any one of these things would have been easily caught if the Hacker had bothered to follow any of the evil "rules" which were laid out before him, or if he had tested his code before submitting it. But hey, "rules" are for suckers. They only slow down a real hacker.
But these things eventually get cleaned up, and it's time for the Hacker to bless the Application with real modules. You know, the kind that you download from CPAN (the only place where perl code is allowed to be written... except for that which is written by the Hacker). So the Hacker starts writing His unit tests in *.t files for Test::More, rather than in *_Test.pm files for the Application's unit-testing system. QA is not able to make use of his tests without altering their unit-testing processes and writing a bunch of new harnesses around Test::More. Eventually, they just decide to write *_Test.pm files around all of His *.t files. The confusion, lost energy and bickering is certainly worth the trouble. Now His (same) test code ends in .t. HOORAY! It's also a little bit longer, because it repeats some of the Application-specific things that are built into the Application's test system. Oh, well.
The Hacker wants to start using DateTime, in place of the Application's existant date manipulation module. The Hacker cannot understand why there is any resistance to this idea, whatsoever. Clearly, it's worth His time to do this. Heck, He'll even do it in His spare time, so nobody can even argue that the energy invested in this project is taking away from work that someone else is counting on. Forget that this would require retraining the other 50 members of the team, sucking up a couple of person-days worth of already over-taxed QA resources (remember that they're still busy dealing with huge gobs of regression errors from His perl -w work), and require the sysadmins to install a new bundle of CPAN modules on about 100 servers... about half of which are locked-down production machines.
So, at this point, the Hacker has decided that the architects, the QA manager, and the sysadmins are all a bunch useless twits. All the stories are true. Hackers just aren't given a fair shake in the Corporate World. Sucks, too, 'cause he was a smart guy, and he could really code well. He just couldn't lower Himself to test His code or take on any appreciation for the other people who worked at the Company.
Oh, well. Hope He enjoys working for Bill. That's bound to be less corporate. And I'm sure that the software, there, will meet His high standards of code purity.
In reply to Re: OT: Why Hackers dont do well in Corporate World