Software development
Our software development motto is this:

Do it the "right way"
and
Do it rapidly

Many firms promise one or the other, few promise both, and fewer still actually deliver on either promise. The "right way" is the right way for you and your current business needs, not just the way we like doing it. Rapidly means leveraging tools and techniques to reduce time-to-market while still maintaining the high quality achieved by doing it right.

We have found through experience that one methodology doesn't suite every application or development scenario, but each one has valuable tools and techniques that can be employed at different times. To that end we choose the best approach on a project-by-project basis and try to use what best serves the individual client.

Here are some key methodologies, tools and techniques we try to employ in every engagement if possible:

Reusability
The two most common forms of reuse companies make use of is Informal Code Reuse and Blackbox Code Reuse.

Informal Code Reuse, such as copying chunks of code from another application or the Internet, is the lowest form of reuse. It takes the least amount of time/effort/cost, but accordingly produces the least valuable result. The amount of reusable code will be very small, and because the code was not designed to be reused it will unlikely demonstrate the best approach. Similarly, trying to adapt an existing applications code, that has not be designed for reuse, usually requires more time than building it from scratch because of the time it requires to understand the code first.

While “blackbox” tool kits or software APIs can certainly speed up development, the time you save using it is usually countered by the time it takes the developer to learn the new tool. Furthermore, tools or APIs are usually only good for a specific piece of the application. If more than one tool or API will be required for the various parts of an application, the attractive “blackbox” aspect will be a major obstacle as developers try to interoperate between the disparate tools. Extra work that was not counted on, so-called “glue code”, will most likely be required to make them work together.

The type of reuse that is most valuable is Architected Reuse, or reuse by-design. When an application or its components are designed to be reused the code will be much more robust and flexible. When an entire framework of reusable components is used, there are very few interoperability issues, and developers can concentrate solely on the business processes.

Types of software reuse and their impact
Based on Software Reuse: Architecture, Process and Organization for Business Success
By Jacobson, Griss, and Jonsson

Iterative design approach
Traditional software design made use of techniques such as the "waterfall" life-cycle, whereby each stage of software design and development cascades down into the next stage, waiting to the end of development to get feedback on whether or not the objectives were achieved.

Using the Iterative Design approach, each stage in the software development life-cycle is one step forward, and then one iteration backward to confirm that the right result was achieved. If something is incorrect or missing then that iteration is improved (refactored), and reviewed again when it is completed, and so on.

While at first glance the iterative cycle may seem to waste time, it actually shortens the overall time a project takes as potential problems are caught in the early stages of development where they are easier to fix. A number of smaller course corrections along the way are always less painful than a total direction change in the later stages of development.

Iterative Design approach

Use case-driven design
Use case-driven design is the process of using the use cases, requirements and analysis artifacts describing the functionality required by a customer, to drive the technical design of the entire application.

First the use cases drive the creation of the domain model, classifying the parts of an application into entities, processes, and roles.

At this time a number of design activities can run in parallel...

Use Case-Driven design

SCRUM Process Framework
The SCRUM process framework offers an excellent model for managing the software development life-cycle and achieving goals quickly.

It suggests using Feature-Driven Design (FDD) to break up the design into feature subsets, and group those subsets into 3-8 one-month sprints. All of the features that cannot be accommodated inside those sprints are added to the 'product backlog', which will be revisited as time permits.

In this way a number of smaller, achievable successes can be demonstrated to the customer throughout the entire course of the application's development (rather than at the end). The end result is that the customer has a much higher confidence level that the overall product will be successful by seeing mini-successes all along.

By using use case-driven design as the requirements/analysis/design mechanism of SCRUM, you can choose subsets of the feature list gleaned from the use cases and group them into sprints.

Test-Driven design
Common practice in software development has been the separation of code development and code testing. The developer creates the code, and then passes it off to a code tester who will then test the code and report the bugs back to the developer. The developer will then fix the bugs and pass it back to the tester again, and the cycle will continue until a bug-free release is achieved.

The problem with this approach is that because the code tester did not write the code, he or she will always be at a disadvantage and understand less than the original developer. This will lead to code that has not been thoroughly tested. Furthermore, since junior developers often fill the code tester position, assumingly to learn on the job, they don't have the skill level required to understand code written by a senior developer. Many bugs will not be found, and the value of a code tester in this capacity is not very high.

Test-Driven design aims to change this by having the original developer create their own tests, called Unit Tests, upfront before they even start coding. In this manner, the developer is fully aware of the business requirements (since test cases are derived from use cases) and there will be less misunderstanding, and the developer will update his Unit Tests all through the process of developing the code. In effect the developer will create a skeleton application and flesh out the code, rerunning the tests each time a change is made to ensure nothing has been broken along the way. The result is that there will be fewer cycles of passing code back and forth since it will be pretty solid the first time round. The code testers can then concentrate on overall application integration testing and not worry about each individual component (or unit), saving a lot of time.

Test-Driven design works fantastically with Use case-Driven design. The test cases are derived from the use cases, and the unit tests are created using those test cases right from the beginning. The unit tests are added to and rerun all throughout the course of development and the majority of errors are fixed before the code ever reaches the hands of a tester.

Automated test frameworks, such as JUnit (for Java) and NUnit (for .Net) make the job of validating those tests even easier.

Object-Oriented analysis, design and programming
Object-oriented, or OO as it is referred to, is the process of classifying data as objects that will act as a real-world representation of the data (as opposed to the underlying entity tables in a database). These real-world objects are easier to relate to, allowing analysts and architects to create software that more closely matches the actual business it will be used in. This in turn makes the code easier to understand, as the business purpose is infused in the design.

Software designed using this approach requires more experienced developers, but results in much more solid and extensible code.

Document-View, or Model-View-Controller paradigm
Developed by the SmallTalk Team, MVC maintains that the model code (code that deals with data-specific operations) should be separated from the view code (GUI-specific operations) and the controller code (code that handles the interoperation of user input, and the other layers).

This separation results in very modular, extensible, reusable code and still aptly describes most application designs today.

Software design patterns
First introduced by The Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides), design patterns are models of reoccurring business problems in software design that offer a "best practices" approach to a solution. While no business is exactly the same, patterns offer blueprints or stepping-stones to achieve answers more rapidly by not re-inventing the wheel as it were.

Design Patterns offer reusability in the "Architected Reuse" range (software that is designed to be reused and extended), so they provide high value reuse.

UML
Created by The Three Amigos (Ivar Jacobson, Grady Booch and Jim Rumbaugh), Unified Modeling Language (UML), a modeling language used to describe software systems, is an amalgamation of the best software design notations of the time.

UML is made up of a standardized set of software design diagrams and concepts used to facilate communication between business analysts and software architects - providing a graphical bridge between the two worlds.

XML
Extensible Markup Language (XML), is a language used to describe (or model) data. A standardized approach to modeling data leads to increased interoperability - the ability for one application to share data and communicate with another application, or even another company. When applications make use of XML as the transport mechanism, seamless integration can be achieved.

XML also provides an abstraction from the implementation level of software. An application can use the resulting XML regardless of what action has occurred to produce that XML. This abstraction allows applications to operate disparate services that by design can form one larger service. This is the web services model, introduced and popularized by Microsoft but now realized by every major vendor.

XML is the "tie that binds" information technology today. Almost every product or service that is made today uses XML in one flavor or another. It is even becoming embedded into the operating systems now.

---

Resources

 Model-View-Controller (MVC) Evolution
 Model-View-Controller (MVC) FAQ