Dealing with bad-code
-
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. | |-------------------------------------------------------------------------------------------|
-
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!
Feel free -- and don't be too shy about your English; it will improve with practice. (Besides, a lot of Americans don't have much command of English, either. Not that that's something we're proud of, mind you.)
All my best, Fran
(This message is programming you in ways you cannot detect. Be afraid.)
-
Feel free -- and don't be too shy about your English; it will improve with practice. (Besides, a lot of Americans don't have much command of English, either. Not that that's something we're proud of, mind you.)
All my best, Fran
(This message is programming you in ways you cannot detect. Be afraid.)
Tank you.
Fran Porretto wrote:
(Besides, a lot of Americans don't have much command of English, either. Not that that's something we're proud of, mind you.)
Same here in Brazil, sometimes it looks like we are heading to a Newspeak.
Sorry, my english is bad! Everything is easy for the man who doesn't have to do it himself. (Fran Porretto)