At New Media Labs we believe in using the best people and the best tools for the job at hand, so each project we take on has its own unique flavor. We do have a few methodologies and frameworks that have delivered the best results for us and our clients in the past, which form the basis of our development process.


Scrum is an iterative process for completing complex software development tasks. It breaks the product down into bite-sized chunks for developers to build and takes the approach that ongoing specification modification and continuous learning is the best way to deliver the complete final product.

The process begins with our client product owner who, in conjunction with the development team, creates a prioritised feature wishlist called a product backlog. During sprint planning, the team commits to building a portion of this backlog in the upcoming sprint, which usually takes two weeks.

The team then completes the development tasks over the course of the sprint, but it meets each day to assess its progress (daily Standup). We have certified Scrum Masters to keep the teams focused on their goal, remove any impediments to progress and give feedback to clients. At the end of the sprint, the work should be potentially shippable.

The sprint ends with a sprint review and retrospective. Here we work on the evolving project “barometer”. Lessons learnt from the previous sprint are taken on board as the planning process begins again with the input of the client product owner.

Domain Driven Design

When designing software, some of the greatest complexity isn’t technical. The complexity is in the domain itself, understanding how a business works and how information flows within a business. If this isn’t dealt with during the design then no amount of technology will deliver what is needed. When we start any project we use Domain Driven Design to ‘crunch the knowledge’ of our client’s domain, starting with getting our software architects and developers to start speaking the same language. We call this the ubiquitous language. From there we start to represent the client’s business and requirements as models. The key entities of DDD that we almost always adopt are Entity, Value Object, Aggregate, Service, Repository and Factory.

Test Driven Development

At NML we are nothing without quality. One way we ensure that our code is of the highest standard is by using Test Driven Development. In TDD each new feature begins with a test before any code is written. This means the developer must fully understand the feature before they write the code. This test is written to fail, to ensure the validity of the test and whether it fails for the expected reason. Only then do they start to write code. As the code base grows so does the number of tests, which are automated to ensure that any additional feature does not break what has already been built.

In order to accomplish this we:

  • prevent bugs vs finding bugs.
  • test quadrants to decide on our test strategy and find ways for the whole team to own quality.
  • are responsible as a team for quality vs testers being responsible.
  • help to build the best system vs trying to break it.
  • assess where best to focus our test automation efforts for the biggest impact.
  • learn how agile testing adopts a fundamentally different mindset from traditional testing.
  • are advocates of the customer rather than specifications checkers.

We use Continuous Integration to manage changes and ensure that a developer does not break another part of the system by accident. CI is the process whereby work from different developers is frequently merged into one Master version of the system. When this is done, the CI server (a physical machine) builds the latest version of the system, then executes the hundreds of fast unit tests and finally executes the slower integration tests where the CI server actually opens a web browser and physically interacts with the system under test to try and detect any problems. The most important part of this process is that when a test fails, the CI server notifies everyone on the team. The team has to then immediately fix the problem. Fixing problems immediately means a more stable system and speeds up the problem analysis.


Service Oriented Architectures is the architecture by which we get modern systems to communicate with one another and thus interoperate with one another. In the modern software development world almost all systems are disconnected in the sense that they don’t reside on the same infrastructure or even in the same process. We connect these systems through protocols and techniques that make up the basis of SOA. Almost all systems now have a visual interface and a software based interface we call this the API or Application Programming Interface. Designing a good API is an art. Choosing the right SOA approach is also an art. Services can be exposed through SOAP, RPC, REST, Java RMI to name just a few.

Need a software development partner?

Get in touch