Stack OverflowAm I an idealist?
[+88] [28] ereOn
[2010-08-20 09:58:35]
[ c++ career-development work-environment ]

This is not only a question, this is also a call for help.

Since I started my career as a programmer, I always tried to learn from my mistakes. I worked hard to learn best-practices and while I don't consider myself a C++ expert, I still believe I'm not a beginner either.

I was recently hired into a company for C++ development. There I was told that my way to work was "against the rules" and that I would have to change my mind.

Here are the topics I disagree with my hierarchy (their words):

One might think I'm somehow exaggerated things, but the sad truth is that I didn't. That's their actual words.

I believe that having separate files enhance maintainability and code-correctness and can fasten compilation time by the use of the proper includes.

Have you been in a similar situation? What should I do? I feel like it's actually impossible for me to work that way and day after day, my frustration grows.

(5) How are incremental builds not painful when they merge all header files into a single one? - jamesdlin
(8) you are assuming they are doing incremental builds - jk.
(3) It's a trade-off with how frequently you change the headers vs. change the class code. If you can precompile the single header and you have a huge number of source files it will definitely help, although it's more common to have a single header that #includes the separate header then pre-compile that. - Rup
(88) It's their money. Follow their instructions. If you can't, leave and take someone else's money whose instructions you can follow. Everything else just leads to headache, heartache and burnout. - JUST MY correct OPINION
(6) @JUST - well that's easy to say, but what about when you're given two (or more) subtly conflicting instructions and then held responsible for the outcome? - Ed Guiness
(1) Thanks everyone for your answers. Very difficult to choose one to accept in particular, so I ended up choosing the one that also made me laugh. - ereOn
I thought "#pragma hdrstop" was a Borland C++ feature that, since C++ Builder never became mainstream, is now basically dead? Anyway, those rules for header files aren't unreasonable in some circumstances. I've ended up merging header files to solve mutual dependency issues, where otherwise I'd have had lots of forward declaration issues that don't really fit the header-per-body file pattern either. A single header for everything is extreme, though. As for Boost, I both agree and disagree, for complex reasons that won't fit in a comment. - Steve314
(1) @Ed Guiness: You keep your head down and find another job. - JUST MY correct OPINION
@Ed Guiness: Sure, if you're given conflicting instructions and then they beat you up for failing to follow one of them, there's a fundamental problem. But the OP here doesn't say he was given conflicting instructions, just instructions he doesn't like. - Jay
(1) @JUST - That's a fairly defeatist attitude to take. Many times, these policies are in place due to someone who either didn't know what they were talking about, or due to previous technical restrictions. I think as a good developer, you can and SHOULD teach other developers about good software practices. But, to do this, you need hard facts to back up why your new way is good (don't ever trash their bad way, people get defensive). Of course, it's important to realize you may never change their opinions. That's when you should decide whether it is worth staying. - JasCav
If you thought you could change your bosses' minds and make them see the light, I think you'd be an idealist. Right now, you just seem like a software developer surrounded by managers. - Hooray Im Helping
(1) @Jason: My "defeatist" attitude comes from trying precisely what you suggest over and over again until I learned to avoid the brick walls flying at my head. Sure, maybe somewhere out there there's a company that is actually honestly interested in improving processes, but in the 99.44% of the remaining companies the best bet is to do what you're told and if you can't stand it find another job. - JUST MY correct OPINION
(2) Maybe you should have posted this to - Conrad Frix
Guess they never heard of make. if they are recompiling everything all the time no wonder everything is so slow. With make they should only be recompiling stuff that changes. Still if it is one of the main headers then the whole project will be rebuilt. - Cervo
@Cervo: They heard of make but their template Makefile is so badly designed, it makes you recompile everything since you change a header file, even normaly unrelated compilation units. I will try to show them how SConstruct can be even more powerful without the hassle of having to write dependencies by hand. - ereOn
(2) My sympathies, but 1. it comes with the job, right and 2. the question isn't specific in anyway to programming. Yes, it's a programming job, but a mechanic or plumber or salesman or cook could ask a fully analogous question and receive the same answers. - dmckee
@dmckee: Perhaps not exactly the same answers, since programming often involves creation, which not all job require. But I got your point. However, if I require an answer from talentend people and from a great community, there isn't much other places like SO ;) - ereOn
Interviews should be a two-way process. I'm curious how much of the wide candidate/role mismatch here surfaced during that process? - Steve Townsend
@Steve: There was no way for the interviewer to evaluate my my level: it was someone that had absolutely no knowledge in IT somehow. I could just ask for the generic domain I'd have to work on and the salary, everything else was kind of a surprise. - ereOn
Easy fix: just start saving your header files with a '.cpp' extension. The #include directive doesn't care ;) - sje397
[+117] [2010-08-20 10:19:12] Aoi Karasu [ACCEPTED]

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.


(11) Thanks for the funny (but true, i guess) answer, and for the reference to matrix: you made me laugh out of my distress ;) - ereOn
(1) You're welcome :) May sound funny, my opinion is serious, however. :) - Aoi Karasu
Even thought it's funny, I think it's a great and valid answer ;) - user62814
(4) Breaking the rules is a part of progress. - Helgi Hrafn Gunnarsson
+1 for the quote - quasiverse
At the beginning of the year I was reassigned to a different team and different project. I recently realized that stumbled across a similar situation. It took me a week to take the red pill. Starting a new job on Monday. ;) - Aoi Karasu
[+68] [2010-08-20 10:18:39] Sanjay Manohar

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


