Code Review is an age old practice in Programming. Nevertheless, code review becomes a bit challenging for distributed teams. If the development team policy does not allow junior developers to commit (check-in) unreviewed code to their development branch in version control, then it becomes a bit difficult for distributed teams to implement an efficient code review process without creating separate branches in the version control repository for every change. A new branch for every task can potentially create hundreds of branches which can soon become confusing and unmanagable for the team. In my experience, only the most expensive version control tools are good in dealing with merging/promoting code across multiple branches.
I think a cost effective approach to solve this issue would be to utilize the "create patch" functionality available in most version control tools (like Subversion). Patches are nothing new in the world of programming. Every open source project utilizes this feature. Developers can create a Patch and commit (check-in) the patch file to a well known location (say a patch folder) and notify the reviewer. The reviewer (located in a different location/time zone) an apply the patch to his local work area, review the changes at his own convenience and get back to the programmer with his feedback (by email, phone, discussion board, etc).
For detailed instructions on how to create and apply a patch in Subversion using Tortoise SVN Client visit http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-patch.html.
I think we can also utilize patch functionality to store code which is useful but not yet ready for release. Often we end up building functionality/proof of concepts which cannot be checked in to the main development branch because it is still not ready for prime time. In these cases we can preserve the changes as a single patch file for future use.
Thursday, July 09, 2009
Tuesday, July 07, 2009
Agile Development Skills
"Your earning ability today is largely dependent upon your knowledge, skill and your ability to combine that knowledge and skill in such a way that you contribute value for which customers are going to pay." --Brian Tracy
I think it would be a mistake to think of Agile only as a new methodology for Software Development. To me Agile is more than just a methodology. It is a paradigm shift not only in the way we develop software, but also in our roles in the development team. In an Agile context we can no longer confine ourselves to a narrow specialty (Analyst, Programmer, Team Lead, Tester, etc.).
Agile Team members must be willing to help out in areas outside their traditional roles/expertise. For example, a Tester might be asked to help out by creating wireframes (screen mockups) to get approval from the customer. The architect might have to help out by writing low level code or fix defects. The project manager might have to help out with Testing. In an agile team, the team members will have to be willing to help out in various areas from time to time to meet the Sprint goals. The new role demands more communication, commitment and versatility from every team member and also makes our job more interesting and fun. In Agile terminology this is commonly referred as Generalizing Specialist.
I think the traditional separation of roles creates a caste system in the team which does more harm than good. In a traditional role centric environment, the team members do not feel empowered to get the job done. So it is very challenging to deliver working software in short Sprints (usually monthly or bi-weekly).
I think it would be a mistake to think of Agile only as a new methodology for Software Development. To me Agile is more than just a methodology. It is a paradigm shift not only in the way we develop software, but also in our roles in the development team. In an Agile context we can no longer confine ourselves to a narrow specialty (Analyst, Programmer, Team Lead, Tester, etc.).
Agile Team members must be willing to help out in areas outside their traditional roles/expertise. For example, a Tester might be asked to help out by creating wireframes (screen mockups) to get approval from the customer. The architect might have to help out by writing low level code or fix defects. The project manager might have to help out with Testing. In an agile team, the team members will have to be willing to help out in various areas from time to time to meet the Sprint goals. The new role demands more communication, commitment and versatility from every team member and also makes our job more interesting and fun. In Agile terminology this is commonly referred as Generalizing Specialist.
I think the traditional separation of roles creates a caste system in the team which does more harm than good. In a traditional role centric environment, the team members do not feel empowered to get the job done. So it is very challenging to deliver working software in short Sprints (usually monthly or bi-weekly).
Sunday, July 05, 2009
Open Source Development Tools for Small and Medium Enterprises
Here is a listing of best of breed open source tools for Java/J2EE Software Development:
- IDE - Eclipse (Check out the Easy Eclipse distribution)
- Version Control - Subversion
- Unit Test Tool - Junit
- Web Server - Apache HTTP Server
- J2EE Application Server - JBoss
- Project Management - Open Workbench
- Project Management - Openproj
- Defect Tracker - JTrac
- Web Application Test Tool - Selenium
- Load Testing - Apache JMeter
- Test Case Management - TestLink
- Continuous Builds - CruiseControl
- Web Development -Firefox Web Developer Toolbar Firebug
- Web Development - Internet Explorer Developer Toolbar
- Browser Testing in Various Versions of IE - IE Tester
- Web Accessibility - Web Accessability Toolbar
- Reports - iReport
Friday, July 03, 2009
Cross Functional Teams
We need to appreciate the need for cross functional teams for speedy delivery of working software. A cross functional team is perhaps the single most important ingredient for project success. The cross functional team should have competencies ranging from requirements analysis, project management, software architecture, web development, database development, testing, etc. Every team member shares the responsibility for the delivery of working software to the client and operates without team boundaries and organization silos. Senior management needs to empower the team to make strategic and tactical decisions to meet the project goals. To a great extent, the success of cross functional teams depends on organization culture. Care must be taken so that the functional reporting managers do not burden the team members with conflicting assignments (serving vested interests and individual egoes) that dilutes focus away from the project at hand or demotivates the team members by not giving them credit for the project assignments that serves a bigger purpose for the organization. This requires strict vigilance and commitment from senior management. I have encountered several examples where a functional reporting manager indirectly penalized their subordinate for working on high performing cross functional team which did not directly serve the narrow interest of the functional manager.
Agile also advocates close collaboration with customers throught the project development cycle. However, breaking the psychological barrier between vendor and client is a prerequisite for such a collaboration. Honest and open communication is the bedrock of collaboration. Portraying a "happy picture" of the state of affairs by the vendor does not always serve the best interest of the project. Suppressing project challenges and risks to the customer during the project only increases the possibility of last minute surprises causing customer dissatisfaction and business risk (both financial and non-financial) for both the vendor and the customer.
Agile also advocates close collaboration with customers throught the project development cycle. However, breaking the psychological barrier between vendor and client is a prerequisite for such a collaboration. Honest and open communication is the bedrock of collaboration. Portraying a "happy picture" of the state of affairs by the vendor does not always serve the best interest of the project. Suppressing project challenges and risks to the customer during the project only increases the possibility of last minute surprises causing customer dissatisfaction and business risk (both financial and non-financial) for both the vendor and the customer.
Thursday, July 02, 2009
The human factor in Software Project Execution
"If you want to build a ship, don't drum up the people to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea."
Traditionally, software project execution had always been a lesser discussed topic than Project planning. While planning is essential for Project Success, the ground realities of software development seldom matches the "ideal" world documented in the Project Plans. Too much of upfront planning and processes often failed to yield the expected ROI in the dynamic world of modern software development. In my experience, most of the high level project planning is performed by Senior Management who either do not have a good understanding of the actual complexities of project execution or lack the will and commitment to do so. Unrealistic expectations set during project inception often doom a project to a death march right from the very begining. It also creates lots of stress and demotivation to the development team that has to fight the battle in the trenches. The net result is that development team has no choice but to "mechanically" follow the "process" on a journey to nowhere.
The Agile Manifesto stresses more on the ground realities of Project Execution vs. Planning. Since, actual results are produced by people, agile stresses more on "people" over "process". While processes and tools are an integral component of team collaboration and success, individuals drive success more than the processes and tools do. Prior to agile, the human factor did not get its due recognition. I think most of the traditional processes failed to address the human factor in software development. In my experience, humans do not work very well when asked to work under too many constraints. Too much processes and beaurocracy dilutes individual accountability and responsiveness. The irony is that the many traditional process that were originally designed to help teams succeed, actually turned out to be impediments to real progress.
However, I would also like to caution that Agile in no way advocates "ad hoc" development. It requires more "process maturity" on the team compared to traditional (process heavy) methodologies where people are expected to work like robots and the process is expected to magically take care of everything! As we all know that with more power comes more responsibility. In Agile, every team member is more empowered to do his/her job but needs to be more responsible and committed for the actual outcome.
Traditionally, software project execution had always been a lesser discussed topic than Project planning. While planning is essential for Project Success, the ground realities of software development seldom matches the "ideal" world documented in the Project Plans. Too much of upfront planning and processes often failed to yield the expected ROI in the dynamic world of modern software development. In my experience, most of the high level project planning is performed by Senior Management who either do not have a good understanding of the actual complexities of project execution or lack the will and commitment to do so. Unrealistic expectations set during project inception often doom a project to a death march right from the very begining. It also creates lots of stress and demotivation to the development team that has to fight the battle in the trenches. The net result is that development team has no choice but to "mechanically" follow the "process" on a journey to nowhere.
The Agile Manifesto stresses more on the ground realities of Project Execution vs. Planning. Since, actual results are produced by people, agile stresses more on "people" over "process". While processes and tools are an integral component of team collaboration and success, individuals drive success more than the processes and tools do. Prior to agile, the human factor did not get its due recognition. I think most of the traditional processes failed to address the human factor in software development. In my experience, humans do not work very well when asked to work under too many constraints. Too much processes and beaurocracy dilutes individual accountability and responsiveness. The irony is that the many traditional process that were originally designed to help teams succeed, actually turned out to be impediments to real progress.
However, I would also like to caution that Agile in no way advocates "ad hoc" development. It requires more "process maturity" on the team compared to traditional (process heavy) methodologies where people are expected to work like robots and the process is expected to magically take care of everything! As we all know that with more power comes more responsibility. In Agile, every team member is more empowered to do his/her job but needs to be more responsible and committed for the actual outcome.
Subscribe to:
Posts (Atom)