2

Possible Duplicate:
Techniques to re-factor garbage and maintain sanity?
Code maintenance: keeping a bad pattern when extending new code for being consistent, or not?

I was hired about 6months by a company that uses Agile, but after learning the code I've realized that it's bad code - methods with over 100 lines of code, duplicate code, methods that says it does one thing but does a few other unrelated things. It works, but the more we update it, the more it become like a house of cards. Refactoring one little thing requires changing lots of others, which can make program unworkable. What did go wrong and is it possible to fix it? I thought agile was supposed to make a good code.

Community
  • 1
Val
  • 147
  • 3
  • 12
    Agile doesn't guarantee quality of code. If you have crappy team members who don't know how to code well, doing agile isn't suddenly going to make them super stars. – Mark Canlas Mar 14 '12 at 08:28
  • 2
    The process is limited by the developers utilizing it. If they dont' truly understand it, or have bad habits such as what you've described and no-one to force them to change, it means nothing. – canadiancreed Mar 14 '12 at 08:28
  • 5
    Welcome to the real world. Probably need to introduce code review by peers. –  Mar 14 '12 at 08:37
  • 1
    I would say that Agile *enables* developers to produce good code, by striving to remove most or all obstacles standing in the way of doing quality work. But as others too noted, once this is done, the importance of having good developers in your team becomes most prominent. Whereas non-agile, big-M Methodologies try to guarantee deterministic output by forcing everyone to the same mediocre level, thus hiding the difference between individual developers. – Péter Török Mar 14 '12 at 08:56
  • There are several related (or even duplicate) threads, including http://programmers.stackexchange.com/questions/66438/techniques-to-re-factor-garbage-and-maintain-sanity, http://programmers.stackexchange.com/questions/46637/code-maintenance-keeping-a-bad-pattern-when-extending-new-code-for-being-consis and http://programmers.stackexchange.com/questions/132926/how-does-one-determine-whether-or-not-to-rewrite-poorly-designed-code . – Péter Török Mar 14 '12 at 09:16

4 Answers4

5

There could be so many reasons why the code looks like it is. Like other comments have suggested, Agile is not a medicine for all illness in software.

Is it possible to fix it?

No one can judge this more than you. If you have the skills, resources and if the system is continually changing or if it is critical to your business, may be you MUST fix it.

The major reason I am writing this is to make you aware of an important fact. Don't mess around with this system unless you really know how it works well and you really have to. Forget about the beauty of the code and focus on functionality and performance.

If you want to do a real change, make sure it is planed for and that you are ready for it.

Sometimes it is hard to resist the say "if it ain't broken don't fix it" but that it is not professional of course.

No one gets credit for breaking a system even if it is a bad one.

NoChance
  • 12,412
  • 1
  • 22
  • 39
0

You have to live with it.

Had been in a similar position. Rewriting the whole code can often be underestimated and is a huge undertaking. It will need your supervisor approval. I haven't rewrote my code it but had experimented rewriting part of it. By doing that I made my life easier, at least I found what was going on. I left the original code as it is. After cleaning up part of it for myself, I had more confidence dealing with the code. Although with mine, the logic of the code was fine, it was the styling that was extremely badly written and that made changing the code very hectic. But I have learned to live with it and I have adopted the same bad coding style to get thing done :)

TheTechGuy
  • 1,035
  • 1
  • 8
  • 16
0

Well i think you are mistaken about Agile being the culprit, Its more to do with how sound you are with coding and most important the one touching the code knows what its intended to perform.

Without this its most of the time hacking into a piece of code so that you get the things on the plate cleared off and then later stumble upon another block which you would have created since you didn't really figure/know as what the code was doing.

Maybe at times it would be good if you could refactor a few methods as and when you encounter problems (i am not saying rewrite) and try clear the mess up a bit, at this point you should definitely know what the code should do and iteratively after a period of time you can see some positive results.

In the meanwhile you can also introduce review (if it exists check why its not effective) and help out the lesser non mortal coders and share with them good practices and give company to your code with some relevant comments.

Hope it turns around n some time but you need to give it some time.

V4Vendetta
  • 594
  • 3
  • 9
0

Agile doesn't make bad code, leave that to bad programmers. You should start off by writing inline comments pointing out the problems, then go about fixing them one by one. It's hard work, but that's what you were partly hired to do anyway.