Is there ever a valid scenario to check in commented code?

Unsure about the changes : From my experiences whenever I comment the code it is because I am not sure about my changes for the time being and I want to test them first may be with some of the already existing pieces commented out. This is just to make sure I do not have to write the same stuff back if my changes do not work.

That is Ok to do as long as we realize that commenting out code is very temporary thing and should never cross the boundary of our workspace. If it does and it goes in the version control, then in a way we are doing what version control does for us (by letting us retrieve the older versions of the code).

Two or more scenarios out of which only one is applicable at a time: Make it configurable to pick one scenario at the run time rather then commenting out the valid scenario and uncommenting the invalid ones before each run. It might sound funny as to why people would want to do it this way but believe me I have seen such occurrences and to quote the most frequent is logging.

I will just leave it there commented out till my code is reviewed: Again just make sure it is not breaking the build and check it in. For the worst scenario, version control has the old version which we can always pickup anytime so why keep the dead code around.

I just read about it in an interesting post on code deletion. The Joy of Deletion

Might Help Tip

org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 5 in XML document from class path resource [test-jdbc-context.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element ‘beans’.

Caused by: org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element ‘beans’.

This happens as a result of using the older version of spring framework while the DTD in the xml files point to a newer version. For example if you have spring.jar of lets say spring 2.0.8 while the xml file points to spring-beans-2.5.xsd

Non Technical Techies.

This is exactly what they are. I have come across so many of them already that it is not merely by chance for sure. I am not talking in terms of their skills or knowledge but mostly in terms of their attitude and outlook.

Looks like being in a technology division or churning out code day in and day out (yes this is exactly what they think they are doing) is just by chance and not by choice. Let alone feeling passionate for what they are doing, they seem so disinterested as they feel it is the way it has to be till they start leading a team or get into project management.

This is what I get to hear. Writing code is easy, anyone can do it. I want to go beyond it. Yes I agree anyone can do it but does that anyone can write good quality readable and maintainable working piece of software, very few. How many really want to perfect the art of designing and writing code.

It is just like a craftsman instead of trying to perfect that craft and setup an example of showing how it should be done wants to lead (read manage) a distant-to-qualify-even-decent and still learning group of craftsmen which themselves are not proud of what they are doing. Sometimes it is hard
for me to make people believe that I am still coding after 11 years and I really enjoy doing it and enjoy growing even more technically.

A big part of being agile is doing ‘Just Enough’

Just Enough Requirements: The idea is not to get down to the finest details up front, capture just enough information which will enable team to estimate the development time for the requirement (in a form of user story) with a window to have a discussion with customer at a later time for the needed functionality. By going lazy with the requirement gathering, we are sure what is being developed is really what the customer want. Guy Beaver supports this in his article on The Challenge of Enterprise Requirements Management

The suggested solution is to replace early detailed specification with solution road maps that can be detailed by collaborative teams at just the right time. Agile methods provide the structure and mechanics to allow business vision to lead product development with cross-functional teams that unfold detailed requirements when needed

Package Structure

It might get very interesting and tricky to layout the packages, no I am not talking some skeleton directory structure which is generally created when we create a new eclipse project or run maven, it is more about the way packages should be structured to avoid cyclic dependencies.

When we start we start out with a very basic bare minimum structure but it starts to get ugly as code evolves and we start to unknowingly and unintentionally start creating cyclic dependencies.

What are they : Package A depends on package B and package B starts to use a class of package A

Why Not: Hard to maintain code where a change in package A leads to change in package B which in turn might again need a change in package A. So a small change starts to propagate throughout the module or may be beyond. Hard to reuse code as it will not possible be to take out a package and convert it into a module due to high dependencies across packages.

How to measure it: There are certain static analyzing tools which help in finding out the cyclic dependencies and a free and very popular one is JDepend.

If already in it how to get out: Common set of classes spread across packages into a single utility package or may be in a full blown module.

Rule of thumb: Packages should have one-way dependencies

Learnings from Interview Discussions

When I am interviewing someone I am not hiring a guy to work for the company I work for, but instead a possible colleague. It is never about the years of experience it is more about the ability to learn and the passion for the work. The idea is never to look out for a match for the requirement but look out for potential, drive and skills beyond the requirement at hand. Few things topmost in my list to look out for beyond just the technical know how in general.

Article on TSS

Agile software development has its own manifesto which lays out the values and principles of agile process. I have tried to look beyond (or may be just deeper into the meaning of) the essential four value statements in my article at TSS

http://www.theserverside.com/news/thread.tss?thread_id=48140