Office politics and sh*tty code.
-
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
"sucking" is not an objective property. You might want to restate your complaints more factually, by listing the use cases that the existing code fails to address, and offer a solution that does. Also, offering estimates to fix the code compared to the mid-term cost of doing nothing might get you more attention than just 'complaining'. Cost is always the relevant factor. Code looking nice isn't.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
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
Jeremy, instead of telling them about the 'bad code', try suggesting them an approach and a solution to get it improved, and the positive impact it might or will have on the issues they're having. try to come up with a top 10 of bad pieces or patterns, estimate the cost of fixing it, convince them of the positive impact it will have in some areas. If some knowledge is missing for some co-workers, try to identify it, and get them trained/skilled in some way. But anyway, try to split up the 'bad code' in manageable chunks of work. Perhaps even code analyzing tools like SonarQube/SonarLint, Resharper, FXCop,... might assist you in making your point with your mgmt, because sometimes data and pictures say more than a thousand words, right? Also try to find out WHY there is so much bad code, just to be able to avoid it in the future. Like said before, is it a lack of knowledge, get some training. But it can also be that they count too little time to get a feature implemented, resulting in messy code. Is it because they never had a 'big plan', a vision for their application, which resulted in always adding some piece of code without having a 'grand design', which again results in messy code and structure.
-
Jeremy, instead of telling them about the 'bad code', try suggesting them an approach and a solution to get it improved, and the positive impact it might or will have on the issues they're having. try to come up with a top 10 of bad pieces or patterns, estimate the cost of fixing it, convince them of the positive impact it will have in some areas. If some knowledge is missing for some co-workers, try to identify it, and get them trained/skilled in some way. But anyway, try to split up the 'bad code' in manageable chunks of work. Perhaps even code analyzing tools like SonarQube/SonarLint, Resharper, FXCop,... might assist you in making your point with your mgmt, because sometimes data and pictures say more than a thousand words, right? Also try to find out WHY there is so much bad code, just to be able to avoid it in the future. Like said before, is it a lack of knowledge, get some training. But it can also be that they count too little time to get a feature implemented, resulting in messy code. Is it because they never had a 'big plan', a vision for their application, which resulted in always adding some piece of code without having a 'grand design', which again results in messy code and structure.
ok, and if the company is aware of this situation, and they really truly don't care about it, they probably will have their reasons. Like a plan of decommissioning the software, or the costs of fixing it will cost more than the return will be. All valid reasons. Because sometimes a developer wants to show how good a programmer he is without taking notice of the context. Sometimes a company just wants a quick and dirty solution because they're not going to make a lot of money out of it. Which should only take like say 5 days to develop. You shouldn't be the super-professional and say : ok, but to get it perfect, I need 20 days, and I only want to deliver a perfect job. Well, if the company is asking for a 'draft' version, give them a draft version, if that's what they only can afford. Not everyone wants to buy a Porsche, most people just want a car that brings them from A to B.
-
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
Every job, whether or not it is coding or something else like building industrial machinery (I do both), comes with this issue. The key is not to complain. Constructive criticism comes in many forms, but the way you do it will determine how you come across. Bear in mind, I often forget these tips myself
-
First don’t single out specific instances, but look for common practices that can be improved. “Each programmer does their class naming differently”
-
Rather than point out what’s wrong, provide systemic solutions. “Should we develop a common naming convention?”
-
State your solutions as a question whenever possible, “do you think this would work?”
-
Acknowledge what’s good about the problem code “This is great at consolidating the information, but if we restructure the data this way…, it would be easier to understand.”
-
Do the work to fix the problem, then share/explain what you did and why you did it.
-
-
You've got to work on how you complain. Taking the direct route ("This is cr@p!" or a paraphrase thereof) might seem the logical route, because it's the truth, but it's not the way to put the point across. You're working with people, not machines, so you have to take feelings into account, just as you'd like others to take your feelings into account. As you said, you (and you are not alone) have written shall we say "less than optimal" code, in the past, so before pointing out errors/problems, think about how you would like people to point out the errors/problems in your own code. Then think of someone you work with whom you don't particularly like, and imagine how you would react to their "negative analysis" of your errors. Take that into account when you want to tell someone that something is "less than optimal" -- e.g. phrase it "Hey, this was a good start, and I think we could build on it!", rather than "This needs to be rewritten!" If you've already developed the rep of being a moaner, you should work very hard on getting things done without making that rep worse. Treating people as you would like to be treated yourself costs nothing more than a little thought.
I wanna be a eunuchs developer! Pass me a bread knife!
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'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
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, 2013 -
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.
Write better code is a must, and the easiest test for whether there's any appetite for improvement. if there is, their changes to your better code will be less bad than the changes to the other stuff. If they plough on and throw equally bad code all over your changes (or even refactor your stuff to their idea of 'good'), they probably won't ever agree with you. Not so sure about comments - too easy to come across as a lecture, given the usual problems conveying tone in writing. If you've done something non-obvious, then sure, leave a brief note explaining the improvement. But the main thing is to try to work out what's in it for the people you're trying to convince. How does it benefit them? Unless you're in a management position, you have to show them how it makes *their* job easier, overall. And yeah, if they just don't get it, polish your CV.
-
(If that is possible!) [Edit] I do not mean that, in one way, because this world is founded upon such ideas, and that has made money for organizations (people) like you work in. Hopefully, you can point them towards responses such as this, and they will see more clearly that the tools they are using are not appropriate for the job. Yes, they may be working, but, having worked with a $20 million a year company that also used spreadsheets, I can say for certain that they are FAR from optimal!!!!! Hopefully, more members can chime in, and give you more ammunition to work with.
My CodeProject Articles :: Our forgotten astronomic heritage :: My website.
"Sorry, buddy, but this mission counts on everyone being as silent as possible, and your farts are just too much of a wildcard." - Korra to Meelo, "Kuvira's Gambit"After 12 years contracting to the one bank, I will put up with it till the end of the year then I'm out of here. I can almost taste leaving and it is still 6 months away.
Never underestimate the power of human stupidity RAH
-
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
Unless your group sells public API's for a living, your manager doesn't care.
-
Kevin Marois wrote:
I always use regions
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. If you have regions in a single function then refactor that function so the regions now become functions. If you have regions in a single class then refactor that class so the regions now become classes. The only thing I usually put in a region is the Dispose function. Mostly because that's in the default Visual Studio snippet. And ordering alphabetically is just tedious and unnecessary, Visual Studio lists everything in an ordered list already. And huge big ass unwieldy functions and classes can still be ordered :rolleyes: I'm not complaining, I'm trying to make your code better ;p Also a nice examples how one programmers clean code is another programmers nightmare :)
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
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.
-
Kevin Marois wrote:
I schedule it for a refactor.
Let me put it to you like this, the people running this show have probably never refactored anything in their life. And I seriously doubt they know what that is without googling it.
Jeremy Falcon
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.
-
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
My advice? Show instead of tell. People are in a hurry, and will copy-paste what's available. When that code happens to be crappy, that's what gets spread around. And then it gets spread around even more. It's like pollen. Is there a place in the code that has a high amount of "foot traffic"? A place where, if you put good code in, that it has a higher chance of getting copied around? If so, try putting some there. Set the example. Make it obvious what the code's doing so that it has a higher chance of being spread.
-
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
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!
-
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
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'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
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.
-
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:
So true. Once you're labeled as a complainer, anything you say will be disregarded. On the office politics end, one place I worked the IT department did chargebacks to the other departments. The programmers didn't realize it, but the sh*tty code was a goldmine for the department manager. One package messed up several times a day (cha ching!) and the programmers wanted to fix it once and for all. The manager bought an expensive code library system (for 4 programmers who sat in the same room) expressly to prevent them from fixing anything.
-
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
Everyone's code sucks but mine. It's the battle cry of every developer. On that note, I have seen some stuff that was beyond repair. As for your boss, complaining won't help, and doesn't offer a solution. Initiative to train and/or repair expediently is the only thing he will be receptive to. In the business world, most of the time, tearing down a project for months of downtime is not a feesable option, regardless of the state of the code. If repairing and training are not an option, plant good code where you can, and refactor as time permits, or.... quit. That's the range of options.
-
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
Jeremy: The reason why you have found so much (@#&*#@*(!$!) code is that you are working for a (@#&*#@*(!$!) boss. Nothing you do can change this type of situation. In my last corporate job I found myself in the same position; only this time the boss actually had done much of the existing the coding. The applications were so poorly designed that I had no idea how they even ran. The major accounting application was an MDI Windows Forms application. It was designed entirely incorrectly allowing one to completely throw out 50% of the code-base if it were to be redesigned. I knew if I complained it wouldn't result in anything good in the end so I just did my job and produced professional quality applications when I had complete control over their implementation. By the time I resigned they were the only working applications that had been built in the department. In a job before that I had a boss that was so stupid that even when shown the facts about an issue he refused to believe any of them. In one case, the issue was a 3rd party e-mail validation tool I had implemented since the company was finding that many of their emails were going out to bad addresses before. The 3rd party software worked quite well as I had written a small statistics module for verification. One day, suddenly none of the emails were being sent out from the application, which was used by quite a number of users. I thoroughly tested the issue and found that it was something external to the application. I even proved it to my boss but for three days he kept yelling at me to get the application working. Turns out, the part-time network specialist came back into the office and found that the email server that was being used for the application had been down but yielded no informational messages of the status before it went down to anyone. And no one had checked it on a daily basis. It was a 3rd party server so there was nothing I could do about it even if I had known what the problem was. The lesson from all this and throughout my long career is that the majority of technical management in the Information Technology field is severely incompetent. My advice, keep your head down and get another position...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
You've got to work on how you complain. Taking the direct route ("This is cr@p!" or a paraphrase thereof) might seem the logical route, because it's the truth, but it's not the way to put the point across. You're working with people, not machines, so you have to take feelings into account, just as you'd like others to take your feelings into account. As you said, you (and you are not alone) have written shall we say "less than optimal" code, in the past, so before pointing out errors/problems, think about how you would like people to point out the errors/problems in your own code. Then think of someone you work with whom you don't particularly like, and imagine how you would react to their "negative analysis" of your errors. Take that into account when you want to tell someone that something is "less than optimal" -- e.g. phrase it "Hey, this was a good start, and I think we could build on it!", rather than "This needs to be rewritten!" If you've already developed the rep of being a moaner, you should work very hard on getting things done without making that rep worse. Treating people as you would like to be treated yourself costs nothing more than a little thought.
I wanna be a eunuchs developer! Pass me a bread knife!
Well written, Mr. Wallace! Are you hiring? :)
-
Jeremy: The reason why you have found so much (@#&*#@*(!$!) code is that you are working for a (@#&*#@*(!$!) boss. Nothing you do can change this type of situation. In my last corporate job I found myself in the same position; only this time the boss actually had done much of the existing the coding. The applications were so poorly designed that I had no idea how they even ran. The major accounting application was an MDI Windows Forms application. It was designed entirely incorrectly allowing one to completely throw out 50% of the code-base if it were to be redesigned. I knew if I complained it wouldn't result in anything good in the end so I just did my job and produced professional quality applications when I had complete control over their implementation. By the time I resigned they were the only working applications that had been built in the department. In a job before that I had a boss that was so stupid that even when shown the facts about an issue he refused to believe any of them. In one case, the issue was a 3rd party e-mail validation tool I had implemented since the company was finding that many of their emails were going out to bad addresses before. The 3rd party software worked quite well as I had written a small statistics module for verification. One day, suddenly none of the emails were being sent out from the application, which was used by quite a number of users. I thoroughly tested the issue and found that it was something external to the application. I even proved it to my boss but for three days he kept yelling at me to get the application working. Turns out, the part-time network specialist came back into the office and found that the email server that was being used for the application had been down but yielded no informational messages of the status before it went down to anyone. And no one had checked it on a daily basis. It was a 3rd party server so there was nothing I could do about it even if I had known what the problem was. The lesson from all this and throughout my long career is that the majority of technical management in the Information Technology field is severely incompetent. My advice, keep your head down and get another position...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
If it aint broke, don't fix it. I have to work with some awful code but a) I don't have time to fix it and b) it works (sort of). Rather than wasting my life fixing legacy code I try to make my own efforts as elegant and hygenic as possible. In this way I hope to influence my colleagues to improve. I like to believe it is working... 'Don't tell them, show them' is the best approach IMHO. We're philosophical about power outages here. A.C. come, A.C. go.
