Code smells galore. Can this be a good company?

Question

I am currently doing some contract work for a company. Now they want to hire me for real. I have been reading on SO about code smells lately.

The thing is, I have worked with some of their code and it smells. Badly. They use incredibly old versions of MSVC (2003), they do not seem to use version control systems, most code is completely undocumented, variable names with more than three letters are a rarity, there is commented out code all over the place, some methods take huge amounts of arguments, UI design is seemingly done by blind people... Yet they seem to be quite successful with what they do and their actual algorithms seem to be pretty sound and rather sophisticated. Since they mostly do DSP stuff, I am willing to ignore the UI side of things, but really these code smells are worrying.

What would you think of a company that doesn't seem to value readable code? The people are nice enough and payment would be good. How much would you value code smells in this context?

You see, this is my first job and SO got me worried, so I turn to you for suggestions ;-)

Edit: The MSVC 2003 thing turned out to be an overlooked requirement of the installer only. They are actually using MSVC 2005.

Answer 1

Code smells themselves aren't really the problem, it's whether the company listens when someone says it should be fixed that matters.

Answer 2

Submit them to the Joel Test, see their score, try to find something better if possible :)

Supplemental:

As a rule, code smells are not problems so much as they are symptoms. Try and find the source of the disease.

Answer 3

Well... You state clearly (though not explicitly) that you don't like many things there. Which implies you will not enjoy working there.

Answer 4

People are nice and payment is good. You have the chance of making a contribution, and it looks like a successful company. I've seen many very sophisticated but messy code, and you can tell them that you can help them in this area - that will give you a chance to learn their stuff and make things better for the company.

Answer 5

If this is your first software job, it will be hard for you to know. It took me a while to get a feel for what a good software company is (by my personal standards). If you are already working there then you've got a huge advantage though. Can you put up with everything you just mentioned? Does the team seem open to change and suggestions? If you could show them a compelling reason to say, use source control (wouldn't be hard), would they be open to it? If not, I'd certainly turn away. Otherwise, it's not necessarily bad.

No company is going to be perfect, it's more their attitude and how they adapt to their flaws that is often more important IMO.

Answer 6

What will be your position?

Will you have the opportunity to do something about it, thus proving your worth to the company? Or will you work with a pointy haired boss who doesn't know and doesn't care about the software?

Answer 7

Welcome to the real world. If nothing else, working on a messy project is a good learning experience and to be honest, not something you will be able to avoid. If the work is interesting, the people OK, and the pay good, take it. If it becomes too frustrating, find something else later.

It's like a journalist... they might want a job covering celebrity weddings or presidential elections, but they mostly have to take a job writing about dancing dogs or local spelling bees.

Answer 8

If their code was good, they wouldn't need any help.
A massive oversimplification perhaps, but you're obviously far more likely to find employment at a place where improvement is necessary.
More often than not, a new job means a new pile of software problems to tackle. That's what the job is.

What I've found to be really important is the people you'll be working with.
Are they dedicated professionals? Jump on that job offer, they'll be great to work with and you'll be able to improve the codebase a little every day.
Are they cowboys and hackers? Run away as fast as you can, they'll reject all proposed improvements and therefore it'll only get worse.

HTH!

Answer 9

Nice people and good pay vs. bad code formatting and structuring?

Think of it this way -- at another job you have a great codebase but the people suck. You can change the code formatting and structuring, but you can't change the people.

Get in there, get some experience in real world developing with people who it sounds like, while lacking in theory, know how to get things done.

Always keep in mind that the end user doesn't care what your code looks like. Not even a little.

Answer 10

When I worked in telecoms, what you described was rather common with small companies. The engineers were experts in protocols and DSP, but they did not have a software engineering background. They were not experts in software architecture, design patterns and all the latest fads in testing, but they produced solid products which the customers demanded. At the end of the day, that is really what matters.

