TFS

I've been re-watching many of the sessions I watched while at Tech-Ed 2008 in Barcelona. I've also been watching some of the sessions that I hadn't been able to attend. One of them being how Team Foundation Server is being used at Microsoft. A couple of things gets under my skin in terms of why can they do it and I can't.

Thousands of users, terabytes of data. OMG! If its good enough for them surely its good enough for us! Is it overkill for a small software development team? Is there a substantial cost of ownership? According to the session it can support Agile methodologies niucely. Generally i got a lot of agile vibes from Tech-Ed. Now if thats a marketing strategy or if its for real who knows. But they have me convinced. Anyway, I think i'd like giving it another twirl some time. There's just no time is there...

XP

I've finally got my hands on Extreme Programming Explained: Embrace Change (2nd Edition) . I'm about half was through so far, but I must admit I was hoping for more detail on some of the practices. I've generally found that http://www.extremeprogramming.org/ had a very good amount of information about XP, and presented in a very nice manner. I was hoping the book would expand on this. I do wonder if the first edition of the book has the extra info I would like, but I don't think I'm going to get it.

My next buy will probably be the SCRUM book. I've heard good stuff about SCRUM, and watched a few sessions at Tech-Ed on it. I think it'll do our organisation good.

Release Processes

At various points in the software development lifecycle it is deemed necessary to release a version of software. This may be for testing within the organization or outside of it (internal release or external release), or because the software is ready (final release). Large intervals between releases will result in less time used up for releases and more time for development. The release process should be as automated as possible to reduce this lost time. Smaller intervals between releases will result in better communication and feedback between developers and the release stakeholders. A balance between these two should be reached and an appropriate release interval should be agreed on for any given project. This document presents a set of requirements that must be met by a release and describes a release process that is intended to meet the requirements in conjunction with a versioning policy and a CM tool.

Release Requirements

Following is a list of requirements that must be met by each release.

1. Each release must be uniquely and easily identifiable with respect to older and future releases.
2. All sources (including code, resources, external libraries, etc) that go into a release are safely marked and stored, and the release can be reproduced from them. This is so that both a) when bugs arise, they may be investigated and solved with respect o the code that the bug was discovered in and b) releases may be made based on old versions of the software.
3. The release that (or at the least, the source of) a released artefact can be easily identified. This is so that both mismatches that may accidental occur on a target system may be identified and to enable the correct version of software to be examined and debugged when investigating a bug.
4. The changes that have been made since the last release can be identified. This is to help testers identify the areas of the system where testing should have a higher priority.
5. Future releases can be made based on old release with minor changes only.

In order to achieve these requirements the following needs emerge.

1. A Software Configuration Management (or Source Control) tool and usage guidelines to manage changing source code.
2. A Versioning Policy for the software produced.
3. A process for releasing software that relates the CM tool, the versioning policy and the steps needed to perform a build so that the release may meet the above requirements.

Release Process

The following diagram shows a release process aimed at meeting the previous requirements in conjunction with a CM tool and versioning policy. Each step in the process is described next.
Following are descriptions of each of the stages in the release process.

Retrieve Build Source

All the files that are needed in order to perform a build must be retried to insure that they are all up to date.

Build Code

Build all code that needs building. If the code can’t be build, the release process cannot continue. If the release is intended for eventual use outside the organization, then it can be build without debug information (release build) and with optimizations enabled. If the release is intended for testing within the organization, then it may be build with debug information to assist debugging and testing.

Compile Release Notes

Use comments from the CM tool to build a set of release notes that describe what has changed since the last release. These notes are intended for use buy testers to identify what areas of the software must have higher priority in terms of testing than others. These notes may also eventually be used to inform clients of changes made since the last version they have.

Move compiled artefacts to setup source folder

It is assumed that the setup project for takes its source folder (or folders). The compiled output must be moved into the source folder for the setup project.

Configure

Any configuration in terms of tracing etc must be performed here. For example , if the release if intended for eventual use outside the organization, then tracing must be removed or lowered so that it does not cause problems with disk usage etc on client machines.

Obfuscate

If the release is intended for eventual use outside the operation it should be obfuscated to prevent it being disassembled.

Build Setup

The setup project must be built. The output of this build will eventually be released.

