You have a problem with authority, Mr. Anderson. You believe you are special, that somehow the rules do not apply to you. Obviously, you are mistaken.

Lol mate, you're not an idealist. Your example shows, that you just cannot bend and go along with the company policy. Regardless of who is right or wrong. Just change the job if you cannot bear it.

You seem to know, what the Matrix is. So it's time to take the red pill now and leave it. Change the job, dude.

Cheers.

"Our build machine doesn't work with nested directories" :-)

I agree with your boss.

• All code should be in a single file ideally.
• If you have to use multiple files, makes sure you name them with long names to avoid conflicts. Also start filename with a number to keep them in order. The number should be long, to allow future expansion, e.g. usr/src/00000016_mainProg.cpp
• Never use classes, they split code up into numerous blocks that are hard to keep track of
• Ideally the whole program should be in a single function.

</irony>

start looking for another job, they clearly have no clue.

for bonus points email them this page when you hand in your notice

for the actuall points

• one big header is almost certainly harder to read and slower to compile assuming multiple headers wouldn't all need to be included everywhere
• #pragma hdrstop is not portable, and having lots of preprocessor directives throughout the file will impact readability
• umm fix the build machine then?

Somehow the same thing here, but to a lower extent.

Going to work for me is like going to church. Everybody believes but nobody knows.

My not so academic psychological explanation: When things start getting complex the human brain shifts down one gear and enters the "To believe is better than to know" mode. Very dangerous - its like a strong drug, you get addicted quickly and can't get rid of it.

Programmers that are in the "believe" mode for some years are really hard to talk to. They are bullet-proof against all of your facts and arguments because they are surrounded by so much believe that gives them security in their thoughts.

If they have a policy about header files you will have to follow it or otherwise leave the company. On the long run you can (maybe) change their mindset a bit. I had some successes here at my company but not as many as I wanted to.

I'm pragmatic and see your (our) situation as follows:

If they pay you (good) for being at work 9 to 5 and you don't have to do overtime because of their global header strategy, the mastermind build server or any other genius software development method they believe in - your fine for now. But consider, that as a programmer you will not improve. Your ideas will be in conflict with their myths and when the going gets tough, your ideas lose, as good and correct as they may be.

And remember... Do not start to be another believer!!

Mh, I just left University with a Master degree in CS, and before, I had a technical, professional formation towards programming, especially in C++.

Here is my opinion :

• You should not use separate header files for your different classes. One big header file is both easier to read and faster to compile."

This is totally against the spirit of C++ object programming concepts. The headers define the visibility of your classes regarding the entire project. Stupid.

• "Trying to use differents headers is counter-productive : use the same super-set of headers everywhere, and enforce the use #pragma hdrstop to fasten compilation"

This has nothing to do with compilation speed. Completely irrelevant. Never heard of a "super-set of headers" this is super-bull**.

• "You may not use Boost or any other library that uses nested directories to organize its files. Our> build-machine doesn't work with nested directories. Moreover, you don't need Boost to create great softwares."

They're right, programming was created in order to avoid reusing existing code. Who cares about libraries. It's definitely easier to start from scratch every time.

You are an idealist, and idealists are changemakers.

"Influence" and "Initiative" are two key competencies one can have in IT industry. It's not just you can quit your job or go along with it; you can also impose change. Sorry for sounding so Obama-ish. But in your career you'll always bump into people with their own bullshit pragmatism. Never think of quitting before trying your best to improve your conditions. It may not be a one day thing but you can develop a strategy to change things there. You can exploit the weaknesses of their existing standards. You can demonstrate to your bosses the increase of productivity by dropping some of that bullshit. Support your thoughts with academical material, documents, etc. If that too doesn't work, you can quit your job.

If you can change how things happen there, that would be one of the biggest accomplishments in your career and one of the highlights of your resume. I think it's very well worth the shot.

I think your bosses don't know what they're talking about.

If you can, leave that job immediately.

This is the sad truth in many places. I have been in such situations before (and am in a situation withch is kinda 50% better).

If these are general rules in your workplace, try reasoning out to them with your points. I have been in some situations where the company/department beleived such rules were really true. I was partially successful in proving them wrong. If possible try to have a discussion.

If you are not able to convince them, or they don't want to be convinced, find a new job, but tell them the reason - that they are living in assumptions and don't know what reality is.

Yes, you're an idealist. Good. You'll do more that way (although also experience more frustration...)

Your bosses are ludicrously wrong, but you knew that or you wouldn't have asked. You are working for them, so you have to follow their policies... but you're doing the job better if you change those policies.

