Recently my company has introduced a new policy that routes all incoming telephone calls into the development department as well as everywhere else.

This seems crazy to me as:

  • There is nothing worse than being interrupted from a complex issue by some silly job agent cold calling.
  • We are small but there is still a support team and receptionist.
  • The ringing is distracting.

I wondered what other short-sighted policies such as this you have seen introduced?


Running an intensive virus scan every day on developers' machines, in the middle of the day while we are trying to build and debug code. VERY annoying.


Years ago, I worked for a company that had just started development on PCs in C. Previously all development was on mainframes in Fortran.

The company policy was that each "module" had its own source file. This seems reasonable, except a "module" was defined by an entry point. So, in Fortran a "module" was a program, and in C, it was a function.

But having several hundred tiny C files wasn't that bad, because it never happened. Because the company also had very strict documentation procedures, which required 7 pages of documentation (including a cover sheet) for each "module".

So, you were left with the choice: Writing a properly structured and factored design (and then spending the next year writing phone-book sized documentation, of which 90% was boiler-plate and 99.9% was useless), ... OR ... just write massive functions.

Once, while looking through another developer's code, I found a 300-line case block, inside a 500-line switch() statement, inside a 700-line while() loop, inside an 800-line if(), inside a 1000-line while() inside a 3000-line function.


A Dress Code

No jeans, no t-shirts, no hoodies, no shorts, no sandals...

There should be a badge for that. - [Best Dressed Programmer]


Group policy that lets only the help desk install applications on all computers, including developer workstations. I can't even change the font in the Visual Studio command prompt.


Everyone will work from 9-5 because that's what our customers work. Of course, we were selling to banks, most of whom existed in at least 5 different time zones, and some of whom were 12 hours time difference from us, but somehow they cared if the developers at a different company worked banking hours...

37 accepted

I worked for a small company. Vacations were given by seniority and had to be turned in by March 31. There were times I'd put in for a week off on Feb 1, and someone with a week/month more seniority would put in for the same time on Mar 31 and bump me.

