tags:

views:

736

answers:

10

For a while I have wanted to move away from new media towards web application development. Today I started a new job for a company specializing in CRM/Sales software. Their toolsets look impressive, shiney and Ajaxed to the hilt.

After my first interview a friend of mine warned me against the company as he knew an ex-employee who did not think highly of the product range. This was not a problem as they are currently redeveloping the whole product range to adhere to best practices. Or so I was told.

After one day I realize that the architecture of their products is horrific, and it is very asp 1.1 style. Sure theres alot of ajax fanciness going on and there are sprinkling of WCF and Microsoft Enterprise Libary thrown in there, but in general it's filthy. Test driven development isn't even a consideration and their processes are none existent.

Now, I am really feeling that the grass isn't greener anywhere. I dont think I want to stick it with this company but I am really starting to think that everywhere I look at will be like this under the hood. So my choices are:

1) Just accept it and sit back

2) Try to effect change

3) Look elsewhere and hope for the best

Now the reason I left my previous role was for some of the same reasons as I've found at this company. And I really tried hard to effect change, so I have no fight left in me for this again.

Am I being unreasonable to want to move to a company where I might learn something, and where people work in an ordered,logical way?

EDIT:

Great anwsers to this question in general, though I should address the "stick it out to get industry experience" responses if anyone else is thinking the same thing as me:

  • First of all I have industry experience, I acted as architect on one of the major project of my last company and I acted as team lead on varios projects.

  • While I do realize that architectural desicions can be limited to business needs the fact that this is a RE-DEVELOPMENT of an existing code base as that has become hard to manage I expect this to be developed well, but they are making the same mistakes all over again.

  • I do not want to be the "annoying new guy who tells the senior guys how to do things". But I dont not feel that the senior guys there should hold that title. They simply do not know what they are doing.

  • I do understand that not all development houses are agile/tdd/ddd houses. But are any of them? I would be happy to find one place that practices what is preached to us over and over again.

Edit 2:

  • Basically I am just bitter and as many people stated here I should have done more homework and treated the interview as more of a 2 way process. My Mistake.
+11  A: 

All three. Try to implement change while not getting stressed out if it doesn't work and always networking for new opportunities.

EBGreen
+10  A: 

You're not being unreasonable, but it sounds as if perhaps you need to do more networking and research to find out more about your prospective employers.

When you're interviewing, ask pointed, honest questions to other developers. Odds are that if you asked "Are you guys doing TDD", other devs aren't going to flat out lie. Ask about their processes. Ask what they see as their weaknesses in their processes.

The job interview is a two way affair. If things are really as bad as they sound, I'd say either you were lied to during the interview, or you weren't asking the right questions.

ahockley
+3  A: 

There exist good reasons to leave a company on day 1 (finding they've lied to you, finding you're not doing the job you thought you were) but a horrible codebase is not one of them. Succeeding in replacing a horrible codebase with a good codebase can be very satisfying. However it will take a long time - possibly years.

I would suggest finding out, very gently and tactfully, what your colleagues think of the codebase. Do they agree it's a mess? And if not, why not. If they agree that it's not good then you probably have opportunities to change it. But be tactful - remember you may be talking to the person who made the decisions in the first place.

There may be good technical or business reasons for using old technologies. If so, it's your choice as to whether you want to stay. But companies that have fully embraced the latest technologies tend to have their own problems. If it's important to you that you are working with the latest technologies I would suggest that you ask about it at your next interview.

DJClayworth
+4  A: 

Your concerns are completely valid, but your timing could be better. Now that you've begun employment, you'll need to strongly consider your options - and jumping ship isn't necessarily the best one. If you're still within a month of starting, you could legitimately quit and chalk it up to unmet expectations. Wait much longer than that and you'll have to get creative in explaining to future employers why you quit so soon.

You should also consider the history of the code you're concerned about - many architectural decisions are made for reasons other than pure technological ones.

In short, you may learn a great deal about the business of software by sticking it out for at least a year. Try keeping your eyes open for those priceless nuggets of truth, even if it hurts a bit. Remember, the sages of our business (Fowler, Beck, McConnell, Nielsen, Tidwell... ) gained their wisdom in less-than-ideal situations.

Justin
+2  A: 

Every place that has developed software will have projects like this and many times the new guy gets placed on it for a bit. Regardless though, I think you should hang in there. You mentioned that you want to try to change a bit and this sounds like a company that has a successful product and would be good on a resume if nothing else. Great code is very low on the benchmark of success (look at the code for Wordpress and you'll understand what I mean by that).

Regardless, I would recommend that you hang in there, learn from what is working and what's not, and propose ways to improve a process. Many companies like to recruit people that will assist in resolving some of their pain points so it may be a prime opportunity to make it happen. In addition, don't be afraid to look into ways to personally compensate for a process's shortcomings. Just because TDD isn't really plausible, perhaps some form of build script is if they don't use a build server and do a lot of manual items.

Hang in there and keep your eyes open on how things can be better. Every job feels overwhelming initially; it's when we take a step back and find the way through it is where we shine. Don't forget, developers can make the computer do anything we want :-)

