|
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.
|
|
|
|
|
Bad code comes from (lack of) expectations. Most devs are capable of writing good code. But they are human beings, and humans are lazy when there's no penalty for being lazy.
It's pretty hard, as a peer, to get people to write good code. You can't just say, "Why do you write such sh*tty code?" because people will (rightfully) think you're an a**hole if you trash-talk their work. You may get slightly more traction with a helpful comment like, "Do you know about RAII? If you use RAII here, you won't have to explicitly delete all those pointers."
(Huh, codeproject auto-censors my cuss-words. I thought the authors were doing it...)
You could try to get your peers to take up a static checker tool or de-linter. Sometimes even a reformatter helps, to get the whole code base into a common-looking form.
You may have more leverage by encouraging your manager to promote the use of these tools. As I said, humans are lazy when there's no penalty. If your manager wants you to write better code, that's a pretty big penalty for laziness. The Holy Grail would be to convince your manager to adopt a code review methodology.
When you ask your manager for help improving the code base is generally when you learn if there is any hope. If your manager views any attempt to review or refactor the code base as time wasted, then you're never going to get any traction. It is my sad experience that most managers are this way, making the usual fallacious arguments about efficiency and how the company can't afford to slow down. When you hear this, all you can do is polish your resume. You'll want to get moving.
|
|
|
|
|
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
|
|
|
|
|
This is what's worked for me in a similar situation: lead by example.
Rather than say "this is cr@p, we need to change it all", instead work on what's assigned and make changes around the code you touch in order to improve it. Don't talk to anyone about refactoring, just do it in the course of doing the work at hand. That is what refactoring is all about anyway. It's not a separate task. Eventually, hopefully they can see the changes and recognize for themselves the improvement. Then they'll have a template to follow.
Improving an existing code base is a marathon, not a sprint.
|
|
|
|
|
Bad code will have bad side-effects because you will underestimate how bad it really is and that little bit of re-factoring will cause you to dig yourself a huge hole because "production" will blow up some time in the future for no apparent reason...
There will be a few times in your career when you will get to work on a new, shiny product; most of the time, you will be fixing what the "team" built before going off on a new adventure.
... Unless you happen to be the owner of the company (which should be your goal IMO).
|
|
|
|
|
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
|
|
|
|
|
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 sh*t, leave. Others will be glad to have you on board.
|
|
|
|
|
Thanks for your insights.
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;
|
|
|
|
|
Well said. 
Jeremy Falcon
|
|
|
|
|
Thanks, Jeremy - it's the benefit of learning how not to be an asshat of a coworker  .
Software Zen: delete this;
|
|
|
|
|
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), should be applied where appropriate (e.g. usually best followed, but there may be good reasons for deviating from standard) and advisory (e.g. there are various different ways of implementing IDispose depending upon the circumstances).
Finally consider ways to present your arguments in objective terms, because the 'right' way to code is incredibly subjective. Here is a list of ways to highlight the problems in the code base:
1. Static code analysis.
2. High incidence of faults in a given area; make sure your replacement doesn't generate as many faults as before!
3. Performance problems in a given area.
4. Obsolete technology.
5. Complicated interactions with other systems and between sub-systems.
6. Complicated build and installation process. If your code doesn't build out the box, requires 'installing' before you can compile it etc Streamlining build->release->test should see a measurable benefit in the faults database and project lead times.
Hope this helps.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
