|
Jeremy Falcon wrote: I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects
Like this[^] 
|
|
|
|
|
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 
All the best on your next project. Turn your reputation around 
|
|
|
|
|
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.
|
|
|
|
|
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. 
Ri_ wrote: All the best on your next project. Turn your reputation around
Thanks man!
Jeremy Falcon
|
|
|
|
|
In my past position I managed a team. My rule of thumb was to give the job of fixing stuff to the person that most loudly complained that it was broken. It's a win-win.
|
|
|
|
|
There are some fancy judo mind tricks, but they only work on clever people.
In your situation, it is impossible to get your points through. Forget about them. Leave.
Actually, if you want, before you leave, you might prepare a detailed document, explaining the shortcomings and the ways that they can be fixed. And hand the document to them, in an email. This way, they will think twice before saying anything negative about you in the future.
You see, the written word has power and ability to persist over the years. Later on, you might need proof that you did make your points and arguments.
Please read the following, to understand the importance of documenting your views for the future:
Your Software is Never Perfect
|
|
|
|
|
I read your post with interest. While our situations are not the same (I'm not a software writer by trade) they are similar.
I work for a small, family run, engineering company, and I have never seen such a disorganised, run down place in all my life. It belongs in the Victorian era! I have complained about the state of the equipment (donkey's years old), the building (leaking roof, filthy, dark and dingey), the working practices (it's a health & safety hazard) and the business processes (or, rather lack of them). There's no emphasis on actually making a profit yet the owners are tighter than Ebenezer Scrooge when it comes to spending any money - on anything.
I have got that fed up complaining that I've come to the conclusion that the only way to deal with it is to just 'go with the flow'. If they want to run a sh*thole of a company, then who am I to make waves? Afterall, it's not MY company. What does elephant me off is if the place goes bust due to bad management, then I'm out of a job due to someone else's incompetence.
In conclusion, my advice to you is to go with the flow too - you can't control what you don't own. As galling as it is, it's not worth getting annoyed, or making yourself unpopular because of other people's inability to do their job correctly. Life's too short, take a chill pill and bite your tongue.
|
|
|
|
|
I stopped complaining and caring. The codebase sucks, both changing it and working around require time. I present my points in the most objective way, stating very clearly that some things are impeded by the existing situation. If the company doesn't care about my efficiency, why should I? Also this way I can slow down when I feel like to and I have something to rightfully blame. It's a nice buffer for the downer periods.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
den2k88 wrote: present my points in the most objective way, stating very clearly that some things are impeded by the existing situation.
We call that "things have grown historically" here. It is very frustrating to find out, you can't do anything about it because (even being cr@p suboptimal) it still works. Changing it is nearly impossible without starting over again due to so many years of additions / bypasses / workarounds.
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.
|
|
|
|
|
"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)
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
I agree, just sometimes it's fun to complain for the hell of it... 
Jeremy Falcon
|
|
|
|
|
Unless your group sells public API's for a living, your manager doesn't care.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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!
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
