0

I started working in a relatively big company that unfortunately has its share of quite a lot of legacy code and I ended up spending an extra ordinary amount of time in maintainance and bug fixes.

I would like to switch project as on the surface there are other project that "seem" interesting. The issue is I am not really sure if it is any better there either.

I have asked some colleagues to see what's going on and they "claim" that they are involved in cool things but I don't really believe them as in one of the cases I know for sure he is the same situation as I am.

So my question is the following:

If I don't have someone I can really trust to make a good choice about swapping to another project is there a way I could find out myself (I mean if it is the same everywhere)?

One idea would be to do some "reverse" engineering i.e. start tracking each persons commit in the repository to figure out what he's been up to. But this approach seems to me irrational.

Surely there must be a better way?

closed as too broad by GlenH7, psr, Ixrec, durron597, Robert Harvey Jun 27 '15 at 22:47

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    I don't know whats better way for a dev to measure 'coolness' of development than looking at actual code.. I would look at what they are checking in.. – Boppity Bop Jul 31 '14 at 22:12
5

The main thing to figure out is how old is the project and is it replacing / converting another project or truly a new project not attempted before.
I would try and find this out by talking to the people currently on the project. Use some discretion of course, just ask them about what they actually do and draw your own conclusions.

You may also find the following viewpoints worth mulling over:

  • generally 80% of programming is maintenance and bug fixes.
  • consider legacy code to include... the code you currently have in production
  • legacy code is also the code that... pays the bills. and maybe your salary.
  • as soon as a new project actually goes live, maintenance and bug fixes are required.
  • new projects often have more bugs than anticipated so the switch to bug fixing is often quick.
  • 80% is maintanance and bug fixes?Surely this can't be right.This is too high.Who builds are these projects we see and use daily? – user10326 Aug 16 '14 at 18:34
1

TL;DR version:

Look at whether the project domain interests you, and look at the whole lifecycle, not just the code, to see if the activities going on are interesting to you.

Elaborating a bit:

To figure out where a project is in terms of truly new development versus maintenance and debugging, looking at the code and code checkins probably isn't enough IMO.

In addition you need to look at other lifecycle activities.

Are new requirements being defined? Can these requirements be met with modifications to existing code or is new code required ?

Is there design going on? Again, is this totally new development or modification?

Often the answer is both. New requirements and new design are often met with a mix of totally new development and maintenance and expansion of the existing code base.

So you can't necessarily equate maintenance and bug fixing with "uninteresting" - often some of the greatest technical challenges arise in these phases.

Finally, as to "cool" - that's too much a matter of personal opinion. To some, maybe working at Google or a Web startup is the epitome of "cool", but someone doing scientific computing, or embedded development, or medical software, might find Google uninteresting by comparison, believe it or not. So it's hard to specifically comment on that aspect.

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