Article Discussion: Hi 5: Part 4

If you have any questions or comments on this article then please post them here.

This forum post relates to this article

Hi Benos,
Thanks for a series of good articles.

Here are few questions, I will appreciate if you take your time to post the answers.

[01]
What you think about "Pair Programming Concept" in Web Development Cycle.

[02]
Do You think that Collective Code Ownership encourages everyone to contribute new ideas (is it really need in low-tech, like web development cycle?) to all segments of the web development project.

[03]
What should be the Optimal way to keep the syatem metaphore in a large web development process.

Thank You.

Hi IAhmed,

In regards to your questions regarding aspects of the web development cycle in relation to concepts found in XP and others:

[01]
For the experience web developers, I believe that pair programming in a web development cycle is a great concept. This decision would need to made in the planning phase.

Sure, pair programming, where two programmers work together can have a high initial cost, due to two people working at the same time(i.e. one programming and the other one planning the next move), but the quaility will be high. Hence, there will be lower long term costs due to maintance costs for lower quaility results.

On the same token if the budget is low, then the team would need to consider whether it is feasible to involve another programmer.

If the web development team is new, the pair programming concept will be difficult and time and money will be lost. As the development team grows in experience, the concept will be easier the work with.

So, the use of pair programming really depends on both the experience of the programmers and the project budget.
[/01]
[02]
Collective Code Ownership should encourage a team to every member to contribute. Although, it would not be needed in the web development cycle, unless it was a large scale project where there are multiple programmers in each section or module.

Personally, I feel that each programmer has his or her own "tools of the trade" or experience in a particular problem that may arise in th edevelopment process. These problems should be discussed amongst team members so that all of the programmers can learn from this problem and any others that may arise from other programmers needing help.

If the team times the time to document the problems faced as well as the bugs found, then the CCO can be benefical and hence will encourage member to contribute ideas. Although CCO is not really a requirement for the web development cycle as long as everything iw well documented so that if the problem/bug occurs in the future a swift action can performed.

Without CCO involved in the web development cycle, the can problem is discussed amongst members, then each member can learn from the experience and new ideas may arise.

So, in answer of your question. CCO may encourage everyone to contribute ideas in all segments, but it isn't needed if the team discusses problems together resulting in an optimised system.
[/02]
[03]
In every large scale project, the system architechure is best described using top-down decompostion. The development team may employee a system architect to handle the desciption of the system, i.e. the system metaphore or the team can produce the system metaphore in the first phase of the cycle.

I find the using diagrams as well as text to illustrate how the system functions from the topmost level and gradually moving down lower levels is the best way to keep the system metaphore.
[/03]

If you have any further questions, I look forward to hearing from you I appreachiate your questions and I hope that my series of articles thus far sparks up a few more. Take care and I hope I've answered you question for you.

Thank You very Much For Your Time and Great Answer

Any time IAhmed ... If you have any other questions let us know. I enjoy it when someone has questions about my articles. Take care.