Approach
Templemore Technologies has a clear approach to software development built from many years experience working on leading-edge development projects. This experience shapes a vision for developing software that we believe sets up clear ahead of other consultancies and development companies.Sound Object-Oriented Theory
In the mid-1990s, object-oriented development was just starting to become mainstream. New projects were switching from the C programming language to C++. Object Pascal (Delphi) was popular for Windows development and a new language called Java had just been announced by Sun Microsystems. Chris Turner, our lead consultant and director, was working on a number of C++ and Delphi projects and soon noted a common thread across all the projects: developers were switching from traditional to object-oriented languages without first gaining a sound understanding of object-oriented theory. The result was that these projects were just implementing functional and procedural code with an object wrapper around them. And we wonder why object-oriented projects take so long and don’t deliver on the promises of maintainability and reuse!Thirteen years on and the situation has improved slightly. However, we are still amazed at how many projects we get involved in where supposedly experienced developers still lack a firm grounding in object-oriented understanding. It only takes a quick look at most Java web applications to see examples of poor object-oriented understanding: anaemic domain models, pointless service layers that just load/save domain objects, bloated MVC controllers, poorly encapsulated data, repetitive code, incorrect use of inheritance, low cohesion and high coupling. Even now, 10 years after the creation of UML, it’s still difficult to find developers who can stand in front of a whiteboard and abstract a problem into a sensible class model.
... why risk writing software without ‘thinking in objects’.
At Templemore Technologies we believe that a sound understanding of object-oriented theory is ESSENTIAL to any development using object-based languages. Before we write a single line of code or commit a design to paper we make sure that we are ‘thinking in objects’. When undertaking a business analysis we ensure that not only are we gathering and processing requirements, but that we are also mapping those requirements to a sound conceptual (domain) object model of the business. As development progresses we remain focused on ensuring that our abstractions are solid and that every class we develop is correctly encapsulated. Low coupling between objects and components is a must for successful object-reuse, and our sound understanding of object architectures and patterns ensures that every component has the maximum level of reuse without the burden of excessive over-engineering.
A sound understanding of object-oriented theory and a detailed knowledge of the Unified Modelling Language (UML) is the underpinning of our entire service offering. You wouldn’t build a bridge without a knowledge of structural engineering and materials sciences, why risk writing software without ‘thinking in objects’.
Agile Methodology
Traditional approaches to software development advocate a document-driven waterfall approach: first conduct an analysis stage and produce requirements documents; next complete a detailed design document; write the code; finally, produce and execute a test plan. This approach works fine provided that you are able gather all the requirements at the start, that you understand them correctly and even that the customer knows what it is they actually want. However, this usually tends not to be possible and you therefore end up building software that is either incorrect or doesn’t meet user expectations. You then get bogged down in sea of change requests and project management politics.Around the turn of the current century, a new approach began to become popular. This started out with a technique known as eXtreme Programming (XP for short). This approach advocated skipping all the front-heavy documentation and just jumping straight in to building something. The development team would ask the customer what the most important feature was and would start building it as quickly as possible. The completed feature would be ready in a few hours or days and would get shown to the customer. The customer could then give immediate feedback on whether the solution met their requirement or not. If the requirement was wrong (or misunderstood, or the customer changed their mind) then it could be easily and quickly reworked into something better. Software was delivered that met both the customer’s expectation and which adapted to the ever changing requirements common on most projects. XP also introduced techniques such as Test-Driven Development (TDD) and Continuous Integration (CI).
However, our early experiences with XP showed one VERY important weakness: the success of the XP approach was directly related to the ability of the software developer (or team) using it. A skilled team that could turn vague requirements into a quality product while at the same time creating code that was easy to enhance and maintain was a very rare commodity. We worked on a number of projects where just one weak developer in the team resulted in code that was almost impossible to work with in later iterations when new features required that it be modified. This then made the XP process less predictable and more difficult to manage.
... earlier deliveries that meet critical business requirements ...
Fortunately XP has evolved into what is now called Agile Development. This takes the best things of the XP approach (e.g. TDD and CI) while combining it with a lightweight methodology that gives more structure to a project, makes it more predictable and makes managing the development team much easier. At Templemore Technologies we believe that an agile approach to development provides the best mix of fast, adaptable delivery with the ability to manage a project and predict delivery milestones. Our staff are trained in the SCRUM methodology and we actively recommend that our customers follow this agile approach.
An agile software development process leads to earlier deliveries that meet critical business requirements without getting bogged down in over-engineering or unnecessary or unimportant features.