Mark/ Tag/ Backup Source

Mark, tag, or backup (according to CM tool) the source that was used to produce the build.

Increase Versions

Increase versions of artifacts and the setup project in accordance with the versioning policy being used.

Commit New Versions

Commit new versions to the CM tool to prevent any future versions having the same version number as the one that will be released.

Release

Release the build setup by placing it in a known location with its version clearly visible and inform all the relevant people of the new release location.

Issue Tracking

Issue tracking systems can help to:
• Better facilitate communication between people working on a project.
• Provide a history of issues which have been encountered in a project and their progression and resolution in order to better support the system.
• Support a shorter product release cycle and manage interaction between development and testing (or generally Quality Assurance)
• Provide a snapshot into the issues being worked on in order to identify bottlenecks in the project.

I've been looking into issue tracking systems lately, BugZilla being the most bell known. I've looked at commercial ones like Jira and Gemini. I also read this very interesting article. All and all I've concluded on a simple tracking system called BugTracker.NET. It doesn't do half as much as most systems out there, but it does what i want it to do in the simplest way possible. Remember: Simple is your friend (as a wise senior software engineer in my old company used to tell me). The most important thing in the whole issue tracking ordeal I've decided is not the software you use, but the workflow, the roles of the users and the responsibilities they each have with respect to the issues. To that end, I've written up the following to describe these.

Primarily the attributes that are associated with issues are described. Next the workflow of an issue is presented with a description of each status the issue can be in. A description of the roles of users of the system is then presented and finally the responsibilities of each role with respect to what state an issue is in and the attributes is presented.

Issue Attributes

Issues are expected to have the following attributes for the purpose of capturing its state and history.

Project

This is the project that the issue relates to. Different people will have different roles with respect to issues of different projects.

Status

The status of an issue relates to where it is and who is responsible for it. The statuses of an issue are describes in the “Issue Workflow” section.

Category

The category of an issue reflects the work that must be performed on it. Examples of category values are bug, enhancement, new feature, client issue, documentation. It is possible to change the category of an issue as more information is found out about it, but appropriate comments must be added at each change.

Assigned To

This is the person that is in charge of dealing with the issue.

Priority

Priority is an indication to the person that is assigned to the issue regarding how he must tread the issue with respect to other issues assigned to them.

Resolution

This is the resolution given to an issue by the person in charge of the issue. Not all resolutions apply to all categories of issues. For example a bug may be fixed, unreproducible or not fixed. A client issue will be resolved and documentation will be drafted, reviewed or completed.

Comments

This is possible the most important attribute of the issue. It must contain all the information about the issue added by the various people that have been assigned to the issue. It must contain fault reproduction techniques as well as verification techniques for the issue if it is a bug, logs and other information such as resolution details if it relate to a client issue and more.

Issue Workflow

The diagram bellow shows the states that an issue within the issue tracking system takes.

New

When an issue is entered into the system, the default state is ‘New’. From this state an issue can go to either support, if it relates to a problem a client is having or to development if it is a bug.

Support

When an issue is taken by support, then support staff will be in contact with a client collection information about an issue and resolving the issue when the can. If they manage to resolve an issue it is passed to Quality Assurance to verify that the resolution is satisfactory and in line with the project quality plan. If the issue cannot be resolved by support it is passed to development with all the information that has been collected.

Development

When an issue is taken by development, then a developer will be put in charge of examining it and verifying if it is a bug and if so fixing it. If the developer needs more information in order to deal with the issue, they must add what they want in the comments and pass the issue back to support. Once a developer has fixed an issue then they move it over to Quality Assurance to verify that the issue had been dealt with (often this will be a case of testing).

Quality Assurance

When an issue is taken by quality assurance, then a QA staff member will be in charge of verifying that the issue has been satisfactorily resolved. This will often require that a bug fix be tested, but may also require documentation to verified or accessed. If the QA member is satisfied with the resolution, then they will move the issue to a closed state. If they are not satisfied they will move it to development or support depending on where it came from.

Closed

A closed issue is considered complete and is kept in the system for reference purposes and for helping future issues which may possible be similar to be resolved. In the event that after an issue is closed, it is discovered that the resolution was insufficient, then it is set to the reopened state with a comment on why it has been reopened.