(4) "makes sure you name them with long names to avoid conflicts" - better still dont have names at all. file001.cpp, file002.cpp is the best way to organize files. Not just for fun, I have seen such filenames. - Nivas
All code should be in a single file... Sorry i don think it is ideal.. - liaK
(11) @liaK one file is still too many? - jk.
@ jk, Imagine single file that contains 100000 lines of code.. I wish I am not the person who's gonna modify it.. I believe in multiple files.. - liaK
(22) I think somebody didn't get the irony here... - Job
@liaK ever heard of sarcasm? - Federico Culloca
(11) I think you mean "Ideally the whole program should be in a single MACRO" for ease of updation. - Ed Guiness
@ klez, Whoof.. I must have been very serious with my own project... :) - liaK
(12) @liak - you can resolve that 100000 lines of code issue quite easily. Delete all the line ends and you have only 1 line of code. Also, you've saved some disk space. - Steve314
(8) I once worked at a couple where we were REQUIRED to give files meaningless, sequence-number names. The justification was that this way if hackers broke into our computer, they wouldn't be able to find the valuable data. They said you should keep a hand-written list of what all the files were. It seemed to me that (a) By the same reasoning, if thieves broke into the building, they could get the handwritten list; and (b) They're assuming that hackers are smart enough to break into the computer system, but don't know how to do text searches for the data they're interested in. - Jay
You all forgot one important point: the numbers for files shall be obtained through proper channels, including a review by legal department so that we don't use a trademarked number such as "Forever 21" (TM) - Arkadiy
Haha, when I read this I felt like I was on Slashdot. sarcasm_points++ - Adam Neal
Not just a single function - a single for loop - sje397
[+46] [2010-08-20 10:03:57] jk.

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?

(4) Disagree. Single files are significantly faster to compile in GCC than lots of separate files, even when using precompiled headers. But that doesn't mean it is a good reason to do so. Though I am speaking about source files, not header files, I suspect the result might be the same. - SoapBox
(4) assuming incremental builds and low coupling though you should end up with less on average. though point 3 suggests the real issue is their build process sucks - jk.
Why not propose to initiate some QIP to improve the quality of work instead - you'd likely gain recognition and respect and you wouldnt have to find a new job. - rmx
(3) well the business has to want to change otherwise you are just setting your self up for pain, regardless of who is wrong or right. life is too short, quicker and easier to find a new job. - jk.
If having only one file is better for compilation time, you could still maintain separate files and cat them together before compilation. - dan04
[+39] [2010-08-20 10:54:58] user331471

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!!

