Lately I've been busy correcting the work of lots of unsupervised
programmers, and I've come to think something different about this
whole debate. It's not the tool that matters, but the people choosing the tools. Their decisions are not rational or based on technical merit, and we can't solve this problem with reason or merit. There are good reasons to choose Java for some things, just like there are good reasons to choose Perl for other things, or even Python or Ruby or something else.

The problem doesn't have much to do with the language. It's a
failure in management. Now, I know the you (Jim) use Perl in
your department, but that you also have regular training for
everyone, comprehensive code reviews, and that you follow the
technology. Not too many places I run into seem to do that,
even at the technical worker level.

Thinking about that, and after listening to an interview with
AT&T's Ed Amoroso,
and probably after reading a bit too much Joel Spolsky, led me to
think that the lack of management is the problem in these cases. Aside
from the usual, puerile generalizations about pointy-haired bosses, in my fire-fighting work I've noted several things that set up the problem. (Update: I'm not generalizing about managers, just some patterns of behavior I've seen from some people in those positions. Being a manager doesn't mean you do any of these things :).

Managers who don't know enough to do it themselves, and they put too much trust in what the code cowboys tell them

Managers who don't have a strong technical background, but they like to think they do (Ed's comments here are interesting)

Managers who don't enforce proper coding standards, or don't even have any

Managers who don't make their technical people learn more

Managers who don't give their subordinates the opportunity
for formal training (in any subject)

Managers who don't know how to measure productivity

Managers who can't or won't solve personality disputes between
developers

Managers who don't make their team work as a team

Managers who don't build a team with diverse skills and use workers are commodities

Managers who are afraid to piss off the tech guys

Managers who want to be liked

Managers who don't want to work

Managers who ultimately want to protect their ego

There are all sorts of reasons why any of those things might be
true, and not all of them are bad or even the manager's fault:

Ill-conceived company policy

Limited dollars and resources

Lots of work, not enough people

Fear of losing good employees because they might get better jobs
if they knew more

Time wasted in useless meetings

Incompetence

...and so on...

No language is going to solve any of those problems, but I've
heard many Java proponents say that they can take mediocre
programmers and turn them loose without worrying about them.
The problem there isn't Java, it's the lack or worry (which
you should really read as "supervision"). Managers don't
want to manage.

A language like Perl, however, just makes the management problems
more apparent, mostly because Perl doesn't let you blame some things
a Java programmers gets to blame (and sometimes with good reason).

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.

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.

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.

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."

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.

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.

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.

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.

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.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other