aspose file tools*
The moose likes Agile and Other Processes and the fly likes Even bad code can function. But if code isn�t clean, it can bring a development organ Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Even bad code can function. But if code isn�t clean, it can bring a development organ" Watch "Even bad code can function. But if code isn�t clean, it can bring a development organ" New topic
Author

Even bad code can function. But if code isn�t clean, it can bring a development organ

arulk pillai
Author
Ranch Hand

Joined: May 31, 2007
Posts: 3256
Based on the link http://www.pearsonhighered.com/educator/academic/product/1,3110,0132350882,00.html

Even bad code can function. But if code isn�t clean, it can bring a development organization to its knees.


What is your definition of a bad code versus a clean code?

Do you mean that unclean code is where exceptions are not properly handled, not designed well, not using best practices, not developed for concurrent access, etc?


500+ Java Interview Questions and Answers | Java job hunting know how & Java resumes
Alaa Nassef
Ranch Hand

Joined: Jan 28, 2008
Posts: 467
Imagine you are working on a class containing 3000 lines of code in just 4 methods, with variable names like x, rs, pgt and thn, and non descriptive method names. This is certainly really bad code.

Now imagine splitting this class into a whole package of its own, where any method has a clear self descriptive name and has a maximum of 15 lines of code, and the variables are named in a self descriptive manner, where you know what each variable stands for and what is the functionality of each method. This is an example of clean code.

Of course there's a lot more than that, and that's why we have a whole book on the subject (actually a lot of books).


Visit my blog: http://jnassef.blogspot.com/
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
I'd probably define clean code as "code that is pleasant to read".


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Alaa Nassef
Ranch Hand

Joined: Jan 28, 2008
Posts: 467
And that produces a low number of WTFs per minute
arulk pillai
Author
Ranch Hand

Joined: May 31, 2007
Posts: 3256
Why will this bring the development organiztion to its knees?

There are a lot of other things that can do this. In my experience I always see these unclean code. Everyone has his or her own rationale for naming methods, variables, splitting into methods, etc. I am not saying it is not important, but it won't hurt the project as much as some of the other aspects that are more critical. The projects with bad code can still surve with a large number of frustations and WTFs . What can really impact the project is code that does not meet the SLAs, badly designed, that is hard to reuse or maintain (one change will break something else), transactional aspects are not handled properly, intermittent behaviour that can not be consistently reproduced due to concurrency issues, no proper documentation, exceptions are not handled properly, badly logged, not properly following agile development methodologies, etc can hurt more.
Katrina Owen
Sheriff

Joined: Nov 03, 2006
Posts: 1364
    
  17
Originally posted by arulk pillai:
Why will this bring the development organiztion to its knees?

There are a lot of other things that can do this.

(...)

What can really impact the project is code that does not meet the SLAs, badly designed, that is hard to reuse or maintain (one change will break something else), transactional aspects are not handled properly, intermittent behaviour that can not be consistently reproduced due to concurrency issues, no proper documentation, exceptions are not handled properly, badly logged, not properly following agile development methodologies, etc can hurt more.


What you say is true - and much of it relates to the quality of the code base itself.

Code that isn't clean is difficult to reuse and maintain. When code is not clean, it is far more difficult to track down and fix bugs, troubleshoot, understand, handle exceptions correctly, deal with concurrency issues, add features, fix bugs, tweak functionality, document, extend...

This can bring an organization to its knees, as the lack of clarity will increase the time to market, and increase the defect rate - both of which are quite expensive.

When this gets too expensive, eventually the project dies. Occasionally, the company goes down with it.
Alaa Nassef
Ranch Hand

Joined: Jan 28, 2008
Posts: 467
Originally posted by arulk pillai:
Everyone has his or her own rationale for naming methods, variables, splitting into methods, etc.


