Software developers are often asked to describe their “methodology.”

You get a variety of answers to this question. Some talk about a version of the “lightweight” or “agile” approach to development. Others describe something similar to the Rational Unified Process. Still others say their methodology is shaped to fit the size and nature of each specific project, and uses elements from both the lightweight and heavyweight schools.

But behind this question “what is your methodology” is mostly a desire to know where you stand as a developer, how you see the process, whether you really understand getting from A to B, from need to solution. What makes you different? Do you know what you’re doing? Can you handle complexity? Risk? Does your process respect budgets and timeframes? How? In other words, “please say something to convince me I can trust you with my goals, my time, my budget, my desire for a very successful project.”

So that’s what we’ll try to do.

The purpose of any methodology is to reach specific objectives. Unless we’re clear about objectives, we can’t judge efficacy of methods.

Eagle’s starting point is to acknowledge our intention to create software which:

• meets the functional needs of users
• is easy to use with minimal training
• is reliable
• has good performance
• is cost-effective
• is completed within an acceptable timeframe
• is maintainable and can evolve gracefully over time

Certain principles are common to all methodologies. It’s important for us as developers to understand them as principles, because these are elements of the process that must not be compromised, even though details of their application may vary with the demands of each project.

These are principles which we have learned over the course of our careers and hundreds of projects. At first glance they may seem too simple, too obvious or too naive to receive the status “principles underlying all software development.” But we think that in the actual practice of software development they are not so simple or obvious, and not so easy to put into practice consistently.

• Understanding. Reaching a valid understanding of stakeholder needs is fundamental. This includes a completely accurate understanding of the vocabulary of the “problem domain,” the functional behavior needed, how the software is to be used, and so forth. Every successful methodology must include the obligation of developers to gain this understanding and to document it so that client and developers share an explicit, common knowledge of the problem domain as it relates to the system being developed.Yes, there are the usual observations that development is iterative, that stakeholders are participating in a “discovery” along with the developers, and of course that is true. It is also true that that must not become an excuse for accepting unnecessary compromises in “understanding.” You do so at your own risk. Ultimately, if the project is to be successful, understanding must be achieved. You can do it sooner or you can do it later. It costs much less and leads to much higher quality if understanding is gained at the earliest possible stage of the project.
• Verification. Developers cannot take anything for granted. Incorrect assumptions can be corrected easily at the beginning of a project, but can be expensive or fatal if discovered at the end. This refers to all aspects of a software project, including project goals, hardware/network performance, and efficacy of third-party software components, as well as estimated effort, timeframe and cost. All questions and assumptions must be investigated, and the conclusions should be part of the system’s written documentation.
• Order. It is often (always?) tempting to begin a new activity before its prerequisite has been completed. For example, to design before finishing discovery and requirements analysis, or to code before completing a design specification. In order for code to be right, an appropriate design must be completed first, and in order for the design to be right, requirements must be understood. This can be a subtle issue because effective development methodologies are iterative and adaptive, which means that all requirements are not necessarily completed before beginning design, and all design is not necessarily completed before beginning implementation. But within specific threads of development, it is essential to respect the necessary order of development.
• The ultimate priority. Every aspect of a project—including “methodology” and “principles” as well as specific work product—must be measured against the objectives mentioned earlier. For example, during implementation a decision based on the convenience of a programmer may create an inconvenience that users will have to live with for years. Or a decision which makes sense from a strictly technical point of view may impair the usability, reliability or maintainability of a system for its entire life. While project cost and duration are always important, decision-making needs to respect the full set of project objectives—especially the quality of the final product from the user’s point of view.