Office politics and sh*tty code.
-
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:
nobody holds a gun to your head and forces you to collapse them
But the default state is collapsed. I still feel the relief when I open some old class to find out it has only about 100 lines, then notice a region and find out it's more like 1000 lines X| With all the shortcuts like "Go to definition" (F12), Go back (Ctrl and -), and the alphabetical list listing all functions, who still needs regions? If your code is clean you don't need regions, if your code isn't clean it's like swiping dust under the rug. Organized shmorganized. No region I've ever seen helped "organize" the code X| Are you one of those people who also like those awful green comments (I hate them even more than regions)? :D
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
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
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.... :)
-
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 very meticulous about the code I write. I always use regions, and I use the same regions in the same order in every class. This way I know exactly where code parts are. Also, all of my class members are listed alphabetically in their regions. When I see bad code, I schedule it for a refactor. I'm actually sitting here right now refactoring some offshore code. These guys just throw code in anywhere and its annoying and flat out lazy. Unlike you, my manager is totally on board with me cleaning up the code.
If it's not broken, fix it until it is
This is key - very few will complain about you fixing things on your own. There is no need to complain - just take the initiative to make it better. Complaining is not constructive.
-
Well written, Mr. Wallace! Are you hiring? :)
Only if you'll accept ironing my shirts in your job description.
I wanna be a eunuchs developer! Pass me a bread knife!
-
I see the same problem in a lot of companies with Enterprise development. The biggest problem is not using the right tools for the job, (use the latest fad of the month and rewrite it). OOP is not suited for business applications where databases are involved. refactoring is only needed for shitty programmers, good code does not need refactoring.
pkulek wrote:
OOP is not suited for business applications where databases are involved
absolutely false. It may not be suited for every application, but it's well suited for most.
pkulek wrote:
good code does not need refactoring.
Not being "good code" isn't the only reason to refactor.
#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 am with you on the using of Regions. I do not know why more programmers/developers don't use them.
A giraffe is a horse designed by a committee....
I can see using regions to collapse groups of related functions. Regions within functions mean that region should probably be a separate function.
Ed Aymami wrote:
don't use them
Because it makes code hard to read.
#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
This is what's worked for me in a similar situation: lead by example. Rather than say "this is cr@p, we need to change it all", instead work on what's assigned and make changes around the code you touch in order to improve it. Don't talk to anyone about refactoring, just do it in the course of doing the work at hand. That is what refactoring is all about anyway. It's not a separate task. Eventually, hopefully they can see the changes and recognize for themselves the improvement. Then they'll have a template to follow. Improving an existing code base is a marathon, not a sprint.
-
I can see using regions to collapse groups of related functions. Regions within functions mean that region should probably be a separate function.
Ed Aymami wrote:
don't use them
Because it makes code hard to read.
#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 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.
-
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