The key question is: can you persuade them otherwise? Find out where this policy comes from. (The answer may be 'it just sort of grew up', in which case you'll need to wage a hearts and minds campaign to win over the key people...) Write up some discussion of the flaws. Remember: Business reasons. The reason to change it that will be listened to is never "it's stupid coding practice" but "it reduces our compilation productivity" or "it increases code maintenance costs." Discuss it with your manager and get permission to take it to whichever group's responsible. (Is there any chance you can transfer to, or befriend, the build engine team? Sometimes 'fix it yourself' is an answer.)

If you can't help change policy, or you keep being told not to try - time to start polishing your CV. Bad policies are routine everywhere, but a shop that has no mechanism to improve them won't be able to change when other stuff breaks either - so start looking for other opportunities.

(a) I certainly agree that putting all your headers in one header file is a very bad idea.

(b) If the companies build process can't handle subdirectories, I'd certainly look into fixing this problem. But as long as the problem exists, to say, "In a perfect world we'd have a build process that could successfully compile my code the way I want to write it, so I'm just going to write it that way even though I know it won't work" is, well, not a very productive attitude. I often think that I wish some language or tool had been designed slightly different, but I don't write code to what I wish the compiler would process, but to what it actually does process.

But my real reaction is, "These are your biggest complaints?! You should be jumping up and down for joy!"

At every job you are goint to have people above you who make decisions, and it inevitably happens that sometimes you think these decisions are poorly thought out. Sometimes the boss is smarter than you think, he knows things you don't, etc, and he is right and you are wrong. Sometimes you are right and the boss is an idiot. Even if you start your own company so you don't technically have a "boss", you have to satisfy your customers, and they will often demand things that you think are bad ideas.

You can always try to convince the boss to do things in what you think is the right way. Depending on the personalities involved and how long you've been with the company, etc etc, you may be able to change policies. Ultimately, if you don't like the rules, get a job somewhere else. But if you quit every job where the boss ever makes a decision you don't like, you're going to spend a lot of time unemployed.

You have to decide what's worth fighting over. Just how miserable does this make your life? How big a deal is it?

"Asking programmers to do something without giving a reason is treating them like small children - they ought to be offended by that." - Bjarne Stroustrup

I humbly modify to say a "good reason."

The good programmers leave, thus the dregs stay behind and get to run the "show." It's called the Peter Principle.

"Am I an idealist ?"

I think that Stroustrup said that the mapping of classes to physical files (source and header files) is one of the least good things about C++.

I agree with you, that my habit is to have different header files for each class.

Having said that, if they want to do it their way, there are probably far more important things to worry about, for example:

• Whether you/they are implementing the required functionality
• Whether you want the job
• How much it would cost them to change their conventions to match your coding style instead of vice versa, etc.

Mapping to source files is just an implementation detail; it's a detail that will be hidden by the preprocessor, the compiler won't even see it.

I don't understand their reasoning; but some developers use primitive tools for finding things in source code (e.g. if using a dumb text editor, finding a class declaration might be easier if the classes are all in the same header file).

I totally agree with your bosses!!!

Few things I want to add:

1. Never use functions, unless they are really needed. In most cases it is totally unnecessary to have other functions than the main function.
2. In case you need functions write them all in the same file. A program does not need more than one file. This will also reduce the compile time.
3. A logical conclusion of (2) is that header files are not needed.
4. Forget about classes / exceptions and other commonly used concepts. They are too complex and will slow down the compiler or will add unnecessary complexity to the program.
5. ...

I could go on forever, but I think that even your bosses should at this point realize that their complains and arguments for them are as absurd as the things I wrote above.

Change your team or change your team

-- Andy Hunt

I'm constantly amazed at the shortcuts people take in my workplace too. There are'nt such strict rules as you seem to have and the majority of the programmers are top-notch but when I started I couldnt help but think how I could have done something better.

Its something I've learned though: that you don't have time to refactor everyone else's code, acheive 100% coverage with your unit tests and everything else. It's all about 'good enough' code.

For being in a similar situation:

I was once told not to use Boost, because my employer wanted to be a "Micosoft only" company. They wanted to hear a "really compelling" reason why you use something that in not from Microsoft.

For what it is worth, I have never worked at a place where I would be 100% happy with the development practicess and process (well, except when I ran my own software company). You always need to adapt somewhat, and if you are lucky maybe they even listen to some of your proposals and improve over time. If not, just start looking elsewhere and be sure to ask the questions about the development practices during the interviews.

Good luck!

If everything was in the same file where I work, it would be "code delivery hell" where delivering locks the file out for others until it's done (ClearCase). I can just imagine the team of 80 here wanting to deliver changes to a single header/implementation that contains too many things and having to wait in a "delivery queue".

I suggest you do your homework and make a sound, reasoned argument detailing how changing policies will improve the development environment.

Start with some simple things. Try restructuring some of the large header files into smaller ones, installing a proper incremental build system, and demonstrate how some of the recent changes made by members of your team would have resulted in shorter compilation times.

When you find that Boost provides a good library to perform a particular task, keep track of how much time you need to duplicate the functionality in some other way.

Translate these numbers into dollars. Make a business case to show them that improving practices will lead to money saved.

In addition to that, you can do some research. Find published papers that compare the effectiveness of various coding practices. Look at some of the well-respected C++ authors like Scott Meyers or Herb Sutter. Try to find coding standards in your industry.

If you're armed with the right information and present in a clear, concise manner, they'll listen to you. Always remember though, to be respectful.

I am on your side

I think their arguments are just bullshit:

• Unless they are using pre-compiled header feature, bundling all stuff into 1 big header will never make compilation faster. Even they wanna use pre-compiled header, it is not necessary to put everything into 1 big header

• Don't forget #include is just like inserting the content into that position. How can having tons of redundant declaration fasten compilation? Their way is "counter-productive" indeed. Productivity is not just compilation speed. Maintainability counts too.

• It is their build tools that sucks, not boost. Yes, you don't need to use boost to write good software but why ignoring good tools if you can use it?

Clearly the rules at this company are absurd as as been commented on by many people. But i disagree with the selected answer as it's often not easy to just change your job just like that. You may be contracted in, or there may just not be other jobs going.

I find that these kind of strange rules (and i think every software house has them to some extent) come from lack of experience from the other developers, poor management, or, most often, a poor developer who got promoted into being a poor manager.

I'm always trying to learn and i'm always happy to teach and I think most companies employ people to not only do the work, but also to genuinely learn from them. Many programmers who have stayed in the same job for years often just don't know or believe there is a better way to do things. The only way to change their mind is to show them.

I use Test-Driven Development and it was only when I got a "wow" out of my team when I led them through a brown bag session showing how TDD is just as fast and much less buggy than their previous write-once test-never approach.

So, my advice would be to try to show them why your way is better through example. You have been employed as a professional developer so just DO the work according to what you know is the best practice. When my manager told me I was not to use TDD, i just refused and then proved why it was better. I didn't argue with him, I just continued to use TDD!

Your company will either see that your way is better and adopt it, or they will eventually lose all their developers (including you) to more modern firms. In terms of your career, it would be a great success story on your CV if you managed to bring them up to industry standards.

Compilation speed is an issue if you work for a company with a gigantic code base. Entire books have been written on organizing code in the large environments (see Lakos). "Best practices" are guidelines, not hard and fast rules. You have to use your brain when applying them. I don't know enough abuot your situation to say if these company policies are ultimately good or bad, but I can tell you that being consistent with the existing code base is more important than any of your complaints and is itself an important best practice.

Everything is a trade-off. How much time does your company spend every day compiling their code-base? How much time to do programmers spend changing code versus compiling it? How much time do people spend waiting for that big ol' header file to get checked back into CVS so they can add their changes? Are these different uses of time of similar magnitudes?

I'm curious about the emphasis on optimizing compilation time - it's about the last thing that would occur to me but I haven't worked on gargantuan bodies of compiled code. Does anyone have experience with applications for which compilation time was a non-trivial amount of the time spent during a day? What's the longest - versus typical - time spent compiling in the experience of people here?

It seems that fast compilations are the biggest priority for your hierarchy. They are even willing to sacrifice maintenance for this. IMO, they should really reconsider their position and try out cooperative compilation with tools like Incredibuild. In our company, we saved several hours of compilation without having to sacrify the most basic Good Practices.

I'm going to focus on one aspect of this question to keep the answer from getting way too long.

Their claim may be true, but only for FULL BUILDS. During development we avoid full builds because they waste time compiling things that were not affected by the change. The dependency tree in the makefile(s) on the build system are supposed to track that to minimize full builds.

Using a single large header will not speed up build times in every case. Assuming the class bodies are in their own files, each of them will have the master header as a dependency in the makefile. This means when ANY change is made to the master header, all of the dependent object files will need to be recompiled.

Essentially, they are doing a full build every time the master header is touched. Since most C++ build tools treat files as the unit-of-dependency, the object files have to all be dependent on that same master header, thus they all have to be compiled when the header is touched.

If their belief is that a monolithic header is faster, it's because they are using the full-build as their metric. Create two private branches, for testing builds of a monolithic header and another for a divided header, maybe into 10 pieces or so. Make the same change in the header in both branches and then compare build times between the two.

Realize that arguing about the build is less about logic and more about belief or perception. Also, policies like this sometimes have a hidden basis that the team may not openly admit. From what I gather in the question, I'd say that this team doesn't trust complicated build systems in the first place. Telling them to make theirs more complicated (remember, their thinking not yours) will run smack into their disbelief.

Some interesting links:

• http://gamesfromwithin.com/physical-structure-and-c-part-1-a-first-look
• http://gamesfromwithin.com/physical-structure-and-c-part-2-build-times

As all the other answers here should demonstrate to you, there are better employers for you. There are employers you can be proud to work for and to look up to, and maybe most importantly, that you can be happy to learn & grow from. You may want to look around and try to find them.

First, I oppose using the word 'idealist' in this case. Idealist == one who thinks that the ultimate nature of reality is based on mind, or simply, someone who believes in god.

Now, to your question. I don't think they are completely nuts - I can easily imagine how one can value compilation time badly enough to reshuffle all your software into unreadable mess of huge files and homemade basic libraries just to save compile time. From my experience, this approach usually fails, but it's not irrational.