Still using VS2003? So? Does it cause any bugs or introduce any problems that would be resolved by upgrading? Would it be worth the time spent trying to fix projects that are not imported and converted correctly by Visual Studio? Would it be worth the time to go back and fix problems introduced by switching compilers and run-time libraries?

No source control? A perfect chance for your to step up and show them the advantages of source control! I introduced SVN to a small company once and they were pleasantly surprised and really took to it. Be careful though, you may get yourself stuck with some boring work. I got stuck administering the repositories (backups, etc.) and access control...

No documentation? Sadly, this is very common everywhere. I'd love to see some statistics on this phenomenon.

Three-letter variables - sounds like you're working with electrical engineers!

Seriously though, its your first job and if the company is in good shape with good products, then get on board for the experience.

Answer 11

The lack of a version control system would worry me the most. Some time ago I adopted "What system do you use for source code control?" as a standard interview question (when asking questions about the company). Consider it to be something of a reverse fizzbuzz, something to find the truly unprofessional.

A company without version control in 2010 suggests to me one that is unable or unwilling to adopt good development practices, and the one time recently (i.e., since 1995) I was in that position I was intensely uncomfortable with the company.

Before accepting, I'd recommend talking with people in the company and seeing how interested they'd be in upgrading their development environment. Since you've been contracting, you may know some of your future co-workers well enough to judge their honesty. (I've been lied to before about what the company intended to do, so I no longer trust hiring managers's statements.)

Answer 12

When I started reading your description, I was thinking "You probably work for scientists, not software people" and then you mentioned it is DSP, which basically confirmed my assumptions. You need to understand what you are getting yourself into. They will never write code "professionally", and that's fine for them. Nothing you do will change that culture. You should join this company only if the following are true:

1. If you are disciplined enough to write your own code in a professional way
2. You are ok with other people producing slop code and dealing with it
3. You are more interested in increasing your domain knowledge than growing as a software engineer (which is A-OK. Growing as a software engineer requires working with other software engineers.)

Answer 13

Three sources of more real-life horror stories are the RISKS digest (aka comp.risks) moderated by Peter G. Neumann, and The Daily WTF web site which is less serious but still explores the real world experiences of software developers and IT professionals.

Finally the writings of Robert L. Glass, including some of his books such as Software Runaways, Facts and Fallacies of Software Engineering, Computing Calamities, Software Folklore, and Universal Elixir and Other Computing Projects Which Failed amongst others.

I think the answer comes down to the employer's attitude, and the willingness to improve. So a lot of it depends on your manager or senior developer if they have the final say about the source code. As Dr. Watson suggests, the source code may of been written largely or in part by engineers, who typically are exposed to Fortran (often Fortran-77) at school, and still follow antiquated restrictions and are not use or perhaps even aware of best practices of software engineering / development.

For a thought experiment, imagine yourself as Chef Gordon Ramsey stepping into a failing restaurant run by this employer, as his UK and US television show Kitchen Nightmares. Would this employer being willing to adapt to a more successful format to help themselves.

As far as passing a huge number of parameters, suggest that using structs and passing a single pointer pushes less data onto the calling stack so would be more efficient particularly if the function(s) is/are called often. (I'm suggesting that from a C rather than C++ point of view)

Because of the performance critical orientation of the code, using standard OOP techniques might be tricky to implement without a performance penalty, so besides introducing source control (and associated backups, a bug database, easy-to-use test cases from reported bugs, and a build system), a benchmarking / performance evaluation scaffolding might be another useful tool they might make good use of, so you can quickly make performance evaluations of potential code improvements.

As far as UI, one approach would be to suggest office copies of common UI and usability references, such as from Joel Spolsky, Alan Cooper, Steve Krug, Jef Raskin, and Jakob Nielsen.

Answer 14

Look on the bright side - at least you wont be scared to touch the codebase because you might not live up to high expectations :)

I guess the decision is whether you enjoy taking some messy code and cleaning it up?