Contact Us


Byte-Vision recognises that each development project is different. It therefore does not believe that a sole methodology should be applied to all projects. The key is to choose the parts of methodologies that are relevant and applicable to the individual project. Saying that, there are some principles, techniques and best practices that Byte-Vision applies to all projects.

Hire The Best People
The number one factor effecting success is the people on the team. Waiting for and hiring the best people is key.

Attack Risk Early
Keep a risk and issues list and manage it daily. Attack risk early. Eliminating risks as early as possible is key to achieving the project deadline.

Manage Project Goals and Requirements
Make sure the project goals and requirements are clear, unambiguous, are agreed with all stakeholders and are measurable .

Test Early and Often
Eliminating slack in a project increases the chances of hitting the deadline. One common culprit for stealing project time are software bugs. The later they are found in the project the more they cost to fix. By testing early, and testing throughly we can reduce the number of bugs that appear later in the project lifecycle.

Automated The Testing
Write automated tests at all levels of the testing, particularly for Unit testing where a large normally a large amount of manual testing is normally done. Doing Unit testing manually incurs a lot of wasted time. Manual Unit testing is time consuming, often undocumented, and not exhaustive, resulting in poor quality software being released. Often repeat bugs are found later in the cycle. Extreme Programming strongly advocates writing automated test harnesses, and is also promotes the concept of Test Driven Development (TDD). These methods work, and provide an enormous leap of productivity on a project. Our course Quality By Design teaches students how this can be done.

Keep It Simple
Make sure you keep the design simple. Techies often like to get carried away and build solutions that are 'flexible' to meet future requirements. Don't do this. If it is not a requirement now, and the business have not stated it is going to be a requirement in the future, then do not spend time (and their money) building a fully flexible OO framework to meet all future needs. Build the simplest thing to meet the requirements. If later they wish to add future enhancements, then you simply refactor the code to do that.

Do not Overwork
As Extreme Programming suggests, do not work more than a 40 hour week, and certainly do not have more than 2 consecutive weeks where overtime is done. It has been shown time and time again, that working longer hours does not get more done, it just gets the same thing done, but it takes longer - and it is of lower quality.

All content © Byte-Vision Limited 1997 - 2004