|
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.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