Good point. I think what you're referring to is just a lack of 'critical thinking'. I know what you mean though its a lot easier to simply go with the flow. - rmx
(14) +1 for Everybody believes but nobody knows... :) - liaK
(1) I think most of us here on SO go to the church of "It's better to know than believe" - which is why we're here and we ask questions. We want to know if and why the computer behaves that way. - Wayne Werner
(3) Sounds to me like you're going to the wrong church. You should find one that bases its faith on evidence -- apologetics -- and not just what somebody's parents or teachers told him or what he'd like to believe or what makes him feel good. That applies to both theology and IT. - Jay
[+14] [2010-08-20 10:11:14] Nicolas C.

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.

(1) Sometimes boost is hard to integrate with. Google allows only the approved boost libraries. Not that Boost is bad, but one has to worry about the risk of having too many things mixed in one place. In a large company there is little flexibility. - Hamish Grubijan
[+13] [2010-08-20 10:31:50] ssg

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.

Heard from one colleague: "Inheritance is only used in school, never in real life" Do you still believe they'll be open to change ? - ereOn
Every company is open to money. And a company is always open to change that brings more money. They just need to be convinced, or see that the change has a direct impact on revenue. You just need to connect the dots properly, push the right buttons for everyone to see it. - ssg
Given the above the easiest counterpoint to that is that, no, infact inheritance is widely used by myriad "real life" intitutions (mine for example); there is no end to the wealth of material on the Internet that can back that up. If they refuse to even consider evidence contrary to their point of view then you may have to consider the advice of others here and consider a change in employer. - cyborg
@ereOn well if they say this Inheritance is only used in school, never in real life now you know you are surrounded by people that knows nothing about C++. Leave them, you will not gain any experience staying there, and you will teach them nothing. - Stephane Rolland
[+11] [2010-08-20 10:03:43] Federico Culloca

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

If you can, leave that job immediately.

(7) This same attitude made me leave my job and guess what I am still not employed - satyajit
@satyajit: this doesn't mean everybody (or even most of them) will have the same proble. Anyway, good luck with your job-seeking - Federico Culloca
(1) I highly recommend looking for another job while at a current job. Use vacation time, then take 2 weeks off between the jobs. - Hamish Grubijan
[+6] [2010-08-20 10:22:09] Nivas

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.

(1) Why tell them? Just start a competing business so you can steal all their customers. After all, the customer is always right (although good marketing can get customers to do dumb things) - Wayne Werner
@Wayne Werner: Trust me, if by any means I was able to create a company that can steal clients from a company that makes over € of benefits each year, I would have ! - ereOn
@ereOn: you don't have to steal them all, just whittle them down one by one. Joel didn't steal all the customers from Github and Microsoft's Dynamics CRM, but I would be shocked if he hasn't had some converts. - Wayne Werner
[+6] [2010-08-20 11:08:12] Tynam

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.

[+6] [2010-08-20 14:29:36] Jay

(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?

Very wise answer I think. To answer your last questions (even if I guess, those are rhetorical): I work with people that can produce ugly code and who don't care because "it's just code". I'm not like them. I tend to enforce rigorness whenever I can (probably too much, yes) and often stay after hours just to make everything (in my code) "perfect". Being forced to do something I know for sure is bad is really frustrating to me. However, you're right when you say it is probably the case on a lot of other companies as well. I guess I have to find a why to care less about what I can't change. - ereOn
I'd love to work some place where all my co-workers were hard-working and capable. Maybe there are such jobs, but I've never found one! A wise man once said, "Don't let the perfect become the enemy of the good." If your workplace is really terrible, sure, move on. But if it's basically pretty good with just a few annoying problems, all you can do is live with it. What's the best you can get? YOu can only find that out through experience. Best wishes. If you find the perfect job, let me know if they have any more openings! - Jay
[+5] [2010-08-20 15:18:53] JustBoo

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

[+5] [2010-08-20 10:44:24] ChrisW

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

partitioning code in to files is not a means of changing the binary but making the code more maintainable - Rune FS
@Rune FS It's not really central to the language though; C++ doesn't require 1-to-1 mapping between logical classes and physical source files (that's just a convention; a good convention usually, but maybe not one that's worth being on the losing end of a fight about): it's more to do with people's programming tools (editors, find-in-files, source control, etc.). - ChrisW
@ChrisW never argued it was :) I was commenting on "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." it's not even an implementations detail. The sematics stay the same whether in one or multiple files so you need to look for the argument for splitting into several files outside the language I.e. processes and business value - Rune FS
[+5] [2010-08-20 10:28:25] George B.

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.