JamesEggers
A: 

Let this be a learning experience. First when someone tells you that a company is not a good one to go to, be more willing to believe them. Second, review what you could have done differently in the interview to get a better picture of the what working there would be like.

Unless you can pop right back to your old job (which didn't sound as if you wanted to do that), then stick it out for a year and learn what you can. Learn what you won't do someday when you become a manager. Learn a few new techniques or a new language. Get more industry knowledge. Play with the poor design and see if you can improve it. Learn what doesn;t work well, so that in some other job when you are asked to design from scratch, you know what not to do (trust me you'll still make a differnt set of mistakes in thee design, but that is a whole other discussion). Learn how to make suggestions for improvement and get them approved by management.

Whether to continue looking depends on your work history. One short job won't hurt you too much, but if you have a pattern of staying at several places for only as long as it took to find another job, I would stick it out here.

HLGEM
Agreed, I should have listened and done my homework.
Owen
+1  A: 

Remember that there is no "One true way", and a lot of shops have gotten along fine without sipping on the Agile/TDD/Etc kool-aid.

The last thing you want todo is be the obnoxious new guy telling the senior people everything they do is wrong.

FlySwat
+3  A: 

My answer/comment has 2 elements.

ELEMENT #1 -- What should I do NOW?

Jumping ship early is not generally a good idea career-wise, although that is less of an issue for young folks. It also seems to me that you are worrying a bit too much about the technology. I would be willing to wager that there are parts of Google's infrastructure that are relatively outdated and cobbled together.

Ask yourself a few questions, which should help you figure it out.

Can you do good work there?
If the answer is yes, you should consider sticking it out. Remember that at the end of the day, Smart and Gets Things Done are more important than being proficient in a particular language or framework. This could be a great place to do good stuff.

What does your boss want to accomplish?
If your boss is just interested in keeping the place running and getting along, then you probably won't be able to make interesting stuff happen. But if your boss is interested in fixing the problems, then you are in a good place to help him and accomplish good things.

Where is the company going?
Is the company moving in the right direction, particularly from a business point of view? Are the products selling? Is the product direction and development plan sensible?

ELEMENT #2 - What should I have done DIFFERENTLY?

It seems to me that you had one set of criteria going into the job, and another set of criteria once you got there. Had you understood better what you are looking for, you could have worked to get the info needed. I suspect that you did not make your interview enough about the work you will be doing and the problems you will be solving. These two items (along with the people you will work with) are the elements on which a job evaluation must focus.

I suggest you read Nick Corcodilos (asktheheadhunter.com) and our esteemed leader Joel Spolsky (joelonsoftware.com).

Good luck!

tomjedrz
I do occasionally look at joelonsoftware.com, ill keep my eye on asktheheadhunter.com too. And of course coding horror, ayende.com, etc, etc. But thats my point, I want to work with other people who spend time looking at these blogs.
Owen
A: 

It seems that I answered the first question (What should I do?), and I answered the unasked question (What should I do next time?), but I neglected to answer the second question ...

Am I being unreasonable to want to move to a company where I might learn something, and where people work in an ordered,logical way?

The answer is an emphatic NO. These are very reasonable expectations, particularly the one about learning. Be careful about the generalization about how others (and the company) operate. Consider outcome as well as process, because there are many different ways to skin a cat. Many would consider an "agile" development process to be chaos (reactive, unplanned), while others thrive in it.

More to the point here .. how can you conclude after only ONE DAY on the job that you will not be learning and that people don't work in an ordered, logical way? That strikes me as a huge intuitive leap, and neither ordered nor logical.

tomjedrz
A: 

My suggestion is to consider revising how you interview various employers as well as how do you use recruiters to help you get a good job. Perhaps there are a few companies where you could put feelers out for what you want and see what they turn up. Chances are you are on a probationary period and thus could jump ship if you find something better. Make sure though you learn from this about what parts of the job do you want nitty-gritty details on and to see some of these things. Some companies will let you look at some of their stuff if you sign an NDA form which may be common at some places.

One idea when interviewing at prospective employers is to ask if they are familiar with "Joel on Software" or "Coding Horror" as if you want to work with people that read these blogs, then you gotta ask the questions to see if they do read them or if they live in their own little world.

JB King