Re Opened

An issue in the re opened state similar to an issue in the new state in that it must be assigned to either development of support for it to progress.

Roles

Users of the system can be grouped into the following groups or roles. A physical person may have more than one of the following roles in a given project and may have different roles in different projects. It is important for a user to know what their role is and what the responsibilities of these roles are.

Users

All users of the system may add issues to the system. When a new issue is added to the system the user has the following responsibilities:
1. Set the project of the issue
2. Set the Category of the issue if it is known
a. If the category is a bug, the user must add a reproduction procedure.
3. Set the status of the issue to ‘New’
4. Set a description of the issue
5. Set comments describing the issue
Users may also move an issue from closed to re-opened, in which case they must provide a comment describing why they have done so.

Development Managers

Development managers are in charge of the developers working on a project in that they are aware of the areas individual developers have worked on and have expertise in. Their responsibilities are
1. To check the tracking system for new or reopened issues that relate to development and move them to development.
2. Review all unassigned issues in development and assign an appropriate developer to work on each of them.
3. Set the priority of assigned issues where they have not been set
4. In cases where they can, they must add comments relating to how an issue must be resolved or where a developer must start looking in order to resolve an issue thus giving the developer a jump start in solving the issue.

Developers

Developers are in charge of the issues assigned to them. Developers must work on issues based on the priorities given to them.
When developers resolve an issue they must:
1. Set the resolution of the issue
2. Add a comment describing the resolution
3. If issue is a bug, they must
a. Add a verification method to the comments instructing QA how they should go about verifying the fix.
b. State the version in which the fix will be available
4. Un-assign themselves from the issue and
5. Move the issue to Quality Assurance.
When a developer needs more information from support they must:
1. Add a comment stating what is needed and how it may be obtained
2. Un-assign themselves from the issue and
3. Move the issue to Support

Support Managers

Support managers are in charge of support staff in that they know what each staff member has expertise in supporting. Their responsibilities are:
1. To check the tracking system for new or reopened issues that relates to support and move them to support.
2. Review all unassigned issues in support and assign an appropriate support staff member to work on each of them.
3. Set the priority of assigned issues where they have not been set
4. In cases where they can, they must add comments relating to how an issue must be resolved or how a support staff member must proceed in order to resolve an issue thus helping the support member.

Support Staff

Support staff members are in charge of issues assigned to them. They must work on issues based on the priorities given to them.
When a support staff, member resolves an issue they must:
1. Set the resolution of the issue
2. Add a comment describing the resolution
3. Un-assign themselves from the issue and
4. Move the issue to Quality Assurance.
When a support member cannot resolve an issue or has attained the information requested by development they must
1. Add a comment with all attained information regarding the issue
2. Add a fault reproduction technique if the issue is a bug.
3. Un-assign themselves from the issue and
4. Move the issue to Development

Quality Assurance Managers

Quality assurance managers are in charge of quality assurance staff in that they know what each staff member has expertise in supporting. Their responsibilities are:
1. Review all unassigned issues in quality assurance and assign an appropriate quality assurance staff member to work on each of them.

Quality Assurance Staff

Quality assurance staffs are in charge of issues assigned to them. They are responsible for verifying that the resolution of an issue is in line with the project quality plan. This may involve testing bug fixes, reviewing documents checking comments added to the issue as sufficient.
When an issue has been verified the quality assurance staff member must:
1. Add a comment describing the verification performed
2. Un-assign themselves from the issue.
3. Move the issue to closed state.
If the quality assurance staff member decides that the resolution does not meet quality standard (e.g. test fails, documentation is incomplete, Unit testing does not cover all the new code) they must
1. Add a comment describing why resolution does not meet quality standards
2. Un-assign themselves from the issue
3. Move the issue to support of development according to who put it up for quality assurance.

Oranizational Processes and Standards

I've tried to get the processes and standards i put together into a diagram to better visualize them and the relationships between them:


I've also written little overviews of each element:

Development Process

The development process is that that is used in order to stream line and organize the development effort from the start of a project till the end. Its goal is to help developers repeatedly produce quality software that meets user expectations. It will be made up of a number or other processes, practices and standards which may consist of traditional waterfall approach methods such as a sequence of analysis, requirements engineering, UML designs etc or it may use agile methods such as user stories, pair programming and continuous integration among others.

