Dealing with bad-code
-
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.
-
I am new to this blog. What do you mean by cite it.
This is an original quote of mine. I spent about 30 years in several phases of software: coding, designing, supporting, and using. I have come to this conclusion. Signed, Ernie Hansen
-
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 your team. The situation wasn't exactly the same, but it may help you to see their point of view. A few years ago I and others had worked hard at creating a system that was just about doing it's job. However, the main page was big and slow. We had used too many 3rd party libraries. It worked, but only just. Then we had some young wizz-kid join the team, who started loudly proclaiming that this page needed to be re-written. I resisted. I shrugged off his concerns as over-dramatic, and consoled myself with weak arguments like "browsers will improve", and "hardware will get faster". It wasn't enough though; the page just got worse as more features were added to it. Eventually it got so bad that we gave in. We gave our young upstart his head and let him lead on a replacement. I worked closely with him, and in the end I learnt more from that kid in 6 months than I'd learned in the last 3 years. We created a fantastic replacement that we were all really proud of, that performs really fast and is really nice to use. I've used the knowledge I learned on that project to great effect on many projects since. Why did we resist so long? Well, we'd put a lot of work into the old code and didn't want to see it wasted. We didn't want to admit that a young interloper actually knew better than us old lags. More than anything, doing the work the first time around was painful, and we perceived that doing it all over again would be just as painful. As it turned out the reality was anything but; re-writing was a joy, and we were all very glad we bit the bullet. So how does this help you? Well it probably doesn't much. It's unlikely that you telling them their code is bad will motivate them to want to change. For us, we changed because it got to the point where the pain of inaction outweighed the pain of changing. What you could try is to sell the benefits of a re-write to them, and re-assure them that the change won't be as painful as they probably think it will. All the best.
-
The best way to improve a bad code is not to add to it. If there is a large amount of work already in the project, it sounds like it is, then it is impractical to just restart from scratch. But what should be considered is a better way - not just the way you want but a better way agreed by all - and then implement all new stuff using the new technology. That way the old stuff can be degraded gracefully and you get a new puppy come annual review.
Reality is an illusion caused by a lack of alcohol
I tried that once, but the manager did not want to change, saying it was "the standard". It took years of education to get him to agree with me.
-
Anup Shinde wrote:
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"...
Won't help you at all. If you find another job, you'll discover bad code there as well. In fact, the only good code I've ever seen is in some books.
-
Anup Shinde wrote:
But there is a lot of bad code in the project that I get to work on - so bad...
But does it do what it needs to do? If so, then it's just a personal preference/style issue that pits yours against others. Otherwise, if it indeed does not work, personal likes/dislikes are irrelevant and it needs to be fixed. Metrics are on your side.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
"Bad Code" does not simply mean that it doesn't work. Bad code may be very difficult to modify without introducing bugs. Bad code can cause performance problems that can't be fixed without a major rewrite. Then we get to the fact that bad code makes work tedious, unrewarding and frustrating. I once was faced with a small block of 5 lines that was copied hundreds of times in dozens of files with 3 required changes in each block rather than using a function, because the coder thought it was distracting to step through a function during debugging (he didn't know how to avoid that), and glowingly praised the way his code was clear and easy to debug, unlike the way most other shops did their coding. I spent a couple of years shooting bugs due to missing some of these required changes while extending the code, and trying to convince him to use functions. He eventually softened a bit, but nothing really changed until he gave up all of the coding to me, and realized how much faster projects could be done using new frameworks that did away with this level of coding.
-
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" :(
Anup Shinde wrote:
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.)
Sounds like you have a bad case of developers who are there for the pay check and job security, not because they want to make things better. Bad code often gets defended by the bad developers who wrote it in the first place as a form of job security. It may also just be plain stupid ignorance. If you really want to make a difference, and you feel you can improve the code base you're working on, refactor it in small increments. And then test extensively, and the refactor another small increment, and test ... wash, rinse, repeat. It may seem daunting at first, but soon you'll see changes. And once you have a set of changes that you feel demonstrates why your code is better, then show it to your "ignorant" manager. By having an actual implementation that works, and demonstrates your argument about coding practices, your team may see the error of their ways and may pay more attention. But it is imperative you have some evidence backing your argument. I was forced to fly under the radar against my managers wishes like this in the recent past, and once my argument was proven the development process evolved and was generally adopted.
|-------------------------------------------------------------------------------------------| | They wanted me to change the world, but God wouldn't give me the source code. | |-------------------------------------------------------------------------------------------|