The Fundamentals of Software Development: Principles, Parameters, and Practices

(You’ll want to read The Core Process before reading this article.)

While the Core Process gives us the basics upon which to understand software development methodologies, there’s more to explore. While the Core Process can be used to build a new, custom software development methodology, generally speaking, teams and organizations already have a process, so building a new one isn’t needed or even feasible. However, improving an existing process using the insight of quality’s relationship to the core Process can be profound.

If quality is the objective for building on the Core Process, defining and understanding what quality means is critical. That definition, however, will be different depending upon the team or organization. That means that there is no “perfect” process that can be applied to all teams and all organizations.

Let’s use a made-up scenario: you’re a businessman who approaches a software developer. You have a new business idea that will require some software to be successful. You lay out your requirements and ask the developer for an estimate of how long it will take to build. You get this answer from the developer:

“You have two options: I can build it in three months, but you’ll have a small number of major failures during the first year. However, I could take five months, and you won’t have any major failures.”

Which option should the businessman choose?

If you’re building a website that sells a product, you might choose the three-month delivery, because there’s an implied “outage” of two months compared to the other option (meaning, you can start selling after three months, so a few failures may not matter compared to the additional two-month delay).

On the other hand, if you’re building a medical device and those failures would cause someone to die, you would want to go with the five-month plan.

The decision comes down to what’s important to you or what you value when it comes to building the software. This represents the “quality” of the overall software development experience.

To understand how you can approach building or improving the development process, here are three areas to help guide you.

Principles

A principle is a value, purpose, or vision for an organization, a team, or project and can be used to drive and justify the processes used to develop software. It’s common for a company to have “core values” that drive its overall business approach and culture. Software projects can have something similar.

Examples of principles that a software development organization might have:

• We value rapid feedback to enable us to quickly adjust or change direction based upon new information.
• We value purpose-driven decision-making to ensure we understand why and how we are successful (or not).
• We value being transparent to our customers to ensure they trust us and our decision-making process.
• We trust and empower our engineers to make decisions, take risks, and feel ownership for our products.
• We value building products that are simple to use, easy to understand, and enable our customers to be successful.
• We value our customer’s safety and well-being, whether physical, mental, or emotional.

The above examples may apply to different organizations based upon the kinds of products they build, services they provide, or culture they want to enable. Any given principle may be useful to one organization and not another. There isn’t a set of globally-applicable principles that every organization or development team should adopt.

In some cases, principles may contradict each other in certain situations. For example, a team may have a principle around speed of delivery and another around the safety of its users. Where this may occur, principles can be prioritized so that when there is a conflict, one of the principles “wins.”

These principles fundamentally define the way quality is understood and can be used to build measures of success for any given software development project.

Parameters

Parameters represent the context of the project. Most of the time, these represent things that are either not changeable or not easily changeable. These are identified in order to “take them into account” when making decisions. Ignoring them means making decisions based upon faulty information.

Examples of parameters that may exist for a particular project:

• We use Python as our development language.
• Our basic team structure is a single senior engineer with several junior engineers.
• We’re using the Acme Tool for managing our iterations.
• Our team is co-located in the same office.

Though some parameters can certainly be changed, doing so is typically difficult or costly.

Practices

With both principles and practices defined and identified, the actual practices can be determined. Practices represent the individual processes that are followed in order to achieve the desired quality of the software project.

Practices should “map” to principles, taking “into account” those identified parameters. For example, the principle of rapid feedback may lead to the practices of iterative development, A/B testing, etc.

If you’ve implemented a practice that doesn’t map back to your principles, you may want to review it to determine why you’re doing it. You may find that there’s a principle that you haven’t identified. You may also find that the practice isn’t necessary.

Putting It All Together

Typically, organizations pick a particular software development methodology off the shelf and implement it. They may bring in experts in that process to help implement it, providing training, guidance, and execution support. For the most part, that approach works to get things off the ground, but it can sometimes leave individual teams without the tools to identify problems, make adjustments, and implement changes.

Identifying the core principles that a team or organization values helps to define and measure the desired quality of both the product, itself, and the experience getting there. Identifying the parameters that define the context in which development occurs helps teams and organizations to be honest with themselves and helps identify the appropriate practices the implement.

To improve processes, start with reviewing them against this backdrop. What’s the real reason the practice is being followed? What quality is not being observed, and what practice can be implemented to achieve it? What if a principle or a parameter changes? What practices should be changed?

These areas — principles, parameters, and practices — can be used by a team or an organization to better understand why they do what they do and can be used to change for the better.