QC people have a special role inthe development process. Part of this role is being involved in differentactivities throughout the entire development process. Starting from the timewhen requirements are gathered, when initial design is made, and until the endof each iteration, the QC people must observe and gather information about thesystem under development. This is crucial to the completeness and correctnessof the QC activity. A QC Engineer can’t be expected to jump into the projectjust before the actual testing starts. She must be aware of the evolution ofthe requirements and the system itself (including the way it is designed andimplemented) in order to create an effective test plan, and build correcttests.

However, at the same time, it iscrucial to maintain the objectivity of the QC people. Since the QC engineer isso involved in the development process, it is easy to forget that if she willbe too close to the developers, the result of the QC process might not reflectthe real quality of the product.

If, for example, something in therequirements is vague, the QC engineer might be tempted to ask the developerfor the “correct interpretation” of this issue. But, it is the QC engineer’srole to verify that the developer’s interpretation of the requirements iscorrect. How can she use the developer’s interpretation to build an objectivetest?

This is a simple example for whatcould happen when QC and developers are too close. Doing extensive testingbased on what the developers gathered from the requirements, is bound to catchonly coding errors. Logical errors in the functionality of the system are mostlikely to be left in the code under these circumstances.

The way to solve this conflict, ishaving great self discipline. QC people should be involved in the development,but they should think twice about whom are they talking to when havingquestions about the requirements of the product. The best person to ask suchquestions is the same person defining the requirements.

Itis important to note that the QC people should not be completely isolated fromthe development team. The QC engineer could benefit a great deal fromdiscussing the structure of the code and the design details with thedevelopers. This kind of discussion might give her ideas for more test cases,for example. The difference between discussing the structure of the code anddiscussing the interpretation of the requirements is that verifying the latteris in fact the purpose of the QC process.

Theodore Ts'o offered an insightful summary of issues affecting future development on the ext3 filesystem, "it is clear that many people feel they have a stake in the future development plans of the ext2/ext3 filesystem, as it [is] one of the most popular and commonly used filesystems, particular amongst the kernel development community. For this reason, the stakes are higher than it would be for other filesystems." He listed the three main concerns for future development as stability, compatibility confusion, and code complexity, "unfortunately, these various concerns were sometimes mixed together in the discussion two months ago, and so it was hard to make progress. Linus's concern seems to have been primarily the first point, with perhaps a minor consideration of the 3rd. Others dwelled very heavily on the second point."

Theodore went on to say, "to address these issues, after discussing the matter amongst ourselves, the ext2/3 developers would like to propose the following path forward." He listed a four step plan beginning with the creation of a new ext4 filesystem registered with the kernel temporarily as 'ext3dev', "this will be explicitly marked as an CONFIG_EXPERIMENTAL filesystem, and will in affect be a 'development fork' of ext3. A similar split of the fs/jbd will be made in order to support 64-bit jbd, which will be used by fs/ext4 and future versions of ocfs2." Theodore explained that new features will go into the ext3dev tree, with only bugfixes making their way back to the stable ext3 tree. He noted that it will remain important that the ext4 code base can mount ext3 filesystems, "this is necessary to ensure a future smooth upgrade path from ext3 to ext4 users." Finally, "probably in 6-9 months when we are satisified with the set of features that have been added to fs/ext4, and confident that the filesystem format has stablized, we will submit a patch which causes the fs/ext4 code to register itself as the ext4 filesystem." He further noted that once ext4 is deemed fully stable, it may completely replace ext3 in the source tree.

A couple of days ago I had thehonor to attend at a lecture given by Jim Coplien about organizationalpatterns. The lecture presented the concept of organizational patterns and gavesome example of such patterns from an upcoming book by Jim Coplien.

One of the patterns presented was“Engage Customers”, which states that the customer needs to be approached bythe development team in order to understand the requirements better. Iimmediately thought of the eXtreme Programming approach in regard to the customer.According to XP the customer should be part of the development team. He shouldbe available on the development site, even in the same room, and constantlyanswer the developers questions and give them feedback about how thedevelopment is progressing towards the product he needs. I couldn’t helpwondering whether the pattern presented by Jim Coplien is indeed equivalent tothe XP implementation…