Coding Standards

Coding standards are qualities of code that must be adhered to by developers. They may include the following:
• What are, how and where to use Assertions
• What is, how and where to use Tracing
• Where to catch and throw Exceptions
• How much and what code should contain comments.
• How to deal with Compiler Warning
• Code metrics: what, how and why
• Globalizing code
• Naming conventions for variables, classes, operations etc.
Coding standard relate to Quality Management in that they define attributes of code that are believe to give it quality value.

Documentation

Documentation should be performed during the development process to give a high level explanation of what the software is meant to do and how it does it. Standards relating to what should be documented and how it should be documented must be defined and documentation should adhere to these. Documentation should be drafted, reviewed and published according to the organizations Document Management processes.

Document Management

Document management defines how documents should be created, reviewed, published, consumed and disposed. It usually included a document workflow and a system for storing and searching for documents.

Peer Review Process

Peer reviews are a quality control process that aim to informally check that code and document standards are being maintained. It involved a developer’s code and documentation being reviewed by a peer. This activity will also encourage better communication, team working and sharing of ideas and technical expertise between peers.

Work Logging

Work logging is the informal practice of developers logging the work they have done, issues they have encountered, solutions they have found and work they must do in order to help them deal with a faster pace of development, documentation and memory loss.

Configuration Management/ Source Control

These are two interrelated issues. Source Control involve being able to keep all code and resources that make up a project in a common location accessible to all developers. It enables many developers to work on the same source using either an optimistic or pessimistic strategy. Source control also involves keeping a history of all the changes made to source code in an efficient manner.
Configuration Management relates to the ability of identifying various versions of the software which has been released to customers and managing them with respect to future versions. Usually a source control tool is used to enable configuration management.

Unit Testing

Unit testing involves writing test fixtures side by side with code being developed. This way as code is changed, if a change breaks existing code it is detected immediately when tests are run. Unit testing aims at having a high code coverage meaning that when tests are run a high percentage of code has been executed. This is something that is very difficult to achieve with manual testing. Manual testing should be used on main use cases and to identify usability and business issues on a project level.

Continuous Integration

Continuous Integration (CI) aims at identifying issues caused when many developers working on the same project work with slightly different versions of the source code. When it comes to integrating, issues that are timely to fix usually occur. Continuous integration involves continuously integrating code, and immediately identifying such issues. A CI server is usually set up to monitor for changes in source code and given various triggers perform a build of the code. It will usually also run unit tests and inform the various stakeholders on the results.

Release Process

Identifying which version of code has gone in which release given for testing or to a client is important for both development and support. A release process is aimed at enabling this. Usually it involves giving the released software a version based on the versioning strategy and tagging a particular version of the code in the source control tool. The release process should be the process by which software is released for quality control via the Issue tracking system so that each issue in the issue tracking system can be pinned to a particular version of software.

Versioning Policy

Versioning software is not a trivial task. A policy must be decided where by the build, release, minor and major version of the software carry some form or meaning, and so that future releases can be made base on past versions. For example if version 1.0.0.0 is release to clients followed by version 1.0.0.1. Then if some clients require some of the new features in 1.0.0.1 but not all of them, then there is no version available to cover the fact that this new version is in between version 1.0.0.0 and version 1.0.0.1. The versioning policy must take this into account.

Issue/ Work Tracking Process

The issue tracking process is a particularly important one. It brings the whole of the organization together. It involves a workflow for issues that go through the various areas of the company (e.g. support, development and quality assurance).

Process Reviews

The various processes within the organization are there to assist developers in developing quality software and meeting business needs. They are not there to restrict them and stagger their creativity. As such each process should be reviewed and refined to the needs of the developers working within a project, during the course of the project and from project to project. This involves various reviews of the processes during the course of the projects and between them.

ToDo

After quite a while, and as a result of a heart to heart talk with our boss, I've been given the feeling that there will be an honest effort to develop some structure and define some development and quality standards and procedure within the company. He's asked me to make a first step in defining these in the form a documents and has promised to support and back them up.

To that extent I need to make a ToDo list of the areas I must document. Needless to say that these documents will be but a first draft, and will be subject to refactoring as they are used.

