|
Totally agree with this - you will need to get others on board if you want to solve this problem. That means winning them over to your side, rather than creating the impression that it is you vs them.
In addition to adopting a more encouraging tone, I would suggest that you tackle the issue not from the point of view of "what is wrong" but "how can we improve". Telling someone that the work they performed is crap will always feel personal, whether it is true or not. Creating the feeling that we are working together for a common good will be much more productive and also resolves the you vs them feeling: make it us vs the problems instead.
At the end of the day, the easiest way to sell things to organisations, is by selling the benefit. If someone has had a frustrating time fighting through poorly documented spaghetti code, they really shouldn't need much convincing that there has to be a better way. The same goes for management; they might not know what refactoring is or what the benefits are. They might think that spending time on code that already exists is a waste of resources. It is your task to open their eyes to the efficiency and cost savings that proper engineering brings with it. If you can convince people of the benefits of changing their work habits and make it in their own interest to do so, you will probably have much more success. After all, nobody likes doing work that is a PITA or unnecessary.
|
|
|
|
|
I agree with this 100%. I suppose being constructive is a skill set I've yet to master. Thanks for the post though.
Jeremy Falcon
|
|
|
|
|
Well written, Mr. Wallace!
Are you hiring?
|
|
|
|
|
Only if you'll accept ironing my shirts in your job description.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
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.
|
|
|
|
|
I totally agree with that when it comes to marketing, and I do that with the comments-ish... I usually don't over comment but for these projects I may.
Jeremy Falcon
|
|
|
|
|
No. That will infuriate them. First he does not only call them idiots, now he proves it to them by holding something under their noses of which they don't even have an idea what the words he keeps ranting about mean.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
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.
|
|
|
|
|
Duncan Edwards Jones wrote: In my (limited) experience you have to show rather than tell
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: how everyone else here deals with poorly written code in pre-existing projects Ctrl+A - DEL
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
OI! Don't give CODZ in the Lounge!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Congratulation. They obviously gave you my job after I left a few months ago. Get out of there as fast as you can, they will not thank you, much less actually do something worth any time or money for the first time ever.
Look for a place where they actually want to have your skills and give you an opportunity to use them.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
It's not only you. I'm bbq-ed here with a bad code grill.
|
|
|
|
|
Good times!
Jeremy Falcon
|
|
|
|
|
Sanford and son.
|
|
|
|
|
Nice!
Jeremy Falcon
|
|
|
|
|
Gawd!
It's "Steptoe", OK? "Steptoe and Son".
Don't accept cheap Chinese American knock-offs, Harold.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Some sage advice in the responses, I'll have to keep them in mind as I often respond with "this is crap".
However my current problem is not that the code is lousy it is that the data source is Excel. Who in their right mind builds a mission critical database system based on a spreadhseet as a data source. The boss has got sick of me telling him that we are building a support nightmare.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
|
(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
|
|
|
|