After having experience of group discussions in my life, I always realize something is missing. The most important point that we all need to learn and master; its the ethics and rules to follow in group discussion. Even normal topics that are not sensitive; still they can be dragged to disagreement and hard talk. We all have natural tendency to be defensive and egoistic, so be careful in group discussions. Following are the golden & ethical rules of group discussion (they do not apply to all group discussions for example, office meeting):

Respectful:

• We should respect each others opinion.
• You must be a good listener.
• Do not laugh unless participant is making a joke.
• Never blame participants. For example, You do not understand. You have not learned. You are wrong. You are so ignorant. Your thinking is negative.
• Be respectful to all participants.
• No personal attacks on a person’s intelligence, background, way of speaking, etc. Ref1
• Give respect to other participants by listening carefully others no matter how hard it is for you to digest it. Remember your stomach is weak thats your problem.

Equal Rights:

• Allow participants to express completely.
• Do not think you are intelligent, or who knows more and have better understand, do not bet it.
• Speak with facts and reasoning.
• Out of Line Comments: “That’s a dumb idea;” “You don’t know what you’re talking about;” “It figures a man/woman would say that”. Ref1
• Speak on your turn.
• Be polite, humble and accepting.

Positive behavior:

• Do not be emotional, remember everyone is emotional being.
• Behave rationally.
• Raise your hand if you have to say something.
• Speak on your turn.
• Do not yell.

Disagreements:

• There is high possibility of disagreement. Again follow you do not have to impose your opinion.
• Enjoy diversity, differences and complexity of topic.
• You can disagree in a polite way. For example, What I think so, this is true in that way.

• You do not necessarily have to accept others opinion, but you have to listen how others perceive differently.
• You donot have to impose your point of view, you have to just express and explain your point of view.
• Allow every participant to express his opinion.
• When you disagree with someone, make sure that you make a difference between criticizing someone‘s idea and the person themselves. Ref2
  

References:
Ref1: http://writing.colostate.edu/guides/processes/group/pop4b.cfm
Ref2: http://www.hrea.org/pubs/rules-discussion.html

I am developing software for almost 3 years though I have not done any significant or noticeable piece of software but the most common thing I always faced, my supervisor saying:

• We need to implement this feature.
• We need to omit this we ain’t gonna need it anymore.
• Oh we need that feature again.
• We need to change that feature it must work now this way.

And all time I used to comment the code so that if I need it again then I don’t have to develop or search this snippet again therefore it should better stay there in comments. See figure below

Sometimes the feature implementation is so much scattered that you can’t figure out. Like if we have some address field e.g., phone-1 and phone-2 to be added in different modules of our customer management systems e.g., customer, employee and then after a month we want to have only phone-1 and want to remove phone-2 now its difficult to track all code-paths.

In recent 2 years, I have seen so many tools and techies that make our job easy and allow to never be freaked out with donkey-coding and help us to avoid spaghetti coding. So I think we start thinking of our project in terms of features then we can organize our work. Its simply may be just another myth or may be just another philosophy or may be it’s gonna define a much better way to get the job done. With agile changes are so frequent that we get sometimes frustrated to deal them each time.

I believe IDE and Version control systems must work together. Because both are providing a way to develop code in an efficient and safe manner. So why they think they are strangers to each other, They must get marry and help us to improve our productivity. If some IDE claims to be IDE it must provide a mechanism for any version control system to be added to extend its usability. If some version control system claims to be best then it must know the manners to be integrated with any IDEs. Now I think time is to compel the vendors of IDE and version controls to work together and come up the way they can extend each other.

Now you can say feature based version is a practice its not necessary to have such system, we can still hold with our existing IDEs and Version controls. Like we continue to work on one feature and check-in the code with some decent comments, and then we can recover the files to older version if we don’t want that feature. But still we need an automated system that will help us to be more effective in our thinking of feature based versions. As we may have developed many features within those files, so reverting to previous versions cannot help us to roll back one feature it will take us to the start where we need to develop 10 other features.

First we need to define what a feature can comprise of,

• Is this feature? we need to implement security
• Is this feature? to add some address field to all modules
• Is this feature? to change a color of header text in webpage

Feature can be a broad abstract or it can be little thing. But somewhere our system may be an intelligent one that if we want to remove any feature we can do that without disturbing other functionality. Our version system and IDE needs to be intelligent to track feature code not by just line numbers but by content also. Suppose if developed feature_A in method my_method, I also added a line for feature_B in the same method it can change line number of feature_A code, may be I have added a feature_B line within the lines of feature_A, so things are going to be tricky and feature-based system needs to deal with all such possible hurdles like may one feature depends on another feature so roll-back may not be done.

Well main point is to have system to identify the code developed in different files for one feature. We need to roll-back changes for example layout we defined 3 times differently for the grid view template.

We need some intelligence to refine the concept of feature; I think feature must be as small as possible and as reasonable to be done as Feature-based to be worthwhile. The concept is to not get panic and develop one thing at a time, finish it, test it and make it reliable and then move next. Prioritize your task. May be there can be a system which may allow to work at multiple features and we can switch between features.

Benefits:

• start and end time of feature development and time taken for feature report for manager
• Feature can be recognized by meaningful title rather than 1000 of line of code.
• There can be an interface where Supervisor can upload/write number of features and assigned to a developer and they can be automatically loaded into developers to-do and therefore we can repository who is working on which tasks also that can be used for different reports.
• feature roll-back, feature removal
• Developer can work on multiple features and when he wants to commit code he can just commit changes for specific features. IDE has the tracking system to track changes done in different/same file for different features, and will commit code without selecting files manually.



Conventional way of selecting files will no longer be required

Critics:

• We are with habit to do so many things at one time (add a comment, replace an error message), so handling multiple features require extra efforts. Will this be a gud thing to do One task/feature at a time, and never take freedom to any small change in any other file, there may be a marker system which allow to relate a change to s specific feature.
• Do we need to develop a feature-based system, or we may have freedom to define some features that we think are critical tasks and are more prone to change in future and do rest of the jobs in conventional way. Or take every small thing into feature-based. Both ways there can be so many hurdles or impossibilities, need lot of study.
• Sometime when project goes in maintenance mode mostly changes are done at that time if our customer can afford which actually create hassle to deal them. But may be during development phase there is less a case we may need such frequent changes.

Note: to be continued, not completed yet