|
Scary, Bad Code at New Company
Just took a new position in a big IT department. The code, it turns out, is scary.
* Object behavior strewn haphazardly throughout the front-end. Global variables everywhere.
* Routines are copied & pasted to create new routines with one or two different lines.
* Only a handful of "classes" used. Inevitably these "classes" are just structs because they don't have any methods except maybe one or two property accessors, or they just stateless modules of loosely related functions floating in space.
* They bothered to create COM DLLs, but all the objects work just like flat APIs... create an object, get a handle, blah, blah, blah.
* No comments.
* Functions the size of novels.
* The database has no normalized tables. There's no concept that a table might represent a particular kind of object in reality - tables are just like Excel spreadsheets. No keys.
* Literals hard coded everywhere.
* Dynamic data hard coded everywhere (i.e. if location = "Newark" then do this else if location = "Clarksburg" do that...)
Is this the normal state of code out there? Would you quit? Is it okay to ask a company to look at its code base before accepting a job? I didn't think so, but then how do you avoid accepting a job like this?
anon
Wednesday, March 24, 2004
I would say that, no, this is not the state of things at most shops. I took a contract once, only to discover a situation very similar to the one you describe. I ran like hell, but then, the year was 2000, and better jobs were easy to find...
If you can't/don't wish to find another position, I think the key question you need to answer is whether management is open to improving the codebase over time, or if they just want to maintain. Obviously, if they're in maintainence mode, they don't want to hear your whining about how bad the code is, they just want bugs fixed.
Rob VH
Wednesday, March 24, 2004
work, get paid, .....
i like i
Wednesday, March 24, 2004
Hey, do we work at the same place?
I kick myself in the ass often for not looking at the code before I took the job...
Sassy
Wednesday, March 24, 2004
I get code from 3rd parties like this all the time. I was debugging a library from one of our partners just yesterday, which depended on call ordering - because of globals carrying state being a big hairy mess. So, as is typical, they cannot even make their own calls in proper order because they have lost track of their own crap. I'm only glad that we've demanded the source - or we'd be delayed or shipping bugs.
Yes, this is the state of *much* code today. Its pathetic. My one consolation is that this is likely the last revision of code we deliver for this particular hardware. I hope to never look inside that load of crap again.
hoser
Wednesday, March 24, 2004
And people wonder why off-shoring is so popular. Maybe the off-shore code will suck too but at least it's cheaper.
njkayaker
Wednesday, March 24, 2004
How does your job relate to this code?
Are you going to be a)upgrading it b)maintaining and bug fixing or c)not having anything to do with it (other than you had a peek at it and didn't like it). If its b) then i would speak to the management about it - explain the situation - of course then you might get a reputation amongst the programmers as a trouble maker as i am sure some arses would get kicked because of this. I would speak to them if it is going to have a direct effect on you only - otherwise it might end up being made worse for you. If you are doing work on it then do your code sensibly with comments etc. I would be tempted to look elsewhere - it sounds like its been created with out any sort of plan and thats probably the way they work there.
Fothy
Wednesday, March 24, 2004
Basically I had to bring it up to managment when a feature add proved to be impossible given the timeframe (They need it yesterday)
The main problem with bad code is that, quite often, it works, and the organization becomes so dependent on it that 'fixing' really means re-writing.
By all means, document your concerns and be as specific as possible. In my case, senior management was very interested, especially when I could demonstrate major security flaws as a result of the spaghetti.
Sassy
Wednesday, March 24, 2004
It is the normal state because most people
aren't good at their job.
son of parnas
Wednesday, March 24, 2004
>> "Yes, this is the state of *much* code today. Its pathetic."
Yeah. What kills me is about this company is that they don't know the code is bad. To the contrary, they think this stuff is GREAT! A lot of the people who wrote the crap are now in upper management, and those who aren't have been deified. If you dare to mention anything about the sorry state of the code, you, quite literally, jeopardize your position. The only people valued here are the people who know the code inside & out: "Oh yeah, that bug happens because half of the business rule is taken care of in the GUI, a quarter of it is over here in this DLL, and the rest is a 'user training issue'".
anon
Wednesday, March 24, 2004
Hey, you must have taken over my code from when I was a junior!
Seriously, though, are you paid per solution? i.e. Do you get $100 each time you do a user-enabling release? I doubt it. Instead you're paid for days or hours of effort, with what results from those efforts being constrained by external factors. As such, quit the whining and (as I like it mentioned) do something about it. Seriously. Given that you ultimately get paid the same whether you walked into a gorgeous, idealist OO abstraction lovingly pruned and commented, or what you've described, it really doesn't seem like such a hardship.
Indeed, the opposite is true and the bar is so low that it should be incredibly easy to do good things. I've made it a "joke-on-the-square" that I can tune most large scale database processes to run in 5% of the original time (a 95% reduction), and I have done exactly that countless times a love it -- talk about easy goings. I don't whine and gripe and talk about how much of a martyr I am, and how such inefficiencies are so offensive that I refuse to fix them.
Dennis Forbes
Wednesday, March 24, 2004
Anon, another tact is to think that the product
did get done, is apparently selling, and has
provided you a job. That's not bad.
son of parnas
Wednesday, March 24, 2004
The problem here is that anon will probably be the one to shoulder the blame if he/she puts in a fix for one thing and it breaks the code in somewhere else, or takes too long to fix a known problem.
--
Wednesday, March 24, 2004
I work at a very similar shop. In a way I kind of like it. It's an interesting challenge to try and slowly swing things the right way without people objecting or refusing, and that's kind of fun if you like to study human nature! Also, when I write stuff that works well, people absolutely love it. So... Have a ball! Or if you find you hate it, leave. It's not for ever, and nor is my job.
don't think i'll put my name this time
Wednesday, March 24, 2004
My past experience is that sometimes it can be infuriatingly funny :)
Especially when your first assignment is locating a bottleneck, you have no profiler, and have to spread printf()s all over the place.
Seriously, though, I'd give it a try, and see how it works out. If you start having a lot of bad days, perhaps it's time to start considering other options.
Paulo Caetano
Wednesday, March 24, 2004
It could be intentionally bad and undocumented so the key people retain job security.
You could also pull a scam like at one of my previous employers. The codebase was a mess like you described, then when management was finally convinced to spend the money to rearchitect it, the key "architect" for the original broke off into his own "consultancy", then because only he knew how it all worked, they hired him at $150/hour to completely redo it. And all he did was subcontract out to three consultants who had zero domain knowledge, at half the rate.
24,000 hours and several years later we ended up with just as bad a mess as the first version. For example, they made a "framework" consisting entirely of C++ macros you had to know what to use, when, and in what order. Crap like DECL_TOKEN_CALLBACK_NOMEMBER(), with entire classes and methods nothing but these obscure macros.
But by then the "consultant" didn't care, he had pocketed $2 million and announced he was basically retired, but if we wanted more help it would now be $200 / hr. That's about when I left the company...
Nice scam if you can get it, though!
Wednesday, March 24, 2004
Now you know why you've been hired ... to FIX it
Liam
Wednesday, March 24, 2004
Write down wasted time from spaghetti code and lack of comments. At your first year's evaluation, pull it out along with examples of your clean, commented code. Show the comparison with the bad code and then the wasted hours you measured. Have an estimate for annual man hours you've saved. Then ask for more money and/or a promotion :-)
Joe Hendricks
Wednesday, March 24, 2004
This is the best scenario for a new job, you can MAKE A DIFFERENCE!
moses whitecotton
Wednesday, March 24, 2004
Anon, you're screwed.
The people who developed this "shite" are, in your words, "deified". You do see the problem, don't you? If you change or improve this stuff you will be seen as an arrogant upstart who is making the good guys who did all this great work look bad.
What you will probably receive will be a lot of flak because: BUSINESS is being conducted with this BUSINESS CODE that MAKES MONEY while YOU are BEING A PROPELLERHEADED WEENIE and FUTZING UNNECESSARILY WITH MAKING STUFF PERFECT THAT IS DOING ITS JOB. Or words to that effect. You will be on the receiving end of defense of mediocrity because "we have a BUSINESS to run here which YOU DO NOT APPRECIATE".
In addition to my war story about being canned after bettering irresponsibly bad code at a former employer, my *next* employer after that place had a similar setup to the one you describe.
The deal was that two of the owners had developed some of the core code used throught the product line. The stuff was a spaghetti coded nightmare. An acquaintance was fired after sitting in the middle of the crap and trying to work within the ego constraints of the owners for a couple of years.
Bored Bystander
Wednesday, March 24, 2004
>The people who developed this "shite" are, in your words,
>"deified". You do see the problem, don't you?
>If you change or improve this stuff you will be seen as an
>arrogant upstart who is making the good guys who did all
>this great work look bad.
Worked at such a place - one project - after 5 years it still wasn't good enough to charge money for. Our lead had only two years experience (with ZERO programming training before that). The 18 page "while" loops.
Nothing had ever been refactored. Business rule knowledge handed out in tiny little nuggets by the people who understood them.
I could go on and on.
I should have run out screaming the first day.
Cowardly Anon E. Mouse Coward
Wednesday, March 24, 2004
You should have screened them during the interview. There are ways to read into them.
An interview is a chance for *you* to interview *them*.
questions to ask *them*:
- do they use and understand design patterns?
- can you list some patterns you use in your app?
...etc.
These are questions *you* ask *them*.
Wednesday, March 24, 2004
I love these people who reply as if they understand. I've worked at 4 places in the last few years. At the first place they had hired various contract programmers to write their website applications. Joel claims rewrites are a waste of time. He has not been in the trenches imho. Anyhow, I used to cry "what awful code, we need a rewrite" as if I were the man. The more I learned the humbler I became. I saw old code that I had written and was impressed by at the time. At my current job I was given the task of handling changes to a CMS that had been written by geniuses at a dotcom. And yet the only guy who could make changes to it was just fed up with it. I was glad to get the job. Even though I had scored very high on "knowledge" of the language it was written in I had little production experience. And what I did, to the extent possible, was to begin to reorganize the code as I did things. I never told anyone I was doing this. They were so happy I was in the code time was not an issue and no change request came with an estimated time anyhow so I don't know if I was fast or not in turnaround time. Which would lead to another issue where I personally don't think turnaround time is as good as just doing it "better" than just weaving the code into knots. I really wonder about people who seem that coding standards might be a waste of time (someone passed an url to an article about this recently ... in support of "to each his own") or that people don't realize that sometimes it's just REALLY, really better to tear the building down. However, there are requirements embedded in code (not the comments usually but in how it works) which Joel pointed out to me and we all know how hard it is to get requirements. Also, side note, I began to use some public classes in the application and the supreme boss happened to get wind of it ... and ... it just turns out that he had been reading about how good it was to use classes like those. As a general rule I'll try to follow the stlye (or lack thereof) in code but if I'm going to be working with a code base and extending it then I will usually begin to reorganize it and I won't tell anyone since I'm not judged on how I organize my code (which personally I think I should be)
Me
Wednesday, March 24, 2004
been there . After I rewrote my colleague's messy code ( I warned the manager many times about it) that had a loop with 8 or 9 loop variables and number of copy and paste procedures that lack any logic, I was blamed for the original bugs , had confrontation with a new jerk-boss and finally laid off. So , as somebody mentioned if it were 2000 you would better quit asap , now it is di fferent story - do your best.
LI
Wednesday, March 24, 2004
> And people wonder why off-shoring is so popular. Maybe the off-shore code will suck too but at least it's cheaper.
You think senior management ever looks at code? Bad code is not the reason.
CEO On The Take
Wednesday, March 24, 2004
"I really wonder about people who seem that coding standards might be a waste of time"
The best thing about standards -- there's so many to choose from! In each workplace I've worked at there have been lots of lip service paid to standards, but overwhelmingly I have found that --
-The legacy code base often harbors evidence of several "standards" initiatives -- no one bases the standard upon the historical code, but rather the whim of the day. An MSDN article about C# standards come out? Well you better change the standards for your Delphi code to coincide. The code successively spirals into a massive mess because each do nothinger, when prodded into a minor amount of work, will carefully insert code blocks following new standards into code blocks following old standards.
-You can't get the people who incessantly talk about "the standards" to actually tell you what the standards are, because...
-`Standards' are often nothing more than a fallback criticism of those who don't against those who do. Overwhelmingly I have found that the "do nothings" are the great crusaders for standards (the non-existant ethereal kind), always ripe and ready to point out that you pluralized a table name or used an explicit join rather than the standard where condition join or camelbacked the public field.
Dennis Forbes
Wednesday, March 24, 2004
My recommendation is to not take it personally. Think of it as a big problem but you can chip away little bits at a time (vis Joel's "Never Throw Away Working Code").
Dan Maas
Wednesday, March 24, 2004
>I love these people who reply as if they understand...
As if you do? You didn't even really address the question. You're just making excuses.
I work in the trenches myself, so I know, I know that many, many companies hire people that don't have a clue. Which is why I contract until I find a company that passes *my* interview. Oh there are good ones out there, you just have to keep looking.
Wednesday, March 24, 2004
About standards. Maybe it doesn't matter in some languages. I do Perl and PHP. It matters. Show me code you need fixed that wasn't written with strict/warnings and find someone else to fix it. I'd say "one of our standards is to use strict/warnings when using Perl". Show me an app that needs to be fixed written in PHP that spans 10 - 50 and more files and uses globals and mixes html/php and I don't need that headache. I recently turned down such a job saying I'd rather wash dishes (solution would be a rewrite, a real rewrite). Do you people who think standards don't matter write code with IDE's where you just do drag and drop? I wonder. Or do you just happen to work on your own code or work at the JPL?
But back to the original question. The answer is obvious. If you need the job you do whatever. If you don't need a job then sure, ask the client how they do their work. For my current job I asked them how they did their work. Did they have a bug database. How were change requests handled? How did they do Q/A? Etc .... goes without saying. But if you are broke and just need a job ... you do what you gotta do.
Me
Wednesday, March 24, 2004
"Show me code you need fixed that wasn't written with strict/warnings and find someone else to fix it."
So that's your perl standards document? "1. Use use strict" Granted that is a best practice and should be a `standard' (and should be clearly documented in the organization), but I was moreso talking about the trivial nonsense that people with far too much time feel the need to standardize...I won't bother giving examples because there are too many to pick just a couple.
As mentioned, though, many of the people who constantly yap about standards can seldom point out where these standards can be found -- instead it's some sort of clique job security thing I suppose that they can pull out of their bass whenever it suits their agenda.
My personal philosphy is that unless something is clearly documented, unambiguous, and unilaterally agreed to by the people in positions to decide, then there is _no_ standard.
Dennis Forbes
Wednesday, March 24, 2004
Well arnt you an angry lil camper.
Fisty
Thursday, March 25, 2004
I think Me was just using that as an example. In almost all coding standards documents there are things there because some d*ck liked to write his code like that (put a space before and after every "(" and ")", perhaps), and there are things which are there to try and stop people making coding mistakes ("use strict", "when coding a comparison the constant shall go before the equality operator", that kind of thing).
Thursday, March 25, 2004
Yeah, code like that is normal.
And so is the thinking that the code is great.
I got a huge lecture at $FORMER_EMPLOYER about them needing to keep the code secret. I think that one ended up with me yelling at senior people in engineering about whether the company actually owned any code that was even worth giving away, never mind stealing.
I like the interviews which really stretch your C++ knowledge about how exceptions get handled and you need to have inhaled stroustroup to answer, and then you get into the team and they don't use exceptions because "There's something wrong with them: we just can't make them work properly..."
That's SO common.
I read somewhere that "1% of the population works in IT. 1% of them are any good at it.."
So true.
Good developers, *really* good developers are the kind who don't "make partial instantiation work", but regard partial instantiation as as much of an issue needing attention as assignment. To these people multiple inheritance is not dangerous, it's not even "sometimes useful"; it's like air -- it's just there...
These people are really rare. When you find them, keep them because they become the only people who understand what you're talking about. Personally, I'm marrying mine, and I'm not sharing him...
Katie Lucas
Thursday, March 25, 2004
Ummm ... I just wonder if some people throw the baby out with the bathwater. I told a contracting company I work for that they should get any Perl programmers to at least use strict and warnings in ANY code they write, no matter how trivial (because you know it will grow). The respsonse was that they did not want to restrict the imagination ... seriously. Talk about clueless. I think this requires some basic common sense. But to say that no standards are better than any is wrong imho. Balance. And again, I think a person's environment might influence their attitude about this. As I mentioned before, I work with a LOT of code written by others for whom programming was something they grew into.
Me
Thursday, March 25, 2004
This is one of the reasons I got out of software development. Even though I have the ability to deal with a screwed up codebase, I have better things to do with my time.
Yes, you should have asked to look at the code before taking the job, and perhaps discussed it with one or more of the developers already working there. In my latter days as a programmer, I always made sure to do this.
Consider it a learning experience. Work at this place while you look for another development job to replace it with. Oh, and make sure not to put in overtime, or to commit to any development schedules that are impossible to meet. (This is an issue when it is impossible to tell from looking at the code how long something will take.)
Donald
Sunday, March 28, 2004
Thanks.
888
anon
Monday, March 29, 2004
 Recent Topics
Fog Creek Home
| 
