Step 1 - You need source control

Starting or reorganizing a software development group from the ground up presents many challenges. Creating a group identity, staffing, infrastructure and operations will take endless amounts of time, consideration and then reconsideration. There are usually multiple solutions to any of these high level points and the hundreds of smaller tasks that make them up. The manager's experience and comfort with his/her past implementations should combine with the uniqueness of the current domain to guide them to the correct group implementation on which the development culture will be grown. With so many choices to make and avenues to be investigated any cut and dry decision saves valuable time and allows the manager to focus on the trickier implementation tasks. Source control is one of these slam dunk decisions.

As we all know a source control system could be argued to the top of the engineering necessity check list. It is not a nice to have but a must have. No serious development company can operate without a solution. "Which system is right for us?" becomes the question. A product that is scalable and offers flexibility must also be easy to use and solve the problems that we all found when we were using Source Safe. Finally, how much should be paid and how much time devoted to administration? I have found that the near perfect solution to all of these questions to be Subversion.

Subversion (SVN) started in '99, and was intended to replace CVS with an open source solution. It will secure your source code as well as your documentation. It supports branching and provides documentation on various implementation schemes that you can peruse prior to implementing a process. The latest version makes the merge process simpler and will help alleviate errors. Along with all of these features, SVN can be used via the command line, web or a desktop Explorer add-in "Tortoise". Finally, SVN integrates well with other bug tracking/wiki solutions like trac and jira.

So if you are looking to replace an existing source control system or implement a new one, I recommend that you check out SVN. You'll save money & time and get a robust solution that is easy to use.

Best of luck,
Brian

The QA Trap - part I

Having Quality Assurance resources is truly beneficial to any company producing software. This applies to whether it will be consumed by internal or external customers. Your department’s credibility depends on delivering high quality products. You must keep in mind that your products must meet basic performance expectations, adhere to the original user requirements, not break any other installations or corrupt data, as well as many other criteria that the user will run into through heavy application use over time. Therefore, having an experienced team that is adept at teasing out even the hard to find issues is a serious benefit.


So how can such a noble endeavor go wrong? There are lots of reasons, but the most challenging to control is the effect that occurs when the QA department sits in the shadow of Development.


There is sometime a perception that the QA engineers are inferior technically to the developers. If this is the understanding in your organization, then QA will occupy a lesser position in the social structure. This mindset sets up an environment where development has a greater influence over the solitary QA engineer than is advisable. Take as an example, the constant task of adding new features to your product. Any product in active development (not in maintenance) is continually growing and evolving to attract and keep customers. Too many times however QA is kept out of the process until the last minute for a cursory check. If the environment is 'development-on top', QA will ask look to the engineers for explanations of how the new features are supposed to operate. This puts too much power in the hands of the developer.

The reason for establishing a separate QA resource is to create an environment where an unbiased party can operate the product as a normal user. If they have to take guidance from development as to how or what to test or if behavior is as expected you may as well reassign the resource and let the development team do the testing.

Developers for the most part want to deliver quality products, but they think like developers. QA is there to think like users - smart ones and not so smart ones. Many times QA will create defect tickets to the annoyance of development. You'll hear "what are they doing, no one would do that", "that’s not a bug" and things of this nature. If development can squash a bug or "advise" QA that their test is invalid or even influence the test plans that they create, the product will not be thoroughly tested.

In a subsequent entry to this monograph I'll make QA recommendations.