July 1, 2014


The Art of ORGANIZING in different phases of project (Page II)

How to take up such changes?

The above change is not a small change. The introduction of new features like above demands a lot of code to refactor and even goes beyond simple refactoring.

Importance of the organization activity

In the event of such changes coming up, my take would be to go for re-organization activity so that further code changes can be easily accommodated and other project activities like code reviewing, static code analysis, testing, fixing errors, comments, documentation are eased out and in synch. In the event of failing to do this activity, there introduces short cut routes to implement a change which are then difficult to handle and also explain in future to different stake holders.

It is a waste of time in different phases of the project if uniqueness is not found out. The duplicity would not only remain at the level of code but would propagate to duplicate logics, comments, more documentation, multiple similar errors to fix, and more unit test cases.

When measured, this activity can cut down a lot of time in later phases of the project.

In order to carry out such changes, one should try to assemble requirements, including changes, in hierarchy so that all major components fit in a relaxed way. To achieve this one need to STRATEGIZE.
Almost all project activities/tasks are two steps based:

  1. Strategize – This involves thought process, discussions, learning, and help and
  2. Execute – Concrete implementation.

In carrying out organizing activity, Strategize is one time activity or revisited at the time of any substantial changes or incorporation of new features.

It is an important activity and can prove very fruitful if done correctly. Sad picture is that it is taken on a loose end.

Failure Reasons

On analyzing the feedback that I received from different stakeholders, I observed that it is the Strategize step which do not find place in sprint activities or in effort estimate sheets but only the execution step is estimated. This then puts pressure on the forthcoming tasks leading to implementation of shortcuts and accumulation of psychological reluctance to do tasks in the rightful way due to pressure which then soon become a habit spreading to different other projects and propagating in the entire project-culture.

The first step of coming up with a strategy should find a considerable place in planning meetings, effort estimate sheets and sprint activities. It should be the most sought after step than the executed output. The importance of this step should be equally weighed among all stakeholders from Junior to Senior Developers to Team Leaders to Managers.



Here are some recommendations:

  1. Plan enough time to organize requirements. This should include the time that you would spend on discussions, thought process and in getting any external help, if required. Since this will become the base of your further activities, it should be taken seriously. If you are able to organize requirements into a hierarchy of major components, bringing out that hierarchy to writing code, comments, documentation, creating sub-modules like Help and Tutorial and even explaining features while giving demos would be a cakewalk.
  2. Leaders/Managers should seek Strategize activity in planning meetings, sprint activities, and estimates. They should support and encourage other stakeholders to make them part of planning, discussions and estimations.
  3. Stakeholders should not try to consume Strategize activity’s effort in Execution activity’s effort. Make them separate and that way it will make estimates more realistic, provide more clarity to the phase you are working in and will make you more synchronized with status checks.
Do’s and Don’ts

Here are few do’s and don’ts to assist in practical execution of the art of organizing:

  1. Think simple and don’t let the complexities of tools, design patterns, and wiring of code to be a base for your decisions. However, thinking simple is hard. The more you try, the more it will enhance.
  2. Use simple tools; Paper and Pen. Instead of using sophisticated tools like MS Visio or any other tools to create diagrams to create class or similar diagrams, start with pen and paper to sketch out the hierarchy of major components and gradually add more detail. If you are not able to do it on a paper, you’ll NOT be able to bring that out in any tool and in code implementation.
  3. Give more importance to write pseudocode before the actual code.
  4. Don’t let your classes be polluted with random thoughts of implementation in achieving requirements or changes where you end up writing properties or methods in just any related class. Try to fit it into the hierarchy where changes can settle down in a relaxed way, even if that demands a big change in the entire hierarchy and a massive change in the data structures.
  5. Don’t apply surface level make ups; which are famously called as patches and workarounds.
  6. If you are not able to continue, it should give a kick that there is something missing. Employ thinking out of box by giving shapes to the missing links at the block level. If required, discuss and seek external help.
  7. With enhanced support of
    1. Code refactoring methods
    2. Code auto completions
    3. Source code generation steps like generating class layouts, inheritance hierarchies, getter and setters etc.
    4. Code organization like Sorting class members; properties and methods in a sort order on private, default, protected and public modifiers.
    5. Code formatting

      in IDE like Eclipse, FlexBuilder etc.. It is very easy to flow down hierarchical organization to the code.
  8. The Art of Organizing is such a crucial activity that in interviews more questions should be asked to check the abilities of organizing.
  9. If you are stuck at any point where you are not able to draw out the hierarchy, stop thinking, may be take a break and come back afresh.
  1. Namespace definition: http://en.wikipedia.org/wiki/Namespace
  2. Factory design pattern in Java: http://howtodoinjava.com/2012/10/23/implementing-factory-design-pattern-in-java/
  3. Generics in Java: http://en.wikipedia.org/wiki/Generics_in_Java
  4. Icons by http://dryicons.com. Icons are licensed under DryIcons Free License Agreement. This doesn’t include the pictures to represent hierarchies.