Office politics and sh*tty code.
-
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
-
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
Jeremy, I did not realize you were in that position. Given that, my suggestions are: 1) Implement Coding Standards 2) Add 50 - 100% to all estimates. Because every file touched will need to be brought up to new coding standards. You might have to do this slowly. 3) Use a tracking system to determine where bugs/fixes are required the most. The 80/20 rule says that 80% of the fixes are needed in 20% of the code. That 20% gets the best next look. 4) Have the philosophy that you will leave this code base in a better condition than you found it. Honestly, you are in charge of your environment. You can spend the time required to make it better. Also, make notes along the way. Screenshot some of the worse code, before and after. Maybe consider writing an article about your experiences. you don't have to rewrite every line. But let me tell you that a LITTLE TLC for the Code goes a long way! Take the pride it in that makes it worth the effort to you. It may get you your next position! HTH, Kirk Out!
-
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
It's very frustrating that, while having the company's interest at heart, you feel like you have to 'fight' for doing things right. To me, this is a clear sign that it's time to move on. I always try to do things to the best of my abilities / time-constraints / etc., and while I'm not above delivering code not 100% up to my own personal standards due to good reason(s), getting your efforts squashed every time because of people's idiocies and/or politics will drive me out of any gig very, very quickly. This is all personal, but my 2¢ would be: do your best with what you're given, honestly. If you get shut down for stupid shit, leave. Others will be glad to have you on board.
-
It's very frustrating that, while having the company's interest at heart, you feel like you have to 'fight' for doing things right. To me, this is a clear sign that it's time to move on. I always try to do things to the best of my abilities / time-constraints / etc., and while I'm not above delivering code not 100% up to my own personal standards due to good reason(s), getting your efforts squashed every time because of people's idiocies and/or politics will drive me out of any gig very, very quickly. This is all personal, but my 2¢ would be: do your best with what you're given, honestly. If you get shut down for stupid shit, leave. Others will be glad to have you on board.
Thanks for your insights.
Jeremy Falcon
-
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
The only solution I've ever found for that problem is to lead by example. It sounds very New Age-y, but it seems to be true. Implement solutions to the code quality problems in your area of responsibility, let your boss know what you've done, and why. Offer to help with the worst problem areas. The difficult part of all this is doing it without looking like a grandstander and pissing off your coworkers.
Software Zen:
delete this; -
The only solution I've ever found for that problem is to lead by example. It sounds very New Age-y, but it seems to be true. Implement solutions to the code quality problems in your area of responsibility, let your boss know what you've done, and why. Offer to help with the worst problem areas. The difficult part of all this is doing it without looking like a grandstander and pissing off your coworkers.
Software Zen:
delete this;Well said. :thumbsup:
Jeremy Falcon
-
Well said. :thumbsup:
Jeremy Falcon
Thanks, Jeremy - it's the benefit of learning how not to be an asshat of a coworker :-D.
Software Zen:
delete this; -
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
Yeah, I have been in a similar boat to you in the past about other people's code. Usually, a lot of code has been turned quickly out by programmers transient to the project and I'm the guy left to pick up the pieces. This used to be really frustrating until I was reminded that it is precisely because I'm the 'better' developer that I'm the one doing all the refactoring. So, it is important for you to highlight the deficiencies in the code base but unfortunately it is there and everyone is stuck with it. You could argue for a complete re-write, but the is unlikely to happen just because you say the code is 'bad'. If it is working and/or being sold, your management won't give a fig about your problems; and, after all it is your problem so no complaining and get on with your job ;) In this situation there is one thing I say fairly early on and it goes along the lines of: 'this code isn't where I want it to be. All the while I'm working on the code I'll seek ways to improve it incrementally until it is. Or until I'm reassigned'. On that basis you'll have to accept the process could take years and make sure your management know this is a normal part of your day to day activities of fixing faults and CRS. Then I will look for opportunities for refactoring, on the justification of a fault to fix or a CR. Always ensure you've got a good testing regime in place to attempt refactoring (that doesn't necessarily mean automation) and you are able to mitigate the risks of the change. e.g. rollback, incremental changes. It is important that your management build confidence in your ability to refactor code, so pick your refactoring targets carefully to begin with so you don't mess up. (You may not know what past history your firm has had along these lines). Sometimes refactoring is simply not appropriate and a direct rewrite would serve you better. Again choose your target carefully, but in a rewrite it will allow you to develop and test in parallel and to establish a core code base to build out, from within. You could champion a set of standards and best practices within your group. Rather than take on the mammoth task of refactoring yourself, perhaps a change in team culture would help. Don't focus on variable naming conventions and the like. That's irrelevant. Focus on things like project structure, where library methods live, code templates snippets etc. Consider your standards in three tiers - must adhere to (e.g. things that break the build or can cause serious problems such as memory leaks