But then I could tell you about the guy who purchased a publishing house that was very succesful using MAC's. He decided MAC's were too expensive, so he went all PC. I used to be a big client of his, but last week he rang to ask why I don't use him any more? He expects not to make payroll next month. Nice Christmas present for his staff eh?

The world is littered with stories like these. Far too many competent programmers/engineers/scientist are ignored to satisfy the ego of managers who are often in those positions because they were not competent programmers/engineers/scientists and believed the rhetoric when they were told that management or marketing are the places to be. If I were you AM, I would be out of there pretty darned soon.

jdtoronto

Far too many competent programmers/engineers/scientist are ignored to satisfy the ego of managers

And far too many competent managers are ignored to satisfy the ego of programmers. I see this happen just as often, Programmer says 'we have to do this using x and y' but the company is already standardized (which has many benefits) on a technology with all the advantages of x and y. Programmer throws a hissy fit and ends up quitting or getting fired a few weeks later.

And before you ask, the two companies I'm thinking of are still very profitable, and would have tanked if they went with the programmer's advice. So it applies both ways, but since this is a 'developer' site, you'll usually only hear one side of it.

Entirely so!

In my 30 years of working I have been a researcher/developer by preference, but I have also managed companies for 20 of those years and continue to do so today. Stupidity knows no bounds and respects nobody. And right now, in this all Perl/MySQL/mod_perl shop I have a guy hired as an HTML coder who insista on performing valiadation using only client-side JS, swears by PHP and won't use templating in any little jobs he gets to code. But he is good at graphics and HTML which I hate loath and detest. At least I know I have subjected my opinons to rigorous analysis and I can give you a clear argument for the decisions I have made.

So I quarantine this guys work. When he works on a project of mine it is purely to generate templates, and he doesn't get to do any of the validation code because I have a module that generates the JS and matches it to the parameters that will be used when the Perl does the same validation server side.

My experience over 30 years is that managers are far too quick to discount the opinions of the engineers/developers and programmers. But they have to learn to argue cogently for their opinion, not just complain. However the ability to communicate, rigorously analyse and argue a case seems to be a dieing skill, not only amongst the managers, but for the programmers etc. as well.

jdtoronto

Well, you can argue about going all the way with that;

• We can't trust DOS, so we'll have to write our own operating system.
• We can't trust the Intel|IBM|Dell|etc. we have to make our own hardware.
• etc...

I did that once actually, but then I started reading about string theory and became concered that I couldn't trust the laws of physics.

So now I'm using .Net - so much more reliable.

What exactly does he mean by "outside code"? Does he consider the entire Perl language "outside code"? Outside code (to me) means a chunk of code written by someone *not* in your shop. At a stretch, modules from the CPAN could be considered "outside code". readdir is not "outside code" it's part of the Perl language.

To be perfectly honest, I've never heard anything more ridiculous in my life and I'd be a little scared if this bloke was my boss.

"outside code" is anything not-invented-here, i suppose. this issue came from a discussion on cpan, so he may not be making the distinction between internal functions and modules.

I think you can do that. For instance, some earlier implementations of threads in Perl were... a bit unstable. You could distrust those, without avoiding the language altogether.

Of course this is a dramatically extreme case: he doesn't trust a demonstrably stable part of the system, so that's a bit different.

-Tats

some earlier implementations of threads in Perl were... a bit unstable

They were clearly labeled as experimental where as readdir and print are not labeled as such.

there will be some database work later in this project. there's already some resistance to the idea of using db access modules. it's better to write them ourselves...

Simplest question to ask your boss - "What business are we in?"

If you are in the software business and are ready to duplicate the efforts of thousands of other companies in order to produce something better than they have, fine.   Money spent and time used _may_ equal profit later.

If you are not in the software business, however, why is your boss advocating the expense of producing something that already exists, is of better quality, and which is not _central_ to your business?

Next, walk him through the demo: use tools that he's comfortable with to create a new directory and populate it with files (show the inventory with Windows Explorer, etc). Demonstrate that both scripts produce the same correct output. (You could try including a timing benchmark, but this is probably not necessary.)

Then add some new file(s) to the directory, in some way that you already know will cause the "@list = `dir`;" approach to break (you could make it seem like a spontaneous idea to try something "new"), and run the two versions again.

You could explain to him that the "home-grown" approach can be fixed, if you spend more time studying the output of "dir" in all sorts of conditions and make the script a lot more complicated. But once he sees that the version with readdir works correctly, handles the hard case without needing to be fixed, and is shorter / easier / cleaner, he should be able to come to a proper understanding.

(update: If you actually carry through with this idea, it will serve to bolster a couple of very healthy attitudes: (1) test suites are useful, and (2) assumptions about the "right" way to code should not be enforced until they are tested.)

he said he wants to rely on dos as much as possible to do the work (this is a windows shop), so rather than use builtin functions like readdir, he wants me to use a system call to 'dir' and parse the output by hand

Is your boss aware that the format of the output of dir is almost certainly changing in the next version of Windows, due to both the filesystem *and* the shell being completely overhauled? When that happens, readdir will continue to work as expected, but all legacy applications that hand-parse the dir output will break and have to be overhauled. This assumes your shop is fully committed to forever remaining a Microsoft-only shop. (If not, there are much more immediate and thorny issues with hand-rolling a readdir replacement.) It'll take you several months to hand-roll something as flexible and reliable as readdir, and it will have to be redone in 2006, if not sooner, meaning *more* months of testing.

Ask your boss if you should also code everything in machine code and rely on loops for timing.

Not using CPAN modules would be a questionable and suspect decision, but there could be arguments for it. Not using builtins sounds like something out of a Scott Adams book. If your boss is serious about this, you should be thinking about maybe taking some certifications or whatnot in your free time on the side, with a view toward getting your resume all nice and shiny-looking, in case you should happen to need it.

$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
[download]

And his life for a time was good.

Then came the day his dofteare ran right into a performance wall.

Long story short, his superiors installed a guy over him with better software architecture chops and they redid all his work with improved design and yes, standard modules in common use wherever they could.

It was the focus on having the fun of rolling his own over paying attention to the overall context and design of the software he was building that did him in.

IMO, the ability to not have to roll around in the nitty gritty of implementation details and spending more time looking at the overall problem is a gift from the gods.

Use C#. Really, I'm not joking.

If he trusts Microsoft to make the OS, he should trust them to write the language. This will take more time, but will save you many headaches and cover you if something goes wrong. And it's not that a bad language either (better than C++ at least :)

I think you mean the Artistic license. If you just grab GPL code (even perl code, where there is no distinction between binary and source) and redistribute it as your own, you are quite likely to be in violation of the license.

(Update: I think this is a violation even under the Artistic license. Both require mentions of the licensing terms to remain, which kind of foils an attempt to pass it off as your own.)

Really? Why don't you post that part of the GPL?

Abigail

If it weren't for people stupider than me I'd be the dumbest person on the planet.



Plankton: 1% Evil, 99% Hot Gas.

I think this sums it up:


Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.
Author: Albert Einstein

smiles

Eh? readdir invokes the same system call as the dir command does. If he doesn't trust the function, how can he trust the tool?

Apply for a job where the guy above you either doesn't try to micromanage you or has at least half a clue.

01100100 01100001 01100111 01100101 01100101 01101011