Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This is not purely a programming question.

I work in a large company. We have lots of code written in C++ language:

  1. Multiple simultaneous projects in progress and implementations that have to be supported.
  2. Multiple code paths due to first reason. Some are ~10 years old.
  3. Multiple target platforms. Most of the code has to be standard. Compiler specific code is frowned upon.(Which is a good thing I suppose)
  4. A large number of processes (>30 easily) each having in excess of 10k lines even in the smaller processes.
  5. 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.
  6. 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.
  7. 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.
  8. Most processes are performance critical. This is a huge incentive for people to adhere to C style coding and shy away from OOP.
  9. templates, STL and metaprogramming usage is near to non-existent.
  10. Use of third party libraries is next to impossible. i.e. No Boost! Oracle is an exception.
  11. 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.
  12. 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:

  1. Do we really need those features?
  2. 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!".
  3. 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). :)

share|improve this question
    
"...because the company is great" leaves me wondering, in what way? –  mojuba Nov 9 '10 at 18:34
    
Speaking relatively :). –  nakiya Nov 9 '10 at 18:36
2  
it is not a stupid question at all –  Paul Nathan Nov 9 '10 at 19:00
1  
You've got several questions wrapped into one, not all of which are on topic. This site really doesn't handle that sort of thing well. –  David Thornley Nov 9 '10 at 22:51
add comment

1 Answer

up vote 3 down vote accepted

"Working Effectively with Legacy Code" would be a book choice I'd toss out there as you seem to have quite the legacy albatross to manage. Legacy code can be its own big problem to handle, in other words.

I'd be tempted to suggest looking at how the overall process works and seeing if there are minor changes you could try to introduce. Granted you may have already been down this road, but if not then this is something I would throw out there. I wouldn't try to do a lot of changes at once, but rather just take one at a time and give a couple of months to see if it has taken root or not.

Some people may be comfortable where they are and have stayed put for so long that moving is rather difficult for them to do. While this may seem like a poor rationalization, it is worth trying to look at this from the other person's perspective. If the decadence is coming from new grads, then you likely have a different problem than what I'd likely see.

Another thought here is the question of how long have you been at this company. If you are the new kid on the block then making some suggestions may make you appear to be the whiz-kid that has come to change everything and ruin the beauty that others have taken years to craft for themselves. If you are rather new, I'd likely take at least 6 months of seeing how things work and ask questions to see why people do some of what they do. While you may frustrate some, it may be good to stir up other's curiosity.

As for the correct approach to this problem, there are likely to be various effective approaches and not just one, "Behold, here is what will fix all your problems..." kind of approach that you seem to want.

I tend to think the only stupid questions are the ones not asked. I usually like answering questions and you never know what you'll find when someone gives you an answer to a question.


In response to the first comment, I'd be tempted to want to go "eek" to some extent. There is the possibility that the new grads are just following the herd in a sense, but the inertia you're facing is fierce I fear. With the 1 2/3 years there, you do have enough time to likely have "earned your stripes" in a sense so there should be some potential to bring in new ideas. I'd tempted to look at the process and try to tweak that with some improvements,e.g. how are tests done, automated builds, code reviews, etc.


Ah, the second comment does answer a few things. There are 2 parts to doing continuous improvement to my mind, just to add here:

  1. Understand where your environment is now. In a way, interpretation is everything, which is why having an awareness of how things are now is important. How easily can you answer the question, "Where am I now?" would be another way to state this point as while you may find something, your company may already be doing it and thus it isn't a great suggestion to make things better,e.g. automated builds which you state you have.

  2. Find those elusive best practices and try them out. In a way this is the big hunting game you have now in trying to find where to do things better which can require some research skills, creativity, patience, and tenacity, I'd imagine. Good luck in finding them, as I'd like some resources on this too. Microsoft's Patterns and Practices may be a source though it may be hard to sift through it. If you have local user groups, this may be another way to find others from which to get ideas for experiments.

share|improve this answer
    
JB King: +1, " If the decadence is coming from new grads", yes it is there also. "Behold, here is what will fix all your problems...", no I know that that such an answer won't work. But what can you generally say? I have been in the company for 1 year and 8 months. Then why am I asking this question now? Because things happened in a way so that only now I am seeing the problems. –  nakiya Nov 9 '10 at 18:54
    
our builds are automated, and we DO code review. :( –  nakiya Nov 9 '10 at 19:19
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.