This is not purely a programming question.
I work in a large company. We have lots of code written in C++ language:
- Multiple simultaneous projects in progress and implementations that have to be supported.
- Multiple code paths due to first reason. Some are ~10 years old.
- Multiple target platforms. Most of the code has to be standard. Compiler specific code is frowned upon.(Which is a good thing I suppose)
- A large number of processes (>30 easily) each having in excess of 10k lines even in the smaller processes.
- Multiple developers per process, multiple processes per developer, multiple owners for a process over time(Who may now be unavailable as some processes have had a fair number of owners). This means there is no definite authority on a process for some processes.
- Not all functionality of all the processes are used all the time. There may exist many bugs in your process you don't know about simply because you haven't come across a situation where a certain branch of code is executed at runtime. Eliminating all these are not so easy.
- Timeline constraints and allocation to multiple projects and multiple processes mean that developers are usually left with no choice rather than to make do with existing code and try and work around limitations rather than to radically change the coding of a process so that it can be much better.
- Most processes are performance critical. This is a huge incentive for people to adhere to C style coding and shy away from OOP.
- templates, STL and metaprogramming usage is near to non-existent.
- Use of third party libraries is next to impossible. i.e. No Boost! Oracle is an exception.
- Basic functionalities needed are implemented in libraries which expose C like interfaces which make you look like an idiot if you are trying to write something in OOP or using templates because every time you use them, you have to wrap them up to hide the C like interface or just forget about the whole thing and do C like coding yourself. Not to mention additional bugs you may introduce by trying to wrap. The libraries themselves have been heavily used and are quite reliable in most cases. So the natural inclination is to go with them in a time constrained project.
- People are not very receptive to new ideas. I do not have ANY idea how to remedy this. I myself am curious and willing to try out new stuff. I find it hard to accept when other people don't. Especially when those people are not in managerial positions. Management decisions I can tolerate even if I don't agree. But what is there to do about decadence in developers?
Q1: What are the questions I should be asking myself? Please note that I love C++, and I have no intention whatsoever of quitting my job because the company is great. And it's the best in my country.
Q2: What are the ways I can, and help others improve?
Q3: I had this discussion with a dev lead about upgrading our compiler to the newer version because it has a lot of nice features in c++0x and I thought the sooner we try to adjust to those, the better. His concern was the risk associated with it. Reasoning:
- Do we really need those features?
- Our current main OS does not support for compiler version XXX. Of course we can always use XXX, but if something goes wrong the OS can say "Hey, we don't support that!".
- It has to be a gradual process not an overnight one. (In my opinion this implies that we should always be a couple of years or more behind the current front)
I know this is not a "yes no question", but what is the correct approach to this problem?
Q4: Are all or some of the above stupid questions?
Thanks for any feedback.
p.s. Writing this has also made me realize stuff that had not occurred to me before. So I guess it would not go to waste if someone were to close this even without a single answer (Which I hope will not happen). :)