I'll changing the list ad adding / editing stuff with time to reflect my changing ideas and perceived requirements.

The List:

• Processes
• Configuration Management/SourceControl/Subversion Usage
• Continious Intergration (Goal of, Processes and Usage)/ Build Process
  
• Release Process
• Versioning Policy
  
• Issue Tracking Workflow (Must also select and set up a tool to support this) (See Issue Tracking & Bug Tracking)
• Document Management Process
• Deployment
• Pear Reviews
• Work Logging
• Process reviews (I've read Martin Fowlers The New Methodology Essay which talks about the motivation behind agile software development. He talks about the need for processes used in development to be self adaptive which I think is imperative to them being adopted,to them surviving the test of time with respect to their usefulness and to their improvement over time. He suggests this is possible via a process review process)
  
• Standards
• Documentation Standards (Architecture, Design & Implementation)
• Obfuscation
• Project Deliverables (e.g. Code, Unit Tests, Documentation)
• Coding Standards
  • Assertions
  • Tracing
  • Exceptions
  • Code Documentation
  • Warnings
  • Code Metrics
  • Globalization
  • Naming Conventions
    
  
  

Using Subversion

As far as source control is concerned I've decided to go for Subversion (SVN) using the TortoiseSVN client. I've been using this combination for a while now and through my experiences and articles I have read, I've come to believe it is one of the best source control systems out there despite it's freeness. I believe that commercial system offer more in terms of integrating source control with other systems such as the IDE, an issue tracking system, ect. etc., but no more in terms of a source control system. It's easy to use but behind the childlike interface of Tortoise is the power of a source control system that successes CVS which has been used in the majority of open source projects out there and as such is an indication of its ability to enable smooth collaboration between a development team. This is in my mind the primary goal of such a system.

The structure of the repository I'm going for is as follows:

• Trunk
  • Tools
  • Library
  • Source
    
• Tags
  • Builds
  • Releases
  • Other
    
• Branches
  • Tasks
  • Personal
  • Other

Each of these folders are described bellow:

Trunk

This is where all artefacts that are related to the project go.

Tools

Tools used in the build process of the project are stored here. Examples may include assembly merging tools (ILMerge), obfuscation tools, compilers, unit testing tools, etc.

Library

All externally compiled assemblies should be placed in an appropriate folder inside the library folder.
Additionally, svn-external projects/ libraries should be placed her. However, care should be taken with respect to Tags. If the SVN-Externs points to the head of a Trunk, then when Tagging, no information is stored with respect to which revision of the trunk was in use at the time. For this reason, when it becomes important for tags to be exact (for example for the purpose of recreating a build), svn-externs should be made to point to either a Tag or a specific revision. When this is the case, care should be taken to update this when changes are made to the external repository.

Source

All artefacts that are compiled or in some way make up the release should be placed here. Solution projects should be nested inside the solution folder. Each business project should ideally be made up of only one solution file. External assemblies/ Libraries/ Library projects should be referenced from the Library Folder. Setup projects should be in a folder of their own and the source files for the setup project should be taken from a source folder insider the setup project folder. Finally the source route should contain a batch file of something of that sort that generates a release. The hows and whys of this will be covered in a released post.
An example structure for the source folder is as follows:

• Source
  • Solution
    • projectA
    • projectB
  • SetupProject
    • SourceFiles
    • SupportFiles
  • build.bat

Tags

This is where Tags (snapshots of) the Trunk are kept to represent the state of the trunk at a particular moment of interest. Care should be taken not to commit changes made accidentally (and changes should not be made purposefully) to Tags. (Because SVN treats Tags and Branches in the same way, it allows this).

Builds

This is where tags of builds are kept. These are generally automatically created by the CI server.

Releases

This is where tags of releases (i.e. versions of the code that have been assigned a specific release version and have been sent for testing of to the client) are kept.

Other

This is where others tags are kept.

Branches

Branches are for copies of the trunk made in order to fulfil a particular task. Branches assist developers in that they allow them to commit unstable and untested code that should not under normal circumstances be committed to the trunk. It is often necessary to do this because a logical task may span over a few days in which case the developer will still want to keep his code in the safety of the repository.
The general purpose of branching is to eventually merge changes back into the trunk. In Subversion, this is often a delicate operation - not as straight forward as one would hope. So far I've found a couple of things that can cause issues when merging. These are generally related to renaming and moving files/ folder on the branch. (Maybe even on the trunk, though I haven't tried this). Thus my recommendation is to avoid these operations on branches.

