About Us

AboutUsTorq Software is a small software development company located north of Perth, Western Australia. We focus on developing and maintaining software products rather than adhoc projects and prefer to work closely with business partners on a long term basis. Our Clients are often also our business partners. We have expertise in a variety of technologies and have developed and maintain a number of product and product suites. The following category list provides more information about us as a company, how we develop software and do business.

Automated Testing

AutomatedTestingOur preference is to automate the testing of all software products we develop where practical. This allows regression tests to be performed whenever changes are made to ensure the existing software functionality hasn't been adversely affected. We use Nunit for the test automation of .NET programs and an internally developed test runner for our C/C++ programs.

The following screen shot shows an example software development project in Microsoft's Visual Studio. We us an addin called Resharper to assist in developing C# programs and that includes an inbuilt test runner. This screen shots shows an automated run of all of the automated tests for an example development project. The example shows a successful test run where all of the automated tests passed. If there was a test failure it would appear as a red symbol highlighting a test failure.

We group the automated tests into four categories:

  • In Memory Interaction Only
  • Interacts with the Local Disk
  • Interacts with the Local Network
  • Long Running

These categories are typically indicative of how long it takes to run an automated test. The memory interaction test category can be viewed as unit tests and what are run regularly by a developer as they are developing. The other test categories can be viewed as integration tests. Rather than use the unit test/integration test terminology we have chosen to treat all of these as automated tests and put them into categories that are indicative of how long they take to run. Our continuous integration system then runs these automated tests whenever there is a source code changed detected in the revision control system.


Continuous Integration

ContinuousIntegrationWe use continuous integration as part of the software development and maintenance workflow. A continuous integration server monitors the revision control database waiting for developers to make changes. As changes are detected, the build server gets a copy of the changes and then automatically builds and tests all of the software products that have been changed. Our build server also automatically builds an installable release of the software products we maintain.

This provides immediate feedback to the development team as to the health of the development system for the software products we maintain. If a developer makes a change that say works fine in the application they are working but introduces a fault in another application, the team will be informed soon after a check-in occurs.

We use the Cruise Control.NET software made available by the nice people at Thoughtworks on our build server. Each developer runs a small Cruise Control application in their Windows tray that provides notifications of build status changes. In addition there is a web based control panel for viewing the status of the build servers and performing actions such as forcing a build to occur.


Domain Driven Design

ResundBridgeDomain Driven Design (also known as DDD) is an approach to the design of software where domain models are used to drive the design process and allow software developers and business experts to communicate more effectively. A dictionary definition of domain is: a realm or range of personal knowledge, responsibility, etc. In the context of DDD a domain is an area of knowledge or expertise that software is being developed to work in. So if you are a business owner that wishes to automate some aspect of your business, the domain is the operation of your business. Put in a different way, the domain in DDD refers to the area of expertise that end users of the software being developed understand and work in.

A domain model is a conceptual model of the area of expertise or organizational system the software is being developed for. For a business owner, this could be a conceptual model of their business or a part of their business operations. It can take the form of a document, a series of diagrams, some scratchings on a whiteboard or a more formal definition in a modeling language such as UML. All people have domain models in their head for a whole bunch of different knowledge areas and expertise.

The power of Domain Driven Design comes from the alignment of the domain models in the heads of the various stakeholders of a software product or project. Aligning how the software developers, business owner and users of the software perceive and think of a system being automated by software allows the entire development and maintenance process to proceed more quickly and better equipped to satisfy the needs of everyone involved.

The language used when the different software product stake holders communicate subtley, but greatly, affects their interactions. The term ubiquitous language is used in DDD to describe the use of a consistent domain language between all of the stakeholders, software developers, end users, business management, business experts etc. Torq Software uses Domain Driven Design techniques in the development of the software products have created and maintain. An example of the use of DDD and ubiquitous language can be found in the Iris Debt Collection System design.


The concept of a debt collection Job was the central theme to the business operation, so this is the term we used in the software source code to label that software class. Similarly the terms Client, Agent, Agency, Client Contact and Tow Company were all in use by the debt collection industry the business deals with. These are directly used in the Iris product's source code which allows the software developers to associate software concepts with business concepts. It allows the developers to more effectively communicate with the users of the software. So rather than have a software jargon, we have a shared jargon that straddles the software development process and the debt collection domain (for this case).

An interesting variation in the DDD approach used was the naming of the Coordinator concept. The business didn't actually have an explicit name for the office staff that worked on debt collection jobs but were not actually field agents. We found that this role in the debt collection workflow was important enough to model it in software. The term Coordinator was used as the person involved coordinates the activities on large numbers of jobs. This isn't quite the text book approach of using language that is already in use in the business domain, but the additional term worked well. It is now in common use within the business at it puts a common sense label on a conceptual role they were already familiar with. We typically follow an approach such as Domain Driven Design because it provides significant value to the development process but aren't averse to tailoring the approach to different scenarios.

Some excellent books describing the Domain Driven Design approach are available:


Applying Domain-Driven Design and Patterns: With Examples in C# and .NET

ISBN: 0321268202
ISBN-13: 9780321268204

See Jimmy Nilsson's blog as well.

Domain-Driven Design: Tackling Complexity in the Heart of Software

ISBN: 0321125215
ISBN-13: 9780321125217


Daily Reports

DailyReportsAn interesting aspect of our standard software development practices is that we produce daily reports for all of our major Clients and Business Partners. Other software developers may query the benefit of this in that it takes time out of the day to type in what the developers have been working on. We have found that it serves us well in that:

  • It keeps the Client up to date with what is going on
  • It is a record of the development work performed over time
  • Developers can easily recall what they did or how they did some task even years after the actual work day
  • By having to write down what work tasks they performed during the day, it provides a useful internal feedback loop for the actual developer writing the daily report
  • It provides a useful communication mechanism for clients or developers that are separated by multiple timezones

The last benefit is what started us out performing this practice. We started doing software development work for a Client in Pensacola, Florida which is literally on the other side of the earth to Perth, Australia. We needed a mechanism to provide visibility to the Client as to why certain tasks took a long time and other tasks were done really quickly. Its the nature of Software Development that once you get into a particular functional area, its true nature is revealed. If Software Development is totally deterministic then "you're doing it wrong". Put another way, if software development was totally deterministic then its likely you can automate the actions being performed and hence put yourself out of a job.

The practice of creating daily reports on the software development work we perform works well for us. It has increased the visibility of our work when the client is physically removed from our location and provides a record of our work.


Feature Driven Development

FeatureDrivenDevelopmentA key process used at Torq Software is Feature Driven Development or FDD for short. It is an Agile method but one where there is actually an explicit up front design step called "Develop Overall Model". We absolutely recognize that design activities will continue to be performed in every development iteration but feel there is a need for an initial design stage where the "shape" of the system or product architecture is established. The FDD practices we use fit in well with our use of Scrum as a software development management process and Domain Driven Design as a design approach.