I am currently working with a leading MNC as a Java/J2EE Developer. I am passionate about blogging, reading books and listening to music. You can read my blogs @ https://iduvejeevana.wordpress.com/ Suresh has posted 9 posts at DZone. View Full User Profile

Monitoring the Health of a Development Project

05.06.2010
| 4787 views |
  • submit to reddit

I have been thinking about this role for quite some time now. I have had the chance to work on a couple of development projects and one thing that stood out in common was the lack of time invested in design reviews, code reviews, etc on an ongoing basis i.e. throughout the life cycle of the development project. Even if there were reviews, most of them cited the obvious, which mostly revolved around good naming conventions, etc. But what I had been looking for is a review that could help me validate my choice of a design principle or a strategy to solve a complex UI requirement. But unfortunately nothing much happened on this front.

The following are the reasons why I feel that there haven’t been enough reviews happening in most development projects:

  1. Too many meetings – This is probably the main culprit. I observed there are way too many meetings happening all the time and you would have all the leads attending one meeting or the other all the time. It leaves them with very little time in a day to focus on the “Actual Task” at hand.
  2. Lead to Developer ratio – This is another major contributor for the lack quality reviews from leads. A good lead (Module lead) to developer ratio 1:3. Why this ratio? I feel that a module lead can devote his time towards 3 developers at the max and still be able to deliver as expected. Once this number exceeds, things begin to get a little bit out of control. A lead then has to start spending a lot more that required time with developers to clarify and addressing issues. This leaves him with little time to focus on his regular tasks like code reviews or low level design. Hence it is very important to maintain this ratio.
  3. Process is a means of achieving the end result not the end itself – Let’s face it. Process is good. But it should always be adopted with a pinch of salt. If we bring in too may processes, it will only introduce too many levels for achieving something in a project. I am talking here about some process which has just been adopted because you wanna come out clean in some XYZ standards audit. Heck! it’s not gonna work. You may end up having followed all the processes but the end deliverable is not just what the customer wanted. It is more of a “means” to achieve results and not the “end result” in itself.
  4. Dead lines – I had written it before too. Just re-iterating it here; Deadlines often introduce a lot of dead lines of code in a project. It is very important to keep a tab on the time lines and make the most out of it. Hence the development team must get its due time. Reviews must happen on time and shouldn’t be a post harvest/project retrospection activity. Looming deadlines should never be a reason for postponing reviews.
  5. Lack of demarcation of roles and responsibilities– A project must have a clear demarcation of roles and responsibilities. This is required for 2 things. Firstly, It sets the right expectation with the person discharging the responsibilities associated with the role. Secondly, it avoids unnecessary confusions and duplication of efforts in the team since everyone knows exactly what he/she is supposed to do and not to do. Sometimes it these little things like knowing exactly what to do that can work wonders for a team in a time crunch situation.

Due to the above, we find a lot of projects deviating from their normal course, without getting noticed. Can this be avoided? Can a project be saved from gradual derailment?

I think yes! What we need to do, is to introduce a role into the project, that would be of a dedicated reviewer.

Some of the salient responsibilities of this role could be:

  1. Ensure that reviews are done on time and development team get good feedback on their implementations and designers on their designs.
  2. The person assigned with this role, would be accountable for ensuring the reviews happening on time and not the execution of the end deliverable in itself.
  3. The person is expected to be available at all times to provide feedback and flag deviations as soon he/she identifies it in the project. This would help teams to rectify inconsistencies as soon as they get introduced into the system, either in the design or implementation.
  4. Facilitate the development team in identifying re-usable components as and when he/she discovers an opporunity.

After going through the above description of the role, you might get a feeling that the role is very much close to what a Technical Lead it supposed to do. Ain’t it? But I beg to differ with you here and here’s why.

A Technical Lead is not only accountable for giving a high level design but also is highly accountable to the actual deliverable. Hence his scope of work often spills over from just technical guidance to managerial aspects of the project. It would also get increasingly difficult to attend to the queries of the entire team.

Hence there is a need for a role whose sole responsibility is to monitor the health of the development project. Give quality feedbacks and conduct "continous reviews" and ensure the project's health is always green.

Published at DZone with permission of its author, Suresh Murthy.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Avdhesh Yadav replied on Fri, 2010/05/07 - 2:10am

I do not agree with your points.I think team members and peers are best people for doing the reviews(specifically code reviews).

Suresh Murthy replied on Fri, 2010/05/07 - 8:13am

@Avdesh,

Thank you for your comments.

A project can be benifitted to the maximum if the reviewer happens to be someone who has a thorough understanding of the architecture and design aspects of the project. Else the reviewer will be not able to contribute to the fullest. 

Hence I feel that a full time reviewer should be viewed at more like a full time role in the project just like a Developer or Module Lead or project manager.

Avdhesh Yadav replied on Fri, 2010/05/07 - 8:55am

Who has the thorough understanding of the architecture and design of a project?.Developers are the one who go through the iterative process of learning the domain and improving and refactoring code.. Simply creating a full time role of reviewer would not help until he contribute with code and design.

Gilbert Le Blanc replied on Fri, 2010/05/07 - 9:14am

I agree with your thoughts.

In times past (the bad old mainframe days), the technical lead was called the project leader.

The person you're calling a dedicated reviewer was called the project (or system) architect.

Dividing the responsibilities between architecture and construction works pretty well when building buildings.  It works just as well when building software. 

Suresh Murthy replied on Fri, 2010/05/07 - 2:30pm

@Avdesh, I totally agree with you that those who dirty their hands with a few hundred lines of code are the best people to evolve and improvise a system. Hence a full time reviewer must be someone who has enough expertise to deliver in that role. Hence must have spent enough time dirtying his hands coding before he takes up this role. On a different note: I remember reading a section in Eric Evans's Domain Driven Design where he cites [Chapter 3, Page60, Hands on Modelers] where he emphasizes the need to ensure that a model proposed by an architect or a lead must reach out to every developer in a project. The essence of the model shouldn't be lost during translation. But unfortunately this happens most of the times. But I have observed in my earlier projects that due to lack a dedicated person who can continuously monitor the outcome (read as code/design) from a development team, a lot of discrepancies creep in over a period of time and the code really starts to loose the essence of the overall model/design. Another factor could total compartmentalization of work due to no single team has a holistic picture of what's going with the other team during the middle of a development project. There can be many reasons why deviations creeps in: 1. New joinees may not have enough time to ramp and deliver. 2. Lack of bandwidth in the project to walk the new entrants through the high level design or architecture. But having a full time reviewer helps the project benefit in a way that we now have a member who can view the progress of the project in a holistic manner since he is getting to see what's being checked into the repository every single day or who is proposing what solution to a given problem. This helps him review and provide feedback in a very holistic manner and not just narrowed down to a specific module or a component. I do agree that this role looks pretty much unheard of or you might feel is it worth it. But I surely see a lot of benefits in having such a role since it helps maintaining a great deal of consistency by giving "Timely Feedback".

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.