Tasks

This folder contains branches that are related to a particular task (e.g. 'issue 345' or 'Adding paging to SearchLists'.

Personal

This folders contain branches that are for personal use/experimentation by developers

Other

This folder contains other branches.

Bringing the old to the new

Before I dive into the details of what tools I'll be using and how I'll be using them I thought I should mention another defining factor which will inevitable affect the progression and success of our project. The developers working for my company are split into two teams: the ones developing and maintaining older systems written in Delphi 7 and the ones working on the future systems using .NET and C#. I work as part of the later team and one of the aims of my project is to get the developers in the Delphi team involved and familiarize them with the newer technologies.

This brings me against two to three areas of 'stuff' I have to transfer to the older developers. Primarily, the obvious first is the tools we use. The IDE: Visual Studio and the language C#. I think that will be the easy part. What I’m worried about is the getting them to think in a more object oriented, low coupling and high cohesion way about the software they are writing (not to in any way pass judgment in the software that they are already writing). I just believe that given the tools we use nowadays, we have two options: to either produce the same software faster or produce higher quality software in the same time. My thoughts are skewed towards the later.

Finally I have to introduce them into the processes we use. This I think will the hardest of the three to achieve. The reason is that processes in general stand up to the test of time: meaning that they'll have equivalent processes for working and those will be based on years of experience that I just don't have. And given my lack of experience I have to go by what is being written about with regard to software development processes. I have to understand the state of the art to the extent that I can present it in a comprehensible manor, to back it up when I have to, and genuinely believe in it to the extent that I can convey this belief to others. At the same time I have to draw on their experience and use it to factor and refactor the processes that we use to deliver software of the quality and in the time required by the business.

Software Development Project Management: Take 1

For the sake of documenting some of the processes or set-ups I'm using for the project I'm working on at work (which I will refer to as BS.NET Project), I'm going to try post stuff here to that end.

Primarily what I'm pushing towards is an 'everyone for everything' approach. Not to say that all developers working on the project will be working on all parts of it, but I do want everyone to have a deep enough understanding of the whole project such that at any time they can work on any part of it that is needed.

This is actually quite a tall order in the context of the company that I'm working for. The developers there (and I'm sorry to say both new and old) don't have a strong feeling of 'shared ownership'. I.e. that the code belongs to no-one and everyone at the same time. That is to say that everyone is equally responsible for all the code. Viewing the code as one inseparable unit of ownership and not fragmented parts written and maintained by separate developers. Not to say that any one won't have their area of expertise, but rather that no-one will be confined to their area of expertise and that given the right circumstances, their areas of expertise will grow.

My hope is that I will accomplish this by getting developers to work on many small chunks of the project in parallel as opposed to splitting work into large ones. So, let’s say that tasks A, B, C and D are related, and 1, 2, 3 and 4 are related. Instead of getting one developer to work on ABCD and another on 1234, I’m going to get one to work on AB and one on CD, then the first on 12 and the second on 34. Yes, I appreciate that I’ll be missing out on specialization of labour, and the efficiencies of that, but I believe primarily specialization has the tendency to dumb the mind resulting in potentially good refactoring chances being missed, and secondly, in the long term, this approach will result in greater capacity to maintain code and to avoid resource bottlenecks (i.e. one developer holding up a project because he is over allocated, but no-one else can do his job).

I want to get across the way to prevent code from breaking when someone other than the person who wrote it working on it is unit tests. Getting across the idea that the way to manage changing requirements leading to changes in the code such as not to introduce bugs, isn't by having everyone working on and being responsible for 'their' code, but instead everyone providing tests for code they have written that verifies that that code does what it should. If we can develop a standard for testing various parts of the system, then we can be more confident when it comes to changing them.

