Office politics and sh*tty code.
-
I have to disagree. It makes code easier to read, particularly in the case where someone else wrote the code and you are stuck working on it. For one thing it allows you to focus on just the code you want to see, with out having to sift through, and/or be distracted by hundreds of lines unrelated to the problem you are currently working on. It is productivity 101... If you are asked to pull the 3 of clubs out of a deck of cards that have been shuffled thoroughly, it will take you much longer to find it and pull it out than from a new deck in which all of the cards are in order by suit and denomination. It is the same reason databases have indexes. I will take code organized in this manner over code that is not all day every day. Finally, "using Regions to collapse groups of related functions" Is what I was/am talking about. I have no idea how you got "Regions within functions mean that region should probably be a separate function" out of my original reply.
Duty calls.... I wish I was deaf sometimes.
Ed Aymami wrote:
Finally, "using Regions to collapse groups of related functions" Is what I was/am talking about.
Then we're not in disagreement.
Ed Aymami wrote:
I have no idea how you got "Regions within functions
Because you didn't specify, but made a general statement about regions.
#SupportHeForShe Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
-
I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects. Now, I'll be the first to say in my day I've written crap, so who am I to judge right? But, over the decades of development I've done, I'd like to at least think I've learned what crap is and what's it's not. And as such, I find myself in a position at a job I've been at since mid February, where I tend to complain a lot - because the quality of code is so poor it's just sad. But, I complain because I want to see it improve. Seeing that nobody wants to be told their code sucks (even if it's true), I've been labeled a bit of a complainer unfortunately. And while I get that, the fact remains, the code is actually not that great. Which is pretty evident by virtue of the fact they always have problems with it. Well duh, I wonder why. But who wants to be the party pooper right? Whatever the case, my manager is getting fairly tired of hearing me complain, which is a bit of a downer since I've only been doing it because some things needs to be addressed to make our projects top quality. So, is there some fancy judo mind trick to get my point through, or must I accept you cannot fit a square peg into a round hole, and if people don't care about the quality of their work then you can't force them to?
Jeremy Falcon
Bad code will have bad side-effects because you will underestimate how bad it really is and that little bit of re-factoring will cause you to dig yourself a huge hole because "production" will blow up some time in the future for no apparent reason... There will be a few times in your career when you will get to work on a new, shiny product; most of the time, you will be fixing what the "team" built before going off on a new adventure. ... Unless you happen to be the owner of the company (which should be your goal IMO).
-
I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects. Now, I'll be the first to say in my day I've written crap, so who am I to judge right? But, over the decades of development I've done, I'd like to at least think I've learned what crap is and what's it's not. And as such, I find myself in a position at a job I've been at since mid February, where I tend to complain a lot - because the quality of code is so poor it's just sad. But, I complain because I want to see it improve. Seeing that nobody wants to be told their code sucks (even if it's true), I've been labeled a bit of a complainer unfortunately. And while I get that, the fact remains, the code is actually not that great. Which is pretty evident by virtue of the fact they always have problems with it. Well duh, I wonder why. But who wants to be the party pooper right? Whatever the case, my manager is getting fairly tired of hearing me complain, which is a bit of a downer since I've only been doing it because some things needs to be addressed to make our projects top quality. So, is there some fancy judo mind trick to get my point through, or must I accept you cannot fit a square peg into a round hole, and if people don't care about the quality of their work then you can't force them to?
Jeremy Falcon
I'm kind of in a similar situation. It doesn't have to do with code, but my company can't keep developers very long because they treat them like crap; mules to get stuff done but are given almost 0 respect from the people asking for their help. I started bringing up the problems, being really vocal about them. Management started to listen and I thought it was sincere, until they had a company meeting where they basically said "stop complaining and get back to work". I ignored them and kept at it until I was threatened with disciplinary action because my negative attitude was affecting the company. So, here's what I've done to survive while I look for another job. 1. Pick the most important battles. I think I drowned them with so many problems they didn't know what to do with them. So I decided to ignore some things and tried to focus on a few of the most important things. 2. Talk in detailed specifics. When I told them about widespread general problems, they heard "Everything here sucks"; which was true, but apparently offensive. So I've started talking about specific people or specific conflicts and suggesting a change to this one, specific event that might have a broader effect for the future. 3. Be careful how it's directed. The management team here is thin skinned. They took the accusations personally and heard it as "You're bad at your jobs". They're in top management at a mildly successful firm... so they've done something right. So I'm really careful that what I say to them can't be interpreted as a personal attack, but is more a suggestion on a way to improve this 1 thing about this 1 small event. 4. Support the hell out of what I control. Since management won't support a company change, I made changes where I could. Treats, lunches, drinks, etc are regularly brought in with a message of appreciation and understanding how much they work. I talk about the developers, the kind of crap they go through, how important they are, and how talented they are to anyone that will listen. If management won't make a change, maybe I can convince individual people to change how they work with them. I hate politics and have a hard time with people who get offended by open discussion about differing opinions, so I don't expect to be here much longer. But this has seemed to help shift the perception of me from a negative complainer to a "team player". Maybe we'll even be able to keep a developer around long enough to actually finish a project.
-
My father always told me (don't know whose quote is though): Don't fight with an idiot. Discussions will drop you to his level and he will win due to more experience.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
Much less the entire idiot world headquarters. There is absolutely nothing to be gained and there is no point riding against windmills with them.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns. -
We've all had to work with @rseholes, there's no getting away from that, but most of them can be handled very easily if you just sit down and think of how to handle the situation (and them), rather than lose your temper and quietly simmer. None of us here is stupid; we just have to use our major assets to find intelligent solutions to problems -- use your head to think, not for butting. Think of whom you need to talk to, and what you need to say -- but remember my dear ol' granny's tenet: If you can't say something nice, don't say anything. If you get angry and butt heads with @rseholes, you're as much a part of the problem as they are -- but you make it a problem that someone else will resolve, without consulting you.
I wanna be a eunuchs developer! Pass me a bread knife!
Mark, I know you mean well and I mostly agree, but they were not the peaceful compromising types. I knew there was nothing to be gained by being stubborn. That's why, while I began to look for a way out of there, I had a little fun with them. I agreed to every crazy idea, did what they wanted me to and when the boomerang came back I left it to them to blame each other. Tuned out that they actually liked me more before. Still, in the long term I expect more from a job than keeping such idiots busy with each other.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns. -
Mark, I know you mean well and I mostly agree, but they were not the peaceful compromising types. I knew there was nothing to be gained by being stubborn. That's why, while I began to look for a way out of there, I had a little fun with them. I agreed to every crazy idea, did what they wanted me to and when the boomerang came back I left it to them to blame each other. Tuned out that they actually liked me more before. Still, in the long term I expect more from a job than keeping such idiots busy with each other.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns.CDP1802 wrote:
I agreed to every crazy idea, did what they wanted me to and when the boomerang came back I left it to them to blame each other.
I have made this one or two times as well. It is priceless when they come to you, swallowing their pride and asking for help / guidance for the needed changes.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
CDP1802 wrote:
I agreed to every crazy idea, did what they wanted me to and when the boomerang came back I left it to them to blame each other.
I have made this one or two times as well. It is priceless when they come to you, swallowing their pride and asking for help / guidance for the needed changes.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
My former colleagues would have died before they did that. Their game was more like leadership by handwaving. There was as good as no documentation amd the 'task assignment' usually was a single, not always very informative sentence. They had been doing that this way for 20 years and the resulting 'application' had the architecture of an anthill. In the rare case that this somehow led to results, they were quick to claim the praise, but usually any code change led to massive side effects and then it was, of course, the developer's fault. So it was me who pestered them with questions and let them make the decisions how to proceed. When it came to blaming someone for the next cascade of side effects which had (mildly said) angered the customer, I just pointed at the guy who told me how to do it and then enjoy the show when they turned on each other. Being treatd like an idiot can be amusing, but only for a while.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns. -
My former colleagues would have died before they did that. Their game was more like leadership by handwaving. There was as good as no documentation amd the 'task assignment' usually was a single, not always very informative sentence. They had been doing that this way for 20 years and the resulting 'application' had the architecture of an anthill. In the rare case that this somehow led to results, they were quick to claim the praise, but usually any code change led to massive side effects and then it was, of course, the developer's fault. So it was me who pestered them with questions and let them make the decisions how to proceed. When it came to blaming someone for the next cascade of side effects which had (mildly said) angered the customer, I just pointed at the guy who told me how to do it and then enjoy the show when they turned on each other. Being treatd like an idiot can be amusing, but only for a while.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns.I know what you mean.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Sander Rossel wrote:
I really hate regions! :sigh: They obfuscate the code, you only get to see parts of it, but I want it all! If your code is really so properly written you shouldn't need regions.
I fundamentally disagree, Sander. First of all, regions do not hide anything -- nobody holds a gun to your head and forces you to collapse them. Instead, they only allow you the option of not having to look at it every time you scroll up or down. Working in SQL all day long, I consider anything which makes navigating between key sections code faster or simpler to be A Really Good Thing. Second, regions are a purely for organizing your code, and outside of a Microsoft demonstration there is no class too small to benefit from a little functional structure (e.g., these functions are for the customer UI, these are for the auditors, and those are for the order-fulfillment folks). If a single-page essay can be more readable by being divided into 3 regions (introduction, body, and conclusion), then what makes you think that a 6- or 7-function class couldn't? Lastly, I question whether code is really any better when you take a 12-step chunk of linear (a.k.a. "spaghetti") code and refactor it into a 3-step process with each step having 4 layers of abstraction in the form of calls to other functions. I would say that there are many occasions where spaghetti code is more readable to both the human and the compiler.
William Clardy wrote:
Lastly, I question whether code is really any better when you take a 12-step chunk of linear (a.k.a. "spaghetti") code and refactor it into a 3-step process with each step having 4 layers of abstraction in the form of calls to other functions. I would say that there are many occasions where spaghetti code is more readable to both the human and the compiler.
If it's code that works on only one layer of abstraction that's a bit longer, maybe like a stupid init routine for some hardware device in an embedded project, okay. If that routine jumps between different levels, breaking it down into small functions will make it more understandable, because that untangles complexity which would otherwise have to go into your head all at once / you'll have to orient yourself in that complexity first. Whereas breaking it down into smaller chunks, you're basically outlining a graph of how things work.
-
Jeremy Falcon wrote:
But he (the main person responsible) has insulted me to my face more than once.
Sounds to me like your manager has told him that you were complaining about his code and this is his way of saying "Fork you". It's not enough to complain that something is wrong. You have to be prepared to show them why something is wrong - but, before you do that, why not take them to one side and say something like: "Hey, I'm just looking at this piece of code here and I was wondering why you implemented it this way. I know I must be missing something because I'm sure you will have considered doing x first, and I don't want to change something elsewhere that's going to break this, so I was hoping you could walk me through this and any touch-points that could impact it."
This space for rent
Pete O'Hanlon wrote:
Sounds to me like your manager has told him that you were complaining about his code and this is his way of saying "Fork you".
That may be the case, but I do know that this guy in particular doesn't really get along with any dev. So, I think I was just the next in line to deal with him. Yay!
Jeremy Falcon
-
Totally agree with this - you will need to get others on board if you want to solve this problem. That means winning them over to your side, rather than creating the impression that it is you vs them. In addition to adopting a more encouraging tone, I would suggest that you tackle the issue not from the point of view of "what is wrong" but "how can we improve". Telling someone that the work they performed is crap will always feel personal, whether it is true or not. Creating the feeling that we are working together for a common good will be much more productive and also resolves the you vs them feeling: make it us vs the problems instead. At the end of the day, the easiest way to sell things to organisations, is by selling the benefit. If someone has had a frustrating time fighting through poorly documented spaghetti code, they really shouldn't need much convincing that there has to be a better way. The same goes for management; they might not know what refactoring is or what the benefits are. They might think that spending time on code that already exists is a waste of resources. It is your task to open their eyes to the efficiency and cost savings that proper engineering brings with it. If you can convince people of the benefits of changing their work habits and make it in their own interest to do so, you will probably have much more success. After all, nobody likes doing work that is a PITA or unnecessary.
I agree with this 100%. I suppose being constructive is a skill set I've yet to master. Thanks for the post though.
Jeremy Falcon
-
In my (limited) experience you have to show rather than tell - make your code as excellent and readable as it can be and then, as people interact with it they will feel pulled toward making their code likewise. Also have an ethic of adding comments and fixing method names to aid readability whenever you address a defect.
Duncan Edwards Jones wrote:
In my (limited) experience you have to show rather than tell
:thumbsup:
Jeremy Falcon
-
Some sage advice in the responses, I'll have to keep them in mind as I often respond with "this is crap". However my current problem is not that the code is lousy it is that the data source is Excel. Who in their right mind builds a mission critical database system based on a spreadhseet as a data source. The boss has got sick of me telling him that we are building a support nightmare.
Never underestimate the power of human stupidity RAH
Mycroft Holmes wrote:
Some sage advice in the responses, I'll have to keep them in mind as I often respond with "this is crap".
I'm glad I'm not alone here. :-D
Jeremy Falcon
-
I used to complain. I complained about bad working environments, because who wouldn't want to fix that?! Don't you want your devs to be ultra-productive? I'm still amazed people pay the dev salaries they pay, and then shove the devs into an open plan office next to Customer Support, give them old machines and small screens. I used to complain that my co-workers, who I felt knew less than me in a particular area, weren't taking my very excellent advice. I complained about having to learn one platform when my skills lay elsewhere, and my skills going to waste. I complained about a lot of things. I meant well but I became toxic. I had a great manager who sat me down and said: "You are not responsible for the ultimate success of the project. If your advice is not accepted, you can't force it. Just do your best." If they don't want to hear, stop complaining, because it comes across as negative, and causes negativity. Try to coach your advice in nice terms, but if it isn't accepted, then gracefully back off, and just do your best with your own code. In a start-up environment, I learnt another great lesson - take ownership. So if it bothers you, and you can, take ownership and fix it. If you can't fix it, don't complain about it. Don't become a toxic co-worker who creates a negative work environment. We mean well, but that's not good enough. If you read enough work studies, you'll know that companies prefer an amiable, ambling, mediocre team over a super-productive but toxic genius any day. The saying comes to mind: Be the change you want to see. So be positive, practical, and constructive, no complaining, no blame-storming. The headache goes away when you stop head-butting the wall :laugh: All the best on your next project. Turn your reputation around :cool:
Ri_ wrote:
I'm still amazed people pay the dev salaries they pay, and then shove the devs into an open plan office next to Customer Support, give them old machines and small screens.
Oh, I know what you mean. Some companies really don't think or get it, or really even have an understanding of what we do.
Ri_ wrote:
I had a great manager who sat me down and said: "You are not responsible for the ultimate success of the project. If your advice is not accepted, you can't force it. Just do your best." If they don't want to hear, stop complaining, because it comes across as negative, and causes negativity. Try to coach your advice in nice terms, but if it isn't accepted, then gracefully back off, and just do your best with your own code.
I'll have to keep this in mind. Great point, just hard to remember sometimes.
Ri_ wrote:
The saying comes to mind: Be the change you want to see. So be positive, practical, and constructive, no complaining, no blame-storming.
I agree. Even if I forget this one too at times. :sigh:
Ri_ wrote:
All the best on your next project. Turn your reputation around
Thanks man!
Jeremy Falcon
-
If you complain, you must be willing and able to change it for the better, but once you do, you own the code and any problems or side-effects that might occur.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013I agree, just sometimes it's fun to complain for the hell of it... :-\
Jeremy Falcon
-
Jeremy, First, stop complaining, and start fixing the problem. As an outside consultant for another firm, I saw similar things. I pulled the head guy over and suggested we start with "retrospectives" and move into weekly code reviews. It took some selling, but we are 6 months into this, and the team is actually grateful! You cannot fix the code. But I found that NOT making it about the BAD code, and making it about Standards and Reviews (without reviews, there are no standards). Also, here are some selling points. Code Reviews help new programmers get up to speed. Code Reviews help increase code Readability. Code Reviews find more bugs than testing. Code Reviews helps to spread best practices. Code Reviews stops worse practices. And finally, code that has been reviewed is GENERALLY more legible and more reliable! Don't complain. Step up. My rule of thumb is "Change your organization!" if you cannot, then "Change your organization" (move on). Start small. Find one ally in the company. Get some approval. determine the coding standards. (Email me if you want some specifics). Take some code. CLEAN IT UP. And present to the boss, and then the team, the before and after. Ask them which is better code. Most people want to do a great job (most think they are above average, LOL). While you are at it. Create a Wiki to store the details of the Coding Standards, and have a place for tools and configurations. We now align our operators with a tool for cleaner looking code. And the code is not only a pleasure to read. It is more stable. We measure this by lines of code to fix a problem. Higher quality code requires smaller changes. More stable code requires smaller changes. Start small. Build up your team of allies. The ultimate goal is that no code gets put into production that has not been reviewed. Honestly, just knowing someone Senior and someone Junior will be looking at your code will tend to cause you to write better, cleaner code. And that's the goal. Kirk Out!
Thanks for your post man. I don't think code reviews will help much, maybe somewhat, since I'm a one-man shop for the most part. But I do like the idea of it and hopefully can integrate them soon enough anyway.
Jeremy Falcon
-
First, you have to be able to remove yourself from the equation. By that I mean, to recognize objectively bad code versus "this isn't the way I would approach the problem." does the code fulfill the existing business requirements? Too many developers are unwilling to subjugate their own egos, get in the ex-development staff's head, and understand the system as it lies, and why decisions may have been made to implement things this way or that way. To move forward doesn't necessarily mean an entire refactoring. It sounds as if you're past that point, and this is objectively bad code. In that case, sometimes you just have to do it. I try to fit in at least one refactoring per release. Sometimes it's a small thing, sometimes it's a rewrite of an entire subsystem. Maybe I'm fortunate that I work with a product owner who understands the value of maintainable, scalable code for the long term. Every once in a while, I tell him, "no, I'm going to take a few days and re-do this part for performance/maintainability/whatever". Mostly, that's as part of another change, kind of "while I'm up", but sometimes, it's just to do a refactoring. All that being said, it is (I presume) a business and not an academic environment. You also need to be able to justify the refactoring (in some way) as good for the business, and not just "this is the new whiz-bang toy that all the cool kids are using." So balance out what's practical to do short-term, with a longer-term goal of moving towards a more sustainable environment, and keep moving in that direction.
agolddog wrote:
It sounds as if you're past that point, and this is objectively bad code.
You're so right on your points, and I've also been guilty of saying stuff is crap for no reason, in the past. As I mature I think I'm better at this though, and in this instance let's just say this code base leaves a LOT of room for improvement.
Jeremy Falcon
-
In some cases I find that management don't want to hear that such and such code is crappy, because they probably went to a lot of effort to find the person(s) who wrote that code, and paid them a lot of money. To later hear that the code that was delivered was "sh*tty" probably sounds like you are pointing the finger at them. You need to find a way to turn around their viewpoint - that the code isn't necessarily bad, but there has been improvements in technology, and refactoring this code could lead to improvements in A, B and/or C (as appropriate). Once you have a few successes with such efforts (keeping things as positive as possible), you will find it easier going forward to get approval for cleanups like this. Not an easy task, and sometimes you just gotta vent too.... :)
Andreas Mertens wrote:
Not an easy task, and sometimes you just gotta vent too..
Amen to that brother!
Jeremy Falcon
-
"...must I accept... if people don't care about the quality of their work then you can't force them to?" yes, you must.
Sad but true.
Jeremy Falcon
-
I'm kind of in a similar situation. It doesn't have to do with code, but my company can't keep developers very long because they treat them like crap; mules to get stuff done but are given almost 0 respect from the people asking for their help. I started bringing up the problems, being really vocal about them. Management started to listen and I thought it was sincere, until they had a company meeting where they basically said "stop complaining and get back to work". I ignored them and kept at it until I was threatened with disciplinary action because my negative attitude was affecting the company. So, here's what I've done to survive while I look for another job. 1. Pick the most important battles. I think I drowned them with so many problems they didn't know what to do with them. So I decided to ignore some things and tried to focus on a few of the most important things. 2. Talk in detailed specifics. When I told them about widespread general problems, they heard "Everything here sucks"; which was true, but apparently offensive. So I've started talking about specific people or specific conflicts and suggesting a change to this one, specific event that might have a broader effect for the future. 3. Be careful how it's directed. The management team here is thin skinned. They took the accusations personally and heard it as "You're bad at your jobs". They're in top management at a mildly successful firm... so they've done something right. So I'm really careful that what I say to them can't be interpreted as a personal attack, but is more a suggestion on a way to improve this 1 thing about this 1 small event. 4. Support the hell out of what I control. Since management won't support a company change, I made changes where I could. Treats, lunches, drinks, etc are regularly brought in with a message of appreciation and understanding how much they work. I talk about the developers, the kind of crap they go through, how important they are, and how talented they are to anyone that will listen. If management won't make a change, maybe I can convince individual people to change how they work with them. I hate politics and have a hard time with people who get offended by open discussion about differing opinions, so I don't expect to be here much longer. But this has seemed to help shift the perception of me from a negative complainer to a "team player". Maybe we'll even be able to keep a developer around long enough to actually finish a project.
I think you've hit the nail on the head. I know a lot of devs don't really stand up for themselves, so I guess people can get used to pushing them around. Which is pretty sad if you ask me considering... you know... someone has to do the actual work.
Jeremy Falcon