Dealing with bad-code
-
I get paid well to do my programming tasks (as an FTE)- But there is a lot of bad code in the project that I get to work on - so bad that it frustrates me and makes me almost write a resignation like - "I give up bcoz of your code"... Few in the team acknowledge that its bad code, most dont. And those who agree consider it a "way of life" - And they are not even motivated to improve - or should I say they have "accepted that way of life". (These folks are the one working in that co since more than 5 yrs.) And I tried - and got crucified more than once. Then, once, I wrote bad code intentionally - and got appreciated .. Then I did nothing and some "blah blah" - and got appreciated again ...wtf.... how do I deal with the team? (considering leaving as the last option) What I mean by that "bad" code here - its 2001ish code created in 2010 with heavy htmls rendered and javascript generated everytime on server (in a php type language) with sql queries somwhere in between and merged with some backend classes that generate javascript arrays and javascript via string concats (and for some odd reason dislike json)... and many times missing caching. Customers have complained on performance - but hey "thats the network issue" - or "its that javascript library" :(
I'm not a web-developer, but we use "gerrit" for code reviews, and it helped a lot to get the code quality better.(android, iOS and GRails) When people know that someone will really look at their code, the start to think twice if they write bad code. We also have forced our code rules with this. You can reject commits in gerrit or down vote them, force people to submit patches for their commits and have better code in the end. Of course it takes some time to do this. But i wouldn't want to code without code review anymore.
-
I get paid well to do my programming tasks (as an FTE)- But there is a lot of bad code in the project that I get to work on - so bad that it frustrates me and makes me almost write a resignation like - "I give up bcoz of your code"... Few in the team acknowledge that its bad code, most dont. And those who agree consider it a "way of life" - And they are not even motivated to improve - or should I say they have "accepted that way of life". (These folks are the one working in that co since more than 5 yrs.) And I tried - and got crucified more than once. Then, once, I wrote bad code intentionally - and got appreciated .. Then I did nothing and some "blah blah" - and got appreciated again ...wtf.... how do I deal with the team? (considering leaving as the last option) What I mean by that "bad" code here - its 2001ish code created in 2010 with heavy htmls rendered and javascript generated everytime on server (in a php type language) with sql queries somwhere in between and merged with some backend classes that generate javascript arrays and javascript via string concats (and for some odd reason dislike json)... and many times missing caching. Customers have complained on performance - but hey "thats the network issue" - or "its that javascript library" :(
Well, you may be a bit of a whiner, IMHO ... ;P There are 2 rules to remember here: 1. Don't !! 2. Wait !!! Thing is: In 2001 this is how we wrote that kind of code that you're complaining about. So there may be a large / huge amount of legacy-code that (fair enough) would have been so much nicer with the newer ways of doing it. But the code may actually work, as it is. Thus rule 1 above: 1. Don't == If It Ain't Broke Don't Fix It If the code does not work, then you must fix the problems, and in doing that you can do whatever is best But whait might be that you want to demonstrate better practies. No harm in that - just remember rule 2: 2. Wait == Do not do it yet, but wait to the proper time... Rule no. 2 is for experts only! The proper time could be a stand-alone project, or an isolated routine / module.
-
I get paid well to do my programming tasks (as an FTE)- But there is a lot of bad code in the project that I get to work on - so bad that it frustrates me and makes me almost write a resignation like - "I give up bcoz of your code"... Few in the team acknowledge that its bad code, most dont. And those who agree consider it a "way of life" - And they are not even motivated to improve - or should I say they have "accepted that way of life". (These folks are the one working in that co since more than 5 yrs.) And I tried - and got crucified more than once. Then, once, I wrote bad code intentionally - and got appreciated .. Then I did nothing and some "blah blah" - and got appreciated again ...wtf.... how do I deal with the team? (considering leaving as the last option) What I mean by that "bad" code here - its 2001ish code created in 2010 with heavy htmls rendered and javascript generated everytime on server (in a php type language) with sql queries somwhere in between and merged with some backend classes that generate javascript arrays and javascript via string concats (and for some odd reason dislike json)... and many times missing caching. Customers have complained on performance - but hey "thats the network issue" - or "its that javascript library" :(
Bad code -- objectively bad, as in fragile, illegible, and effectively un-maintainable -- is sometimes a consequence of the task one has been asked to perform.
At the moment I'm working on some really bad code: a huge C# program written by a gaggle of mid-level and junior engineers who, from the evidence, must have hated one another too much to converse. This team was told to produce a program that I would have budgeted about four man-years for and assigned to an all-seniors team. (Yes, it was honestly that tough a job.) These poor schmucks were given far less time than they needed even to design the **BLEEP!**ing thing. So it came out bad. Mind you, it works, for persons mindful of its limitations and within the extremely narrowly defined conditions required of it, but outside those conditions it crashes and burns.
Here's the kicker: The user community for which that program was originally intended has persuaded other persons that that program:
- Is exactly what they need;
- "Should" be easily convertible to handle their circumstances and conditions.
(Have I mentioned how much I despise people who say "should" -- especially when the subject is one on which they're abysmally ignorant?)
My original intention was to "lift up the windshield wiper and slide a whole new airplane underneath." I made the mistake of mentioning that intention to someone who ought not to have heard it, and was immediately thereafter forbidden to do any such thing. So here I am, very quietly rewriting the greater part of a 250,000 line program that my management assures me "should be a snap for you, Fran."
Yet another demonstration of the managers' maxim: "Everything is easy for the man who doesn't have to do it himself."
(This message is programming you in ways you cannot detect. Be afraid.)
-
I get paid well to do my programming tasks (as an FTE)- But there is a lot of bad code in the project that I get to work on - so bad that it frustrates me and makes me almost write a resignation like - "I give up bcoz of your code"... Few in the team acknowledge that its bad code, most dont. And those who agree consider it a "way of life" - And they are not even motivated to improve - or should I say they have "accepted that way of life". (These folks are the one working in that co since more than 5 yrs.) And I tried - and got crucified more than once. Then, once, I wrote bad code intentionally - and got appreciated .. Then I did nothing and some "blah blah" - and got appreciated again ...wtf.... how do I deal with the team? (considering leaving as the last option) What I mean by that "bad" code here - its 2001ish code created in 2010 with heavy htmls rendered and javascript generated everytime on server (in a php type language) with sql queries somwhere in between and merged with some backend classes that generate javascript arrays and javascript via string concats (and for some odd reason dislike json)... and many times missing caching. Customers have complained on performance - but hey "thats the network issue" - or "its that javascript library" :(
Well, for one, don't fix what it's not broken because in that process you may and probably will create bugs and get bashed for it. Then, if this is stressing you out, then you should: 1 - Get over it, becoming too attached can get you in trouble by saying more than you should (Been there). 2 - Start a movement to standardize practices in your company. It may start on your team and later spread to the rest of the company. If this is not an option, then goto 3 3 - Leave the company for another that is known for having skilled programmers and good practices. Loosing your hair over this stuff will get you a heart attack someday. It's not worth it.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
I get paid well to do my programming tasks (as an FTE)- But there is a lot of bad code in the project that I get to work on - so bad that it frustrates me and makes me almost write a resignation like - "I give up bcoz of your code"... Few in the team acknowledge that its bad code, most dont. And those who agree consider it a "way of life" - And they are not even motivated to improve - or should I say they have "accepted that way of life". (These folks are the one working in that co since more than 5 yrs.) And I tried - and got crucified more than once. Then, once, I wrote bad code intentionally - and got appreciated .. Then I did nothing and some "blah blah" - and got appreciated again ...wtf.... how do I deal with the team? (considering leaving as the last option) What I mean by that "bad" code here - its 2001ish code created in 2010 with heavy htmls rendered and javascript generated everytime on server (in a php type language) with sql queries somwhere in between and merged with some backend classes that generate javascript arrays and javascript via string concats (and for some odd reason dislike json)... and many times missing caching. Customers have complained on performance - but hey "thats the network issue" - or "its that javascript library" :(
Been there, Done that! Lay out available options and take action. 1. Stay and keep quiet. (could be job security) 2. Stick around until something better comes along. 3. Make your own list of options. I would be willing to bet the programmers that wrote the code have been promoted into management and are running the project. In that case you are in a political situation. Hansen's Theorem 1 : If a situation is not logical, it is political
-
Bad code -- objectively bad, as in fragile, illegible, and effectively un-maintainable -- is sometimes a consequence of the task one has been asked to perform.
At the moment I'm working on some really bad code: a huge C# program written by a gaggle of mid-level and junior engineers who, from the evidence, must have hated one another too much to converse. This team was told to produce a program that I would have budgeted about four man-years for and assigned to an all-seniors team. (Yes, it was honestly that tough a job.) These poor schmucks were given far less time than they needed even to design the **BLEEP!**ing thing. So it came out bad. Mind you, it works, for persons mindful of its limitations and within the extremely narrowly defined conditions required of it, but outside those conditions it crashes and burns.
Here's the kicker: The user community for which that program was originally intended has persuaded other persons that that program:
- Is exactly what they need;
- "Should" be easily convertible to handle their circumstances and conditions.
(Have I mentioned how much I despise people who say "should" -- especially when the subject is one on which they're abysmally ignorant?)
My original intention was to "lift up the windshield wiper and slide a whole new airplane underneath." I made the mistake of mentioning that intention to someone who ought not to have heard it, and was immediately thereafter forbidden to do any such thing. So here I am, very quietly rewriting the greater part of a 250,000 line program that my management assures me "should be a snap for you, Fran."
Yet another demonstration of the managers' maxim: "Everything is easy for the man who doesn't have to do it himself."
(This message is programming you in ways you cannot detect. Be afraid.)
Fran Porretto wrote:
"Everything is easy for the man who doesn't have to do it himself."
Good for a signature. Do you mind? I have seen this happen. Some years ago i worked in a system that have to produce reports to a specific client, so, one day a sales person come to us and said that we have to add a lot of new data to the report and so she told us: "This is easy, you just have to do a select grouping everything. I DON'T KNOW HOW TO DO THIS, BUT IT'S EASY"
Sorry, my english is bad!
-
Well, for one, don't fix what it's not broken because in that process you may and probably will create bugs and get bashed for it. Then, if this is stressing you out, then you should: 1 - Get over it, becoming too attached can get you in trouble by saying more than you should (Been there). 2 - Start a movement to standardize practices in your company. It may start on your team and later spread to the rest of the company. If this is not an option, then goto 3 3 - Leave the company for another that is known for having skilled programmers and good practices. Loosing your hair over this stuff will get you a heart attack someday. It's not worth it.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
If it ain't broke, don't fix it! We are so busy, we fix as things break and do them the "new" right way! :-O
-
If it ain't broke, don't fix it! We are so busy, we fix as things break and do them the "new" right way! :-O
Onde day the entire application will be new :laugh:
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
Nemanja Trifunovic wrote:
the only good code I've ever seen is in some books.
Yeah, and unfortunately there are so many (not so cheap) books with flawed code.
Mislim, dakle jeo sam.
-
I get paid well to do my programming tasks (as an FTE)- But there is a lot of bad code in the project that I get to work on - so bad that it frustrates me and makes me almost write a resignation like - "I give up bcoz of your code"... Few in the team acknowledge that its bad code, most dont. And those who agree consider it a "way of life" - And they are not even motivated to improve - or should I say they have "accepted that way of life". (These folks are the one working in that co since more than 5 yrs.) And I tried - and got crucified more than once. Then, once, I wrote bad code intentionally - and got appreciated .. Then I did nothing and some "blah blah" - and got appreciated again ...wtf.... how do I deal with the team? (considering leaving as the last option) What I mean by that "bad" code here - its 2001ish code created in 2010 with heavy htmls rendered and javascript generated everytime on server (in a php type language) with sql queries somwhere in between and merged with some backend classes that generate javascript arrays and javascript via string concats (and for some odd reason dislike json)... and many times missing caching. Customers have complained on performance - but hey "thats the network issue" - or "its that javascript library" :(
I went from being a software engineer to managing software engineers, starting my own software company, selling that business and back to a software engineer. What i can tell you is that your issue (as described above) isn't a programming issue but a company culture issue. I would recommend doing code/unit test reviews with the goal of writing better code... not bashing people personally, not to get people fired but to simply write better code and learn from each others experiences. Done correctly, this should shift your company culture slightly making it a more fulfilling work environment. The other thing i tell people: "It is your choice to work there. If you aren't passionate with your current position start looking around for a new job." There are some exceptions to this and family situations have to be taken into account but most people stay in a job they hate because it is easy and that is stupid.
Eric
-
Been there, Done that! Lay out available options and take action. 1. Stay and keep quiet. (could be job security) 2. Stick around until something better comes along. 3. Make your own list of options. I would be willing to bet the programmers that wrote the code have been promoted into management and are running the project. In that case you are in a political situation. Hansen's Theorem 1 : If a situation is not logical, it is political
Member 8697068 wrote:
Hansen's Theorem 1 : If a situation is not logical, it is political
Can you cite this? I really like it. Eric
Eric
-
I get paid well to do my programming tasks (as an FTE)- But there is a lot of bad code in the project that I get to work on - so bad that it frustrates me and makes me almost write a resignation like - "I give up bcoz of your code"... Few in the team acknowledge that its bad code, most dont. And those who agree consider it a "way of life" - And they are not even motivated to improve - or should I say they have "accepted that way of life". (These folks are the one working in that co since more than 5 yrs.) And I tried - and got crucified more than once. Then, once, I wrote bad code intentionally - and got appreciated .. Then I did nothing and some "blah blah" - and got appreciated again ...wtf.... how do I deal with the team? (considering leaving as the last option) What I mean by that "bad" code here - its 2001ish code created in 2010 with heavy htmls rendered and javascript generated everytime on server (in a php type language) with sql queries somwhere in between and merged with some backend classes that generate javascript arrays and javascript via string concats (and for some odd reason dislike json)... and many times missing caching. Customers have complained on performance - but hey "thats the network issue" - or "its that javascript library" :(
Here are two ways of dealing with it. I've done both of these. 1. Pick one page that renders particularly slow and recode it so that it significantly cuts the wait time. I once took a page that took almost 2 minutes to load and made it load in about 20 seconds and they implemented it. 2. Change your cause to commenting how "old" the website looks and offer to give it a new design. As you design the outward appearance, you can also update the underlying code to optimize it. They won't notice the speed difference, but they will like the visual improvements to the site. Number 3 is to just live with it and make code improvements as you have to make updates to the site. Good Luck
Brent
-
I get paid well to do my programming tasks (as an FTE)- But there is a lot of bad code in the project that I get to work on - so bad that it frustrates me and makes me almost write a resignation like - "I give up bcoz of your code"... Few in the team acknowledge that its bad code, most dont. And those who agree consider it a "way of life" - And they are not even motivated to improve - or should I say they have "accepted that way of life". (These folks are the one working in that co since more than 5 yrs.) And I tried - and got crucified more than once. Then, once, I wrote bad code intentionally - and got appreciated .. Then I did nothing and some "blah blah" - and got appreciated again ...wtf.... how do I deal with the team? (considering leaving as the last option) What I mean by that "bad" code here - its 2001ish code created in 2010 with heavy htmls rendered and javascript generated everytime on server (in a php type language) with sql queries somwhere in between and merged with some backend classes that generate javascript arrays and javascript via string concats (and for some odd reason dislike json)... and many times missing caching. Customers have complained on performance - but hey "thats the network issue" - or "its that javascript library" :(
-
I get paid well to do my programming tasks (as an FTE)- But there is a lot of bad code in the project that I get to work on - so bad that it frustrates me and makes me almost write a resignation like - "I give up bcoz of your code"... Few in the team acknowledge that its bad code, most dont. And those who agree consider it a "way of life" - And they are not even motivated to improve - or should I say they have "accepted that way of life". (These folks are the one working in that co since more than 5 yrs.) And I tried - and got crucified more than once. Then, once, I wrote bad code intentionally - and got appreciated .. Then I did nothing and some "blah blah" - and got appreciated again ...wtf.... how do I deal with the team? (considering leaving as the last option) What I mean by that "bad" code here - its 2001ish code created in 2010 with heavy htmls rendered and javascript generated everytime on server (in a php type language) with sql queries somwhere in between and merged with some backend classes that generate javascript arrays and javascript via string concats (and for some odd reason dislike json)... and many times missing caching. Customers have complained on performance - but hey "thats the network issue" - or "its that javascript library" :(
I am in a similar situation, worse in some ways. The code I inherited is written in Classic ASP from the early 90's. It has been maintained and expanded over the years but a number of developers so there is not a lot of consistency. SQL is built up from strings in the pages themselves and there is little or no javascript interaction, it just changes some session variables and reloads the page so the ASP code can rewrite the HTML instead. I tried a total rewrite from scratch first (with the blessing of my boss) but quickly discovered that there is no staff available to test that much all at once. I have since changed my strategy. I introduced jquery and started creating some layout templates that I could use to mimic the look of existing pages. Now I am in the process of converting one small block of functionality at a time in ASP.NET and any new requirements get implemented in the new code as well. Luckily, I am currently the only developer on staff. They will bring in a contract resource or two if I need help with a larger effort (like the mobile app we are getting ready to release and the web services behind it). Because you are trying to work contrary to your whole team, I think yours may be a lost cause. It sounds like the others have figured out that they can just settle in and enjoy the ride while doing as little as possible -- you even getting rewarded for it. So your choices would seem to be going with the flow or moving on to something else.
-
Fran Porretto wrote:
"Everything is easy for the man who doesn't have to do it himself."
Good for a signature. Do you mind? I have seen this happen. Some years ago i worked in a system that have to produce reports to a specific client, so, one day a sales person come to us and said that we have to add a lot of new data to the report and so she told us: "This is easy, you just have to do a select grouping everything. I DON'T KNOW HOW TO DO THIS, BUT IT'S EASY"
Sorry, my english is bad!
That irate me. One time when someone said this to me, I got up from my chair and told: its easy, ok, put your butt here and do it, there are all the tools needed on the screen.
-
I get paid well to do my programming tasks (as an FTE)- But there is a lot of bad code in the project that I get to work on - so bad that it frustrates me and makes me almost write a resignation like - "I give up bcoz of your code"... Few in the team acknowledge that its bad code, most dont. And those who agree consider it a "way of life" - And they are not even motivated to improve - or should I say they have "accepted that way of life". (These folks are the one working in that co since more than 5 yrs.) And I tried - and got crucified more than once. Then, once, I wrote bad code intentionally - and got appreciated .. Then I did nothing and some "blah blah" - and got appreciated again ...wtf.... how do I deal with the team? (considering leaving as the last option) What I mean by that "bad" code here - its 2001ish code created in 2010 with heavy htmls rendered and javascript generated everytime on server (in a php type language) with sql queries somwhere in between and merged with some backend classes that generate javascript arrays and javascript via string concats (and for some odd reason dislike json)... and many times missing caching. Customers have complained on performance - but hey "thats the network issue" - or "its that javascript library" :(
I've been in that situation. I write clear code, but have been forced to maintain code written by idiots in past jobs. Sometimes you can encapsulate the bad code into "black boxes" that work correctly, and you never have to open them; just call the function. Fortunately, at my present position, I've been maintaining MY OWN CODE for several years. It's a relief!
-
I went from being a software engineer to managing software engineers, starting my own software company, selling that business and back to a software engineer. What i can tell you is that your issue (as described above) isn't a programming issue but a company culture issue. I would recommend doing code/unit test reviews with the goal of writing better code... not bashing people personally, not to get people fired but to simply write better code and learn from each others experiences. Done correctly, this should shift your company culture slightly making it a more fulfilling work environment. The other thing i tell people: "It is your choice to work there. If you aren't passionate with your current position start looking around for a new job." There are some exceptions to this and family situations have to be taken into account but most people stay in a job they hate because it is easy and that is stupid.
Eric
My experience is that this is the best advice you are going to find. Everyplace will have code you would rather not deal with. But you have a choice with your current situation. You can either give up and give in, or move on. You will probably not be able to change the culture of the group (at least for a long time). Before you will be able to change it, you will have to be accepted. Then you can introduce very small steps over a period of time. Don't try to change things too fast. Also, in my experience needlessly complicated code is a sign that the developer writing it is overwhelmed by the problem at hand.
-
I get paid well to do my programming tasks (as an FTE)- But there is a lot of bad code in the project that I get to work on - so bad that it frustrates me and makes me almost write a resignation like - "I give up bcoz of your code"... Few in the team acknowledge that its bad code, most dont. And those who agree consider it a "way of life" - And they are not even motivated to improve - or should I say they have "accepted that way of life". (These folks are the one working in that co since more than 5 yrs.) And I tried - and got crucified more than once. Then, once, I wrote bad code intentionally - and got appreciated .. Then I did nothing and some "blah blah" - and got appreciated again ...wtf.... how do I deal with the team? (considering leaving as the last option) What I mean by that "bad" code here - its 2001ish code created in 2010 with heavy htmls rendered and javascript generated everytime on server (in a php type language) with sql queries somwhere in between and merged with some backend classes that generate javascript arrays and javascript via string concats (and for some odd reason dislike json)... and many times missing caching. Customers have complained on performance - but hey "thats the network issue" - or "its that javascript library" :(
Well, I suppose they don't pay you enough to withstand bad code... ;P The golden rule is if it's not broken then don't fix it, because you may introduce new bugs while improving the application and of course you will be the only responsible for such mistakes. If you really can't withstand working with such codebase I recommend you to move on, but be warned that wherever you go, unless you go to a startup, you will likely find bad code.
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
I get paid well to do my programming tasks (as an FTE)- But there is a lot of bad code in the project that I get to work on - so bad that it frustrates me and makes me almost write a resignation like - "I give up bcoz of your code"... Few in the team acknowledge that its bad code, most dont. And those who agree consider it a "way of life" - And they are not even motivated to improve - or should I say they have "accepted that way of life". (These folks are the one working in that co since more than 5 yrs.) And I tried - and got crucified more than once. Then, once, I wrote bad code intentionally - and got appreciated .. Then I did nothing and some "blah blah" - and got appreciated again ...wtf.... how do I deal with the team? (considering leaving as the last option) What I mean by that "bad" code here - its 2001ish code created in 2010 with heavy htmls rendered and javascript generated everytime on server (in a php type language) with sql queries somwhere in between and merged with some backend classes that generate javascript arrays and javascript via string concats (and for some odd reason dislike json)... and many times missing caching. Customers have complained on performance - but hey "thats the network issue" - or "its that javascript library" :(
Your team doesn't appreciate good code. They just don't care. They learned to write code 10 years ago and they haven't kept up. Their managers don't care either. If you do care about good code, you need to get a new team. That is the only fix. Right now is a great time to be looking for work. You have a great answer for the, "Why are you looking for work?" question. Don't make waves at your old company. Let them feed you during your job search. Keep putting in your 40 hours a week until you can give notice. Thank everyone and promise to keep in touch. Every developer thinks they write good code. Every employer claims they value good code. The reality is not as rosy. During your interview, see what the prospective employer *does* to produce good code. Do they track bugs? Do they do reviews? When was the last time they devoted a couple of sprints to refactoring? Having said you want to write good code, you will, of course, have to put your money where your mouth is at that new job. It's hard to write good code under deadline pressure. Your colleagues will be less forgiving of your mistakes. And most of the time, writing bad code pays about the same as writing good code. So be careful what you wish for.
-
Member 8697068 wrote:
Hansen's Theorem 1 : If a situation is not logical, it is political
Can you cite this? I really like it. Eric
Eric
I am new to this blog. What do you mean by cite it.