|
(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.
modified 21-Jun-16 1:50am.
|
|
|
|
|
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
|
|
|
|
|
Mycroft Holmes wrote: Some sage advice in the responses, I'll have to keep them in mind as I often respond with "this is crap".
I'm glad I'm not alone here. 
Jeremy Falcon
|
|
|
|
|
Often the biggest problem is being viewed as objective. I find myself often in a position of defending code from people who are upset that they couldn't join in, and pointing out bad code in projects (including my own) to get people to up their game.
The thing which I've found works best if to have tooling which can provide an objective view of the code. My two favourites being ReSharper and SonarQube, the first because it provides immediate feedback and helps fix a number of issues and the latter because it provides some great metrics that can be tracked (great if you can make it part of your build process).
Building these up to show the team and your manager gives you the ammunition to show that you know what you're talking about and helps the team measure themselves against an objective measure.
Of course there may be things like coding styles which people don't agree on (yourself included) but if everyone follows the same rules then things improve and it makes sure that everyone can read the code easily.
Once these are in place you can build up some internal guides on coding practice to help new starters and as refreshers for existing people.
It can be a long journey, but if you can present it as "it's not me complaining, look here's the proof" then it's an easier pill to swallow.
Eagles may soar, but weasels don't get sucked into jet engines
|
|
|
|
|
I used to be a real PIA about code quality and pissed of most of the department ... but as I was as hard on older, "less optimal" code written by myself and that I also listened to them and theirs complaint about my code, it worked out in the long run.
Nowadays I mostly preach "Code Complete" and lends my copy to anyone even remotely curious. As most programmers really wants to improve it usually ends with them keeping the copy -- "Ahh, I have a older copy at home, you just keep that one".
For "less optimal" code it's refactoring time wherever and whenever it's discovered 
|
|
|
|
|
Jeremy Falcon wrote: I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects.
Noooooo! Of course not! It's only you! You alone have been "blessed" with cow-orkers that write stupid code! 
Seriously, my suggestion would be as follows:
Everybody with half a mind would be able to understand that it is a huge advantage if code is written in the same way by all coders. There are several VS plugins that can enforce code standards available out there. Pick a standard and use it (all of you) - or tweak it to your common liking.
My personal recommendation is IDesign's Juwal Lowy's "C# Coding Standards", which can be downloaded freely from their web site[^]
As for existing code, it can be refactored and rewritten when it's practical and when time permits it...
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
I'd just like a chance to prove that money can't make me happy.
Me, all the time
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
