Re: Why Perl is a Valid Choice

Replies are listed 'Best First'.
Re^2: Why Perl is a Valid Choice by g0n (Priest) on Feb 01, 2006 at 11:22 UTC
Managers don't know enough to do it themselves, and they put too much trust in what the code cowboys tell them Managers don't have a strong technical background, but they like to think they do (Ed's comments here are interesting) Managers don't enforce proper coding standards, or don't even have any Managers don't make their technical people learn more Managers don't give their subordinates the opportunity for formal training (in any subject) Managers don't know how to measure productivity Managers can't or won't solve personality disputes between developers Managers don't make their team work as a team Managers don't build a team with diverse skills and use workers are commodities Managers are afraid to piss off the tech guys Managers want to be liked Managers don't want to work Managers ultimately want to protect their ego There are some generalisations there that I'm not entirely in agreement with - remember, managers are people too. But your comments reflect something that I've been fulminating about for quite a while. Take a look at any job advert for an IT manager. What characteristics are they asking for? Line management experience obviously, but primarily business management skills, budget management skills etc. Technical comprehension is way down the list, on the rare occasions it even appears. It's my contention that to provide a good standard of service an IT manager must have a good technical understanding, as well as an understanding of business priorities. Not that an IT manager must be a world class coder, or a top notch oracle DBA; but he or she should at least understand the issues, comprehend software life cycles, testing principles, and be able to see without assistance where code can do one thing easily, and another with difficulty. That list is specific to managing coders, but the same principles apply to managing an internal IT department. Most IT managers make choices based on sales pitch, not on technical suitability. You don't have to be Donald Knuth to understand the relative merits of different products, you just have to have some understanding of them. Underlying this IMO is the fact that technical expertise is largely devalued by business people, so the business managers (possibly the board) who appoint the IT manager want someone with the same skills as them. The fact that they have half a dozen accountants who can manage a budget in their sleep, but no one who can tell them why a server costs more than a desktop doesn't seem to matter. In my perfect world, the IT manager would be a business oriented person who can code, but probably not very well. Someone who can meaningfully translate between business priorities and technical feasibility (am I bitter about not making the shortlist? You bet I am). But that isn't happening any time soon, so (to return to the topic of the thread) if we want to promote Perl to the people who make the language decision, we need to put cbrandtbuffalos very well thought out, and crucially non technical article in front of them - very few of them visit PM, in case you hadn't noticed. How can we do that? Suggestions are welcome, but perhaps identifying the right magazines, getting the right journalists on side, and getting well written, business oriented (not technical) case studies and articles out there. -------------------------------------------------------------- "If there is such a phenomenon as absolute evil, it consists in treating another human being as a thing." John Brunner, "The Shockwave Rider".	[reply]
Re^3: Why Perl is a Valid Choice by cbrandtbuffalo (Deacon) on Feb 01, 2006 at 13:48 UTC
The way I've addressed this issue of technical and non-technical managers is to try to champion Brooks' The Mythical Man-Month. Despite the age of the book, his conclusions are as amazingly relevant to coding today as they were when he wrote them. The bit that I've pulled out and harped on is that there should be two advancement paths within a technical department: project manager and technical manager. Both need to be equal paths, and people with equal experience and skill in each need to be treated equally in the company (authority, pay, etc.). Each significant project should have both a project manager and a technical manager assigned and they work together, each focusing on their expertise. This has been very successful in our shop. We have several people who are certified project managers and do their job very well. They handle allocations, schedules, and dealing with stakeholders. I work as a technical manager where I keep my hands out of the project management software and make sure the technical challenges of the project are taken care of. I know about other projects going on, I help with code reviews, and I make sure coders know about all of our shared code and best practices. You can't get this to work everywhere, but I feel rewarded for plugging away until we tried it. And the success has kept it going. The project managers really like having someone on the project whose job it is to know the technical bits. And I feel my time is better spent away from Gantt charts. As for you other point, I thought about working this into something that we could share somewhere else. I just wanted to vet it through perlmonks first. I'm in The Perl Foundation, so maybe I can ask about throwing up a page on the TPF site somewhere.	[reply]
Re^2: Why Perl is a Valid Choice by xdg (Monsignor) on Jan 31, 2006 at 21:58 UTC
Lately I've been busy correcting the work of lots of unsupervised programmers Hmmm. Maybe Perl::Critic needs some greater publicity as an automated management tool. :-) -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply]
Re^3: Why Perl is a Valid Choice by brian_d_foy (Abbot) on Jan 31, 2006 at 22:09 UTC
I don't think this is a technical problem, or one that we'll solve with technology. It's a people problem. If you already have a bad situation, an automated tool isn't going to make it any better. I know you said this with the smiley face attached, but the problem isn't the language. By the time people get to quibbling about the actual code, they've already passed through most of other problems that allowed that to happen. The best thing that people can do, I think, is work together. Programmers (or any other sort of worker) aren't veal calves to shove in cubicles. Although I won't go as far as recommending company retreats, people in the same organization should know each other, and know what other people are doing. For managers, this means actually inspecting the work of their subordinates and tracking its progress. You don't do that with an automated tool. You actually have to look at the code, and you have to think about it in terms of everything else. It's not just the syntax that's important, but how it relates to everything else. What does the code let you do? More importantly, what does it keep you from doing? What decisions does the code make for you if you allow a certain design? A good manager could use Perl::Critic, but tools don't and won't make good managers. -- brian d foy <brian@stonehenge.com> Subscribe to The Perl Review	[reply]
Re^4: Why Perl is a Valid Choice by xdg (Monsignor) on Jan 31, 2006 at 23:47 UTC
Turning off the smiley-face mode, let me say that on the topic of why Perl is a valid choice, I think the availability of tools or lack thereof does matter. One thing that the Agile movement has (re)discovered is the value of people over process. While that is true, managers of all stripes in all businesses still seem to want a magic bullet and get very excited about platform and tools -- probably because they are tangible when lists of abstract pros and cons are not always so easy to appreciate. That's an important consideration in making a case for a certain language. Look at the Software Magazine 2005 Jolt Awards. While I'm sure there's guru/advertiser bias, still, how many of those are for Perl, specifically? How many are written in Perl? If there are -- it was certainly hard to tell. Why doesn't Perl get more credit in this area? Perl has some good tools beyond just CPAN. To expand the attractiveness of Perl to IT managers, it's well worth playing up the tools it provides. Articles like the original post would be stronger for an articulation of the Perl tool chain as well. Of course, good managers will always benefit more from good tools than bad managers will -- that's almost a truism. But good tools can help good managers allocate their time more wisely. -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply]
Re^5: Why Perl is a Valid Choice by brian_d_foy (Abbot) on Feb 01, 2006 at 00:26 UTC
Re^6: Why Perl is a Valid Choice by xdg (Monsignor) on Feb 01, 2006 at 03:19 UTC
Some notes below your chosen depth have not been shown here
Re^6: Why Perl is a Valid Choice by glasswalk3r (Friar) on Feb 01, 2006 at 13:15 UTC
Re^2: Why Perl is a Valid Choice by jhourcle (Prior) on Feb 01, 2006 at 16:52 UTC
Managers are afraid to piss off the tech guys Managers want to be liked I've worked at a job where the problem was the exact opposite of these two statements -- the director of the department had been a consultant -- he believed that the solution to any problem was to throw bigger hardware at the problem, and that the tech folks were just an annoyance that he had to deal with. Because he came from a semi-technical background, he thought that he was instantly knowledgable in all things technical. I don't know about you, but I don't want an ear-nose-and-throat specialist performing open heart surgery on me. Likewise, someone who designed a Citrix solution for the company might not have the necessary skills to deal with a 35k user mail system. (hell, he didn't even have the skilsl to design a replacement Citrix solution years later, when the Citrix consultants were trying to explain that the system ran best on faster dual processor machines, and he had already blown the budget on quad processor machines that he got a good deal on (and were discontinued shortly after he bought them)). In this case, the management only cared if they were liked by other management folks -- they couldn't care less about the people who worked around the clock for 2 weeks straight to try to repair a mail system that had tanked. (but of course, it was the system w/ student's accounts that went down, not the one with faculty and staff, so it wasn't that big of a deal) When I was appointed 'technical oversight' for a project, whenever I raised an issue with a solution that our director had proposed, I got bitched at, and told I was wrong. (the director had actually threatened multiple staff members, and I heard that there was a meeting that he tried taking a swing at one of my former managers). I was informed after I was fired that he had told one of my project managers to try to force me out. I'll agree on some of the reasons for such occurances, but we had 12 'UNIX administrators', the most of whom sat idle, and there were two of us who did the majority of the work, because we actually delivered. (but although we were the only two focused on development, they left us doing production support, and then got pissed off whenever a schedule slipped) They spent lots of money on training -- they even sent managers to training, but didn't bother sending the people who were actually maintaining the particular systems because they couldn't risk having those people out for a week. Money wasn't really an issue, either -- management would go to the board of trustees, explain how they needed another $1.5mil, and when the quote turned out to be lower than they thought, they'd just buy more systems than needed (to sit in a store room for more than a year) ... and of course, there'd be no budget left for disk upgrades because of it ... well, there was money spent on disks, but they went to a different project, so we didn't have the necessary disk space for our project. In this case, the director wanted to micro-manage -- he specifically kept overriding what my managers (yes, I reported to more than one ... I asked for clarification once, and he told me I took orders from any manager who had an emergency, and he refused to elaborate on what qualified as an emergency, and who made the judgement) ... So yes, I'll agree on the management incompetance, but there are a few, possibly outlying cases where managers try to rule by fear, and/or spend the time sucking up to their superiors (when they're not playing Jedi Academy at their desk), and couldn't care less about being liked by their underlings or even trying to do a semi-competant job -- just the appeareance of doing one to their superiors. And they're perfectly willing to piss off the tech guys, if it means they'll go away, so they aren't around to expose their lack of knowledge.	[reply]
Re^3: Why Perl is a Valid Choice by adrianh (Chancellor) on Feb 02, 2006 at 09:38 UTC
I've worked at a job where the problem was the exact opposite of these two statements -- the directory of the department had been a consultant -- he believed that the solution to any problem was to throw bigger hardware at the problem, and that the tech folks were just an annoyance that he had to deal with. I've had similar experience. Some of the very best managers I've worked with have been completely non-technical. Some of the very worst managers I've worked with have been ex-techies. In my experience the divide between good and bad management has very little to do with technical experience, and a lot to do with being able to trust people to do their job well and remove the things that stop them doing it.	[reply]
Re^4: Why Perl is a Valid Choice by tirwhan (Abbot) on Feb 02, 2006 at 10:13 UTC
Ditto, oh so ditto! The one singular criteria which for me divides a good manager from a bad one is that the good manager will readily accept criticism from his "subordinates" and act on it (in a way that does not automatically involve firing the critic ;-). There are lots of others, but throughout my career this one has always been true. Unfortunately, the ratio of bad to good is atrocious amongst managers (probably worse than with any other job), because Managers are held in higher regard than other employees, thus people who are primarily motivated by status considerations tend to aspire to management careers There are few good performance metrics for managers People who underperform at their productive jobs are often pushed into management as a way to get rid of them Managers are often under the delusion that they need to "lead" people when they should actually be communicating with and facilitating communication between them People who do well at their productive jobs but are terrible management material (because they don't communicate well for example) are pushed into management as a promotion. I think this one is probably the worst, whoever came up with the notion that a move to management was a promotion did us all a great disservice. And for the record, I personally know I'm terrible management material (I believe I'm better than most I've worked under, but still terrible). I'm well aware that management is a tough job and requires several uncommon skills. I just wish the emphasis on employing managers was more on quality than quantity. There are ten types of people: those that understand binary and those that don't.	[reply] [d/l]
Re^2: Why Perl is a Valid Choice by sanPerl (Friar) on Feb 16, 2006 at 08:01 UTC
Let me just update you all with my personal experience. Mostly we use Perl . Our top managent decided to start few projects in Java, very recently. I casually passed this information to one of my friends, who is a Manager in a good Software firm. He advised me Not to go with Java, and his reason was purely Non-technical. Java professionals are in high demand and hence they don't stick to one place for long time. This makes project very unstable and Manager has to spend sleepless nights in planning hand-over and recruiting the similar talent.	[reply]


Keep It Simple, Stupid
	PerlMonks