[+4] [2010-08-26 05:28:17] Troy Bourdon

Change your team or change your team

-- Andy Hunt

[+4] [2010-08-20 10:47:10] rmx

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.

Depends on your job really. That attitude when you're dealing with real-time systems, secure data or distributed processing is a recipe for industry-wide disgrace. - Rushyo
(1) If you're dealing with a safety critical system, 'good enough' code still applies but the 'good enough' is much higher :-) - rmx
[+3] [2010-08-20 11:05:28] Eike

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.

(2) Wow, that's some willful ignorance going on there. - cyborg
I know the feeling. Took two years to get over that hurdle... - Rushyo
(1) The "only Microsoft" decision was most probably about complexity reduction. With Boost having the reputation of being a tricky library, and Microsoft documentation often being available in German. And probably the mindset: No one gets fired for choosing the market leader's technology. - Eike
[+2] [2010-08-20 12:37:29] Nemanja Trifunovic

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!

[+2] [2010-08-20 12:53:19] David

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

[+2] [2010-08-20 10:47:05] JRM

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.

Are you suggesting that he refactor the company's source code, using the company's time and equipment, after he has been explicitly told not to? - ChrisW
@ChrisW - No, I would't suggest he violate any company policies. I'm merely suggesting that he work from within to improve his team's coding policies and practices. If he can use his own codebase to build examples his case would be much stronger. If he doesn't have the freedom to access this codebase on his own time, then by all means, he should find other ways. - JRM
[+2] [2010-08-20 10:12:00] Adrian Shum

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?

[+2] [2010-12-10 17:24:12] alpian

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.

[+2] [2010-08-20 16:17:39] frankc

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.

[+1] [2010-08-20 16:40:07] user426538

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?

[+1] [2010-08-25 06:21:21] Seb Killer

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.

[+1] [2010-09-13 19:39:30] Kelly French

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.

[+1] [2010-08-20 10:19:16] Andreas Brinck
@Andreas Brinck: Interesting. I would add that on certain target platforms, including 16-bit DOS and some embedded processors, intra-module variable access and function calls may be faster than extra-module access, but there may be a module size limit. It may be useful to design code so that modules may be arbitrarily grouped (by #include'ing .c files) without naming conflicts, and then join closely-tied modules together as much as possible. - supercat
[+1] [2010-08-20 11:06:40] tenfour

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.

[-1] [2010-08-20 11:01:12] Pavel Radzivilovsky

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.

(3) that's not what idealist means in english. - Matt Ellen
@matt Yes it is. Whatever slang you people attached on it, based on "ideals" is ridiculous. - Pavel Radzivilovsky
(4) Language is dynamic, you don't define a word and it stays that way forever. 'Idealism' to most people means something closer to thikning positively or having high ideals. - rmx
(5) Belongs to :) - Pavel Radzivilovsky
(1) Lakos's book (which was written a while ago) says that file I/O is what takes most of the time when compiling a large system. Perhaps O/S file system implementations have improved since then, but still. - ChrisW
(1) believing in god and thinking that the ultimate nature of reality is based on mind are not the same things - Matt Ellen
(2) Idealist can mean both someone who's taking a metaphysical position on the nature of reality and someone who hopes/strives for things in life to be "ideal". - cyborg