I worked for a small development company (C++/J2EE on a windows platform) that was bought out by a publishing behemoth, and the IT department idiocy was the primary reason I left. We not only had no administrative rights on our development boxes, but we had a *single* corporate configuration that was pushed out every night. Among the gems in this were:

• EVERY FILE OPENED was scanned for viruses, including newly created files. C++ compile times went from minutes to many hours
• Only one socket connection could be opened to any machine. Could not connect a debugger to a web app.
• Programs on a "dangerous" list were deleted from the hard drive in a nightly scan. Found this out when my wire sniffer disappeared.
• We could not use torrents or FTP. Had to download ISOs via HTTP

With these bozos calling the shots, it took less than a year to turn a world-class development shop into a ghost town.

Like it or not IT pals, developers have to do things on their boxes that normal users should not be able to. If you try and prevent them you will force them to come up with even more dangerous workarounds (tunnels to home boxes, dark nets, etc). If you're worried about security isolate their network, but don't make it impossible to do their jobs.

Couldn't agree more. A good architect making informed decisions (including when to break out the duct tape) is what separates the cowboy shops from the successful companies.

It amazes me that there are a ton of experienced people that are applying for architecture positions that think that coding is somehow beneath them. When I am applying for a job as an architect, I always tell the employer that I will need at least 6 months of "real programming" on the product before I will be able to do any significant architectural changes. You need concrete knowledge of where the bodies are buried to know how to proceed.

Without the trust of the developers (which is only gained by demonstration of competence) or knowledge of the underlying idiosyncrasies of the system, any change an architect makes is destined to fail.

Somebody give me an AMEN!

I've been through this a couple times in my career, and in my experience it's anything but a slow process. There's often 1-2 people that are the keys to holding a tight team together, and once one of them checks out it can be a mad rush for the door. In once case, a top-50 ISV that I was working for lost over 1/3 of it's engineering staff (and probably 75% of its experience and tribal knowledge) in a 6 week period, all because one key person gave up. And yes, this was during a "down" time in IT.

Unfortunately, I am going through this AGAIN right now. The small ISV I work for had a board fight where one faction ended up taking control and firing ALL members of the executive staff with software development experience, and replaced them with friends and contract executives (yes, such beasts exist!). The resulting display of incompetence has been excruciating to watch, and we have already lost several key people. There are still a handful of good people holding the team together against all odds, but my guess is we are one more resignation away from the tipping point.

It's no fun, let me assure you.

You forgot the worst Canadian season of all... Blackfly Season!

Even more amazing stuff for the mechanically inclined, from Massimo's web site: http://www.mogi-vice.com/Antikythera/Antikythera-en.html

As an amateur clockmaker, I have to say that his model is awe-inspiring. This is by no means a simple mechanism to build, but seeing what he did I am off to try!

There were some pretty good 3D games in 1982, but they were vector-based. Battlezone (a tank game), Red Baron (a dogfight game), and Tempest (too bizarre to describe) were all out in 1980/81, the wonderful Star Wars arcade game came out in 1982 IIRC. There were others as well, but these were the "biggies".

They go back significantly farther than that. I know SPSS was using major.minor version numbers back in the 70s (maybe even to the 60s), and I'm sure they didn't invent it.

Funny story from this, is that when SPSS was introducing version 10 there was apparently some consternation about having a 2-digit major version (not sure if it was a technical or a marketing concern, but it was a Big Deal to them). The solution? SPSSX version 1.0!

I've been working for ISVs for nearly 25 years, and for some reason have developed a "thing" about prime build numbers. It got to be a running gag at a couple of places I worked, to the point where at one place the buildmaster would bump the build number to the next prime number for the "gold" build.

Nice to know I'm not the only one with build number quirks..

I have been involved with a lot of hiring over the years, and have had amazing luck with guys from programs that did this. Certain languages are great from a teaching perspective, regardless of how widely used they were in industry.

For example, one well-known program in the midwest used Scheme/Lisp for the first 2 programming classes. By the time the guys in this program moved on to the "real" languages, they truly understood stuff like control flow, recursion, and stack structure. This meant that when they got to the C and assembler classes they were worrying about pointers and registers, and the Smalltalk and C++ classes could concentrate on objects and abstraction. Nice.

To quote my mentor back in the 1980's, "programming is prose, the language is just punctuation".

A few years ago, one of my junior guys was marveling at a hacked-together bash/sed/awk script that I threw together to do some testing, and asked how many programming languages I knew. I thought about it for a while, and came up with over 20 languages that I have used professionally in my (25+ year) career. Some I know to the depths of their existence (Smalltalk, C++, Forth), some that I became fairly proficient in (assembler, Python, Lisp), and others just enough to debug and extend existing code (Fortran, Perl, APL). Right now I probably couldn't punch out an off-the-cuff program in most of the languages I have worked in, but give me a couple hours to google the syntax and it will come back to me.

What's hard is understand what your program does, and why. THAT is why you go to university.

As an American ex-pat living in Canada, I have to say that I agree with your friends. Plus, you can add "will do you physical harm for not believing in their invisible friend" and "thinks Fox News is fair and balanced" to the list. And I lived in a "blue" state...

It's just obeying the first rule of computer science: Constants aren't
(second rule: Variables won't)