Or how about you get 3 sick days per year. Jan 1 your sick balance goes to 0. You may not take a sick-day unless you have 8 hours accrued (which means you can't take a sick day until sometime in May... and cold/flu season here is Jan-Mar).

But my favorite from this company (who was a Microsoft GOLD LEVEL PARTNER!!) is they decided that Source Control was too expensive (Microsoft gives away Visual Source Safe to its partners FREE), and complicated (it took less than 5 minutes at my next job to describe the features of Tortoise CVS to me, and most of that was waiting for the program to install!).


No Internet access.

Unbelievably stupid. My career at that place lasted two days before I handed in my notice - thank god for probation periods!


My ex-company (consulting) introduced the so called "objectives" for every employee.

You had to set at least 5 work-oriented objectives every six months, and then you discussed the results at the end of the timespan. The entire process was so complicated and time-wasting that at a certain point, when you pronounced the word "objectives" everyone was shivering.

Last note: no one ever knew how the objectives influenced your final evaluation.


Stupid decisions:

I work with a rather large company with offices spread across Europe mostly. For years each office had its own Internet access. Think ADSL line or so. That was very OK for Internet research, email, download patches etc.

Then the company decided that it's cheaper and neater if all offices use the same Internet connection. Now we have a fast VPN (that noone ever uses) and the ordinary Internet traffic gets through a single line for half a thousand people.

Guess the fun if you really have to download something large. In my case that's often a OS image from customer for debugging. With the old line the download completes within minutes. With the new line it may take a day to download 130 MB and you take down the company Internet line for half Europe as well.

Automatic updates of the various software that we use is fun as well. A 10 MB patch sent out to 500 people can take down the Internet for a day.

For large (100 MB haha) downloads we started to leave the office and do the download from home. That's faster and nicer for your workmates.

That's so stupid.


I worked at a company where it was decided that developers must never wear headphones or use iPods etc as it was unprofessional.

Of course, most developers wore headphones to drown out the noise of the sales department, which dominated the open plan office.

The headpone rule included listening to technical podcasts/screencasts or producing applications that used sound.


That our test information, setup, method and results, for Unix applications should be copied from flat files and pasted into an MS Excel spreadsheet.

Our team leader belives it doesn't exist if it's not an MS document!


At the last company for which I worked, I telecommuted from another state. The company used a standard form for all reviews across the engineering side of the company. Without setting foot in the office, I was marked down on my appearance by my boss. Guess I shouldn't have worked in my boxers quite so often... Needless to say, I don't work there anymore.


Even if you are prepared to pay for it yourself, you can not have a more comfortable chair than the CEO, and his was a cheap piece of junk for my 10 hours/day sitting ordeal.


We used to have a weekly get-together meeting for the whole company. Good intention, except that the meeting was scheduled half an hour before the regular working hours. On a Monday morning. For several years.

What followed was that the meeting was attended only by 50% to 75% of the company, certainly never everyone. Also people kept coming in while the meeting was underway, causing disturbances and everyone knew who was late this time. Even worse, everyone knew who was late or not even showing up at all on a regular basis. More often than not one of the team leads (who are supposed to present last week's work) came in late as well.

It has been argued that the meeting's schedule was so that it could act as a kick-off into the week and it was scheduled before the regular hours so no one's work would get interrupted.

However, those who needed to come in early on a Monday of all things weren't happy. No one liked coming late but some had to drive a long way through heavy monday-morning traffic but didn't want to get up extra early on a Monday to be surely there on time. And those who always came to work early still had their work interrupted, and actually wished the meeting would be even earlier.


Working in a non IT company, I think that the most annoying policy they ever introduced is to let the business part of the company have the final decision when it comes to purely "computer technical" points (and of course, being always involved in that choice).

This leads to SO STUPID decisions, simply because they just don't have a clue of what they're talking about. Wrapping all their decisions with cumbersome working instructions full of paper work and manual work to ensure compliance, they said.

We end up with absurd situations like this one:

One of the process step the development team had to do (and did for years before I came!), is to map all the requirements identifiers to the resulting input in the tool (for a data capture). The mapping process consists in putting in a database a row for each requirement mapped to an input, describing the whole thing. The business decided that this work should be done MANUALLY! More than 5K rows to be inserted one by one in a database by a person who should take care to avoid mistakes (and another one that will do a peer review).

When I saw this, I immediately wrote a little script that would do same job (without the errors). It took me half an hour. Now, it's been three weeks that they are trying to find a way to validate this script, because they still have more confidence in someone signing with his soul about the work he did for 2 weeks than what a computer can achieve in 5 minutes.


Every time you log on to one of our company's computers, you are greeted with a MessageBox saying (in effect):

This computer is company property. Every item stored on this computer is company property. Do not download or install illegal applications, do illegal activities, bla bla bla (text runs for 10 more lines or so).

Sheesh, like we don't know that.

For me it was annoying enough to block the server hosting the script that shows this messagebox with a "servername" entry in the "hosts" file. Works like a charm because the only thing that particular server hosts seems to be this messagebox script.


Every company I've ever worked for has wanted me to fill out a timesheet.

While that's bad enough, the worst part is that they never wanted me to state how many hours I actually worked. If I worked 7 hours one day and 10 the next -- no matter. I was always to put down that I worked exactly 8 hours a day, 5 days a week. Every timesheet was always exactly the same.


I once heard about a top-down decision to only use our local language (as in Danish), which on high levels make sense, but in code and schemas it gets very very messy.


Once I worked for a small company where the owner had a hobby of woodworking. Since we had some extra space in the warehouse part of our office building, he built out a woodworking shop there. Usually he just used it on the weekend so it never caused any trouble.

One year he decided he was going to hand-make the holiday gifts he gave to everyone that year, and he spent a bunch of time in the wood shop during work hours working on this project.

It was a bit of a problem for the programming staff because the wood shop was just on the other side of a not-very-well-insulated wall from our work area. Can you imagine trying to program with a table saw running a few feet away?

Fortunately the guy was a programmer himself, and after we complained he severely curtailed using the shop during work hours. But until that happened we had a very low productivity week or two.


We have a general policy of complete computer lockdown. This is no good when you are trying to develop software which involves say storing settings in the registry, or install settings or make changes.

Unfortunately the IT department think that I need exactly the same rights as a secretary typing on Word and Outlook.


I can't believe I forgot this one:

Probationary employees aren't allowed access to our servers for security reasons. Instead they are required to ask one of the senior devs to log them in. And then the senior dev goes away again. And there's only one admin account, so there's no audit trail if something did happen.


I was going to add this as a comment to Tim Farley's message, but it was too long, so I'll make it a separate message.

I once worked for a company who rented one section of a warehouse for office space. The other sections were rented to companies who used it, naturally enough, as a warehouse. So for the two years I was there, on the other side of a thin, and not-very-well-insulated wall, there were fork-lifts roaming.

I kept thinking... "just one wrong turn, and one of them would be crashing into my desk...."


Oh I have a great one. My company uses as proxy to block certain types of websites and as a policy they block ALL BLOGS!!! Every solution to a problem I end up googling would almost inevitably end up being on a blog, that is so frustrating. They also blocked Stack Overflow when it first started.


"What stupid policies affecting developers has your company introduced?"

No internal programming.

When I first came to work at the bank, there was a firm policy that no one was allowed to program. The reasoning was that we didn't have a staff of programmers nor a version control system to support legacy code. All development had to be outsourced so that consultants would remain responsible for support.

Unfortunately, getting a consultant hired to do even a trivial task took weeks. Their work was usually crappy and poorly documented since we tried to do it cheap. When it was complete we could rarely get the same person back to hack fixes into their buggy code.

The upshot of this was that instead of using real development tools to write good programs, we had users hacking janky crap out of batch files, Excel and manual processing.

Fortunately that has since changed.


All traffic goes through an NTLM authenticated HTTP proxy; it sounds almost reasonable, until you realize that includes DNS lookups. Now a majority of my command line tools simply cannot cope with that.

Oh, our Wi-Fi uses an unsigned certificate that must be installed on each PC. It therefore doesn't work with iPhones or other wireless devices that either A) don't accept the installation of a certificate, or B) require certificates to be signed.


I have to use my picture on MSN (we use MSN for custommer support), I tried to warn them that this would trigger a lot of customers canceling the service, but they didn't listen to me... I'm sorry for them.


I worked for a place that wouldn't let me have a Python or Ruby interpreter on a server system because "they are compilers".

They did however have a Perl interpreter on them. Perl is fine and I can use it, but I would very much rather have had the option of working in my language of choice.


Banning the use of USB pen drives.

We frequently need to copy stuff to/from customer machines that aren't on any network, but because some dork once lost a pen drive with some confidential information on it, nobody at all is allowed to use any pen drive at all.

Two problems with this: 1. it's punishing the many for the sins of the few. 2. I can't do my job without them.


I once worked for a company where the software project managers were all electrical, electronics, or mechanical engineers. Not a single software engineer in the bunch. Some of the electronics guys (and gals) weren't bad, because at least they had written code before (full disclosure: I come from an electronics background, but got my BS in CS). The worst project manager I ever had on a software project was a mechanical engineer.


I keep a thumb-drive with me at all time, containing a collection of tools to help be diagnose the various computer problems people ask me to fix. Recently, I used the thumb drive to copy something from my laptop to my office desktop PC, and accidentally left the thumb-drive plugged in overnight.

Every night, IT runs virus scans on every PC in the office. The scan flags one of the applications on my thumb-drive (lowlevel hard-disk reader) as a "hacking tool". Now, despite the fact that the scan clearly showed that nothing had been affected by the tool, and that it only existed on the thumb-drive, IT had to seize my PC and run a hard-code scan on it -- leaving me with no PC for 5 hours one day.


I had a boss who decided that during team meetings everyone should have a form so that we could rate each other on several measures such as "How clear was our communication" and whether we were attentive.

Fortunately civil disobediance won the day.


New management came in and decided we were all keyboard cowboys. He built his own functional spec template in a Word document and required us to fill out all 14 pages in detail. No blank spots acceptable. I had a few projects I had just finished up. His idea? You need to write functional specs for those old projects too.

So you want me fill out a 14 page document to describe how I'm going to do what I already did?


Contractors are not given user accounts to planning tools. They cannot officially be assigned any work.


We're currently fending off pressure to use Macroscope documentation for all projects. For those not familiar, Macroscope requires roughly 20-30 10 page requirement, spec, and design documents for every single module, describing your justification for why you decided to build this module rather than use an existing one, and what decisions you made when designing the module, and so forth. The problem: we've got over 200 applications that our 4 person group wrote over the last 5 years that would need to be documented before we could update them in any way.


The usual timekeeping complaint. I have to track my hours and leave detailed notes on what I'm doing. Then leave detailed notes in check-in notes. Then leave detailed notes in a weekly wrap-up spreadsheet.

We used to have an office that the coders shared, it was warm and we could close the door and block most of the noise. Now they want all of IT in the same area so we're in cubes next to marketing and sales. The noise from the people and printers can be incredibly distracting.


Quarterly meetings are two hours before working hours and in the middle of nowhere so that we can get back to work a full day.

The process for getting an application up to production or even a patch can be complex and time consuming than writing the actual app.

At the main office everyone has to take lunch exactly at noon and finish exactly at 12:30.

Heavily filtered internet access.



Fill the timesheet / Daily report for what I did every day

Either I have time to complete my tasks, or, fill the time sheet. I have no cue what is the purpose.


Write pure ANSI SQL


You should never write a program for a business logic. You should create your own (buggy) 4GL language and syntax (which is hard to learn and share) to do few very very simple tasks. Every single lines of codes must be generic and reusable that does not buddy with any business logic.


Try to do messaging without polling and any kind of server.


Dress Code


Work without Administrators rights (or even power user) on Windows.


When they built our offices, they put a server room off of the area where the cubicles were.

We have one rack with at least 8 servers in it, and it produces a ton of heat.

There is a vent and blower in the top of the server room, but the other end of that vent is on the other side of the wall point down at the cubicles, particularly mine!!

That means that year round, our AC runs constantly to keep the cubicles at an almost uncomfortable temperature of 75 °F (24 °C), even in the winter, when it is in 10 to 19 °F (-12 to -7 °C) outside and snowing (read: not often for NC), the AC still runs constantly.

Just last week the AC failed, and the temperature got up above 81 °F (27 °C) within about 20 minutes, and was getting hotter.

People complain all the time about being cold, but really they are cold only because the AC is always on and always blowing, but lucky for me I get to sit under the server room heat and suffer from heat exhaustion every day. If the heat was vented properly, the AC wouldn't run all the time, and the temperature would stay much more stable without the superheated server room air blowing around.

I finally emailed our VP about it in hopes that they can fix the problem.


An unnamed friend once worked for a company who did not allow the use of Python because "we are a company that works for money, therefore we don't use free software".

As for personal experience, I once had to design upon incomplete, but signed off specifications, and I resorted to prototype code to understand better how to solve outstanding issues. I was forbidden to do any coding whatsoever until the design was completed and signed off. Needless to say I did not care and I prototyped anyway. The final design and implementation were rock solid.


No more free coffee!


Having to estimate the time required to fix a bug without being allowed to review the bug report without an estimate to review the bug report.


My company changes its deployment process every couple of months. No one knows how to follow the deployment process anymore.

Also, they bought an expensive tracking system last year, only to replace with a different (expense) tracking system this year.

  1. We use VSS and do so in a fairly ungainly fashion. No periodic builds, not enough coordination between devs when working on the same project, and attempts to address this have been rebuffed.

  2. We have some internally set guidelines/rules/coding standards in plac, including how to do things like deployments. But they aren't uniformly followed, and indeed a mistake I recently made lead to a rebuking (not an unkind rebuking; I like my boss generally) but dev #2 (I'm third/dev #3, speaking in terms of time with the company and Boss has the most) usually skips most of it and that's been true for several years. I'm not always following them as closely as I should but I'm way ahead of the other two devs. This is really frustrating me, too.


One word: Scrum.


During the beginning of this recession we were told that we weren't allowed to work on internal projects any more. Oddly enough, two of us in the IT department were here specifically for programming purposes. We didn't really have any client projects that required programming. We were told to try and put in all of our hours towards client projects. Needless to say, a few weeks later when they were looking at costs, they told us that we were over budget and we needed to put our times somewhere else... so it went back towards internal projects.

Sometimes I just don't understand. I'd volunteer to only work 4 hours a day if that's what they really want!


Allowing the notion that if your working on a different project. We should be reinventing the wheel in different ways. Well... you get the point.


Almost a year I had to write things like

if (126 == someVar) then KillBill();
It surely a good practice, but at the end I even started to say things like "Gin, please turn down the TV volume if it is not used by you" or "you can use sucrasite if natural sugar is not preferred by you". I would rename this convention to "Yoda code".