On the other hand I do believe that you can over test. That is to say at the end of the day it all boils down to money. There comes a point when the cost (in terms of man-hours) of writing extra tests to iron out another 50 percent of bugs isn't worth it. For example, let’s say with 1 unit of time we can iron out 50% of bugs in a project. And for the sake of argument, let’s say that this is constant. 1unit of time = 50%of bugs, 2 units = 75% of bugs (50% of the 50% left), 3 units = 87.5%, 4units = 93.75... And so on. It should be clear that there comes a point where the absolute number of bugs found isn't work an extra unit of time. The trick is finding where this point is: and in general, it depends on the nature of the system. If it’s a safety critical maybe you need to have a 99.9% bugs eradicated. If it’s a finance system, maybe you can live with 3% bug, and if it’s a game maybe you can do with 8% bugs. In practice I guess you never know how many bugs are in the system, but you do know how much it costs to catch the next bug. From my point of view, I have to guestimate how much our boss is prepared to live with such that he allows a Test Driven Development approach without getting pissed off at the perceived time it is taking (I say perceived, because convincing him the time will be made up when it comes to testing it and supporting it is an equally difficult task)

In order to get everyone working on everything smoothly, I definitely need a source control setup and I've decided to try a continuous integration setup too. I want developers to know how to use the source control tool, and what their responsibilities towards it are. I don't want them to be constrained by it or afraid of it. I want the CI process to run unit tests and to check code coverage. I need to think about configuration management and thus define a build process, a release process and a versioning policy. I would also like to eventually introduce an issue tracking system to better bring together support, development and management but define a process for its use and make sure that users are familiar with it and understand that is isn't an extended e-mail system.

Good Book

I've recently received a book I ordered off Amazon:
"Code Leader: Using People, Tools, and Processes to Build Successful Software" by Patrick Cauldwell.

I'm really enjoying reading it. It's been a while since I've got my hands on a book that talks about the very important non technical aspects of writing software. Forget about cool new technologies, languages and libraries that will do everything for you. That's not what makes successful software. Its people working well together that make good software. The book give practical approaches to implementing Test Driven Development and Continuous Integration, talks about what it means for software to be done, Testing, Source Control and more in a practical context. Everyone more or less knows what has to be in place to deliver good software, but implementing these processes is not always as straight forward as it seems. The book talks about the What (needs to be in place), the Why (it needs to be in place) and the How (to put it in place).

So far i'm very exciting about Continuous Integration and CruiseControl.NET which can be used to set it up. I've been trying to get a setup going myself using Subversion for Source Control, MSBuild and MSTests. The following pages have helped:

http://www.testearly.com/2007/06/20/running-mstest-against-net-20-on-cruisecontrolnet/
http://msdn.microsoft.com/en-us/library/7z253716.aspx
http://paltman.com/2006/12/06/3-steps-to-integrating-cruisecontrol-with-msbuild-mstest-and-code-coverage/

ORM and AI

I was talking to a friend and telling him about this idea that has been playing around in my head. Its still very abstract, but it goes something like this:

You know in AI, how the 1st thing you get given as an example is a route finding program. You start at a point and want to get to an endpoint, and the program will look through the roads trying to find the best way there right?

Well, what I do a lot of at work is we have a few tables e.g. 'Persons', 'Addresses' and 'AddressTypes'. To get a person, we also want to join with Addresses to get his primary address and we want to join with AddressTypes to get the primary address type. So all that sort of goes into one select.

Now, lets say we're looking for contracts. When getting a contract we also want to get the name of the solicitor of the contract (he is a person) and we want to get his primary address and his primary address type. That'll go into one select too. Because that's what relational database are good for: joining tables. I don't really want to get the contract, find the id of the person in charge and then loading him in a second query.

However, when writing code for this, I find myself having to write the fact that persons joins to Addresses and Addresses join to AddressTypes twice. Once for getting persons and once for getting contracts.

So, my idea is: wouldn't it be nice if I could define the database in terms of tables and attributes, and relations for getting from one table to another. The relations should get you from an entry in one table to a single entry in another (for example you'd have to say that you want the address for a person that has the Primary flag set to true). You could say the attributes are the endpoints and the relations are the roads. Then, starting from a table, you could ask for all the attributes you wanted from it or any other table. Then you could have an AI style search though the relations in search for a route of joins that will get you the attributes you needed. Then could dynamically build your query from the route, putting in the joins you need and selecting the values you wanted.