As it happens, the answer (in myopinion) was not late to come in the form of another pattern: “Fire Walls”. Theconcept in the basis of this pattern is that the developer should be shieldedfrom most external roles during development. The rational is that the developershould be disturbed as seldom as possible, since she is the one playing themost important role in the development process.

It is easy to see how the conceptof “Fire Walls” (assuming you agree with it) contradicts the notion of anon-site-customer who sits in the same room with the developers. XP merely tooka basically good idea (engaging customers) and put it under an extremeinterpretation. As in many other cases, taking a practice to its extreme couldeasily lead to the opposite results (or at least it has a price in regard tosome other good practice). In this case, bringing the customer to thedevelopers sanctuary could easily lead to a situation where the productivity ofthe developers is damaged, due to the constant involvement of an outsider.

The lesson, in my opinion, issimple: good practices should work together and not against each other. Youcan’t just “turn all the knobs to maximum” and still hope to get the benefit ofall the good practices you know. Noise is bound to be introduced wheneverything is being done the extreme way.

Justto make it clear… the views expressed above in regard to XP vs. theorganizational patterns are merely my thought and they were not part of thelecture ;)

We are looking for Team Members for the DNN Wiki Module Project. If you have the following let us know!

1. C# development experience
2. DNN Module Development experience.
3. Ready to get down and dirty with Wiki!

Send me an email at chris.hammond dotnetnuke.com with your qualifications and DNN Experience.

• Pharmaceutical Research and Manufacturers of America, Japan Division
  This all-Japanese site is slated for a mild content reorganization and 'engine swap', moving it to the ExpressionEngine platform for content management.
• Christ Memorial Church of Holland, MI
  This project - complete site makeover, also moving to the ExpressionEngine platform - is currently under development.
• Haven Church of Kalamazoo, MI
  Haven Church has engaged Boyink Interactive to perform some research and internet ministry strategy development to define goals for their presence on the web.

In the article The Two Sides of a Document we discussed the importance not interfering with the creating mode during the development process. We recognized the fact that in a highly rigid process which involves many documentation to be written during the development, the creative flow is constantly interrupted. We also mentioned Mind Maps as a possible solution for keeping track of ideas and insights throughout the development process (which enables us to maintain a review process along the way), while reducing the overhead of writing a “real document”.

Object Oriented Analysis and Design is one of the most creative activities in the development process. Thus, we might benefit from reducing the overhead of using conventional tools when performing this activity.

Since Mind Mapping is a great technique for open thinking (it doesn’t tie you to a rigid solution or way of thinking) and it promotes both creativity and flexibility, it is a great tool for an activity such as OOAD. This technique is very lightweight. It imposes almost no overhead. This means you can easily capture ideas, manipulate them and refactor the way you perceive the system without having to do a lot of work. This by itself is an enormous advantage, since it enables you to flow. It does not hold you back in the thinking process. You do not have to stop thinking while changing your model.

Flow and flexibility are crucial in the initial stages of creating the design. At these stages, you frequently change aspects of your design. You might even change the way you grasp the entire system. If you are forced to spend time on technicalities (such as changing a UML model) you stop yourself from thinking. Every new idea you have might introduce quite some overhead on these technical details.

A suggested implementation of OOAD using Mind Mapping was recently published at SharpDevelopment.com. This article is the first one in a series of articles exploring Mind Mapping as a tool for various software development activities. The article demonstrate how this technique could be using for OOAD. It also contains a real-world example of analysis done using Mind Mapping.

During the development of a software product we all make numerous design decisions. Some decisions are done in early stages of development, while analyzing the requirements and gathering the overall architecture of the product. Other design decisions are done during the lower-level design. Finally, even during the implementation of the a single component, we are often in position to weight several design options against each other.

In the following discussion we will examine one of the common design aspects, which is the source of numerous design dilemmas: should we design the product such that it will be ready for a future change (in the requirements, in technology etc.), or should we settle for a straight forward implementation? When is our product “sufficiently-designed” and when is it “over-designed”? In other words, how can we find the golden path when it comes to designing a software system to be ready for future changes?

Read the article...