And to add to what Katrina said, since everyone has his OWN rationale for naming methods, variables, etc., when someone leaves the organization (or move to another project), maintaining his code becomes a pain, which causes a lot of lost time, maintainability issues, new bugs due to the lack of understanding of the code of the previous person, and of course, since the new person will have his OWN rationale, the code will be a mixture of both styles, which means more mess.
Robert Martin
Author
Ranch Hand

Joined: Jul 02, 2003
Posts: 76
Originally posted by arulk pillai:
Based on the link http://www.pearsonhighered.com/educator/academic/product/1,3110,0132350882,00.html



What is your definition of a bad code versus a clean code?

Do you mean that unclean code is where exceptions are not properly handled, not designed well, not using best practices, not developed for concurrent access, etc?


Have you ever been significantly impeded by bad code? Bad code is code that slows you down. It makes it hard for you to make changes, because the repercussions of those changes cannot be predicted. Every time you touch one part of the code, other parts break. In order to make a single change to a feature you have to touch many different modules.

Bad code is coupled, opaque, fragile, rigid, immobile, complex, etc. etc.


---<br />Uncle Bob.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Alaa Nassef:

And to add to what Katrina said, since everyone has his OWN rationale for naming methods, variables, etc., when someone leaves the organization (or move to another project), maintaining his code becomes a pain, which causes a lot of lost time, maintainability issues, new bugs due to the lack of understanding of the code of the previous person, and of course, since the new person will have his OWN rationale, the code will be a mixture of both styles, which means more mess.


The only way I know how to prevent this is making sure that people understand each other's rationales and over time even develop a team-wide rationale. And the best way I know to do *that* is - Pair Programming...
arulk pillai
Author
Ranch Hand

Joined: May 31, 2007
Posts: 3256
Every time you touch one part of the code, other parts break. In order to make a single change to a feature you have to touch many different modules.



This why it is very important to get the baseline architecture and first vertical slice for a typical usecase right. Once you get this right collaboratively, the successive usecases can be easier to implement and cleaner.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by arulk pillai:

This why it is very important to get the baseline architecture and first vertical slice for a typical usecase right. Once you get this right collaboratively, the successive usecases can be easier to implement and cleaner.


While there is a lot to this, for a long-living system (and all successful systems I know *are* long-living), it doesn't suffice. After years of implementing new functionality, the architecture needs to be significantly different from the one supporting the first "typical usecase". In my experience, the only way to get there is continuous refactoring.
Alaa Nassef
Ranch Hand

Joined: Jan 28, 2008
Posts: 467
Originally posted by Ilja Preuss:
And the best way I know to do *that* is - Pair Programming...


I agree that pair programming is really helpful in a lot of other situations, but in this situation, I believe that the pairs should be changed every once in a while so that we can get to just on rationale instead of just the half of the number of developers. Just that moving people around all the time might cause problems.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Alaa Nassef:

I agree that pair programming is really helpful in a lot of other situations, but in this situation, I believe that the pairs should be changed every once in a while so that we can get to just on rationale instead of just the half of the number of developers. Just that moving people around all the time might cause problems.


In fact, Pair Programming should *always* be promiscuous, in my experience. Fixed pairing partners aren't just a smell - they drive me insane... See http://agiletoolkit.libsyn.com/index.php?post_id=15636

Not sure what problems you are imagining with that approach...
Alaa Nassef
Ranch Hand

Joined: Jan 28, 2008
Posts: 467
Originally posted by Ilja Preuss:
[QB]Not sure what problems you are imagining with that approach.../QB]


Some people just don't get well with each other, while some people hate change.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Alaa Nassef:
Some people just don't get well with each other,


Promiscuous pairing does *not* mean that everyone has to pair with everyone else...

while some people hate change.


That's nonsense - everyone changes, all the time. Many people resist to change that isn't under their control, or that doesn't seem to be aligned with their needs, though.
Alaa Nassef
Ranch Hand

Joined: Jan 28, 2008
Posts: 467
You make a good point
 
 
subject: Even bad code can function. But if code isn�t clean, it can bring a development organ