Cultural barriers: Many businesses view software and engineering as “dark arts” that are magically done by creative people. Undeniably, engineers are highly skilled and their work very technical, but that does not excuse them from understanding and acting upon the business needs associated with the software they are developing.
Lack of understanding: Communicating requirements is a difficult task further complicated by the subjectivities of the business and development teams. Policy-driven development requires engineers to understand the business objectives behind the policies driving their code, which eliminates the need for businesspeople to communicate with engineers on a technical level.
Belief that adherence cannot be measured or enforced: In most cases, engineers are working with an existing codebase. Attempting to suddenly enforce a full set of policies would not only overwhelm the team, but it would also make measuring and enforcing the policies extremely difficult. This is why policies should be introduced gradually.
The reason that organizations fail to overcome these barriers is that their guidelines are not elevated to policies. Guidelines describe suggested behavior, whereas policies define expected behavior. For example, “Wash your hands after using the restroom” or “Look both ways before crossing the street” are guidelines. They’re great suggestions, but they cannot be fully enforced. Overcoming these barriers is essential for graduating from “nice-to-have” guidelines to “must-have” policies.
How to get started with policy-driven development
Define what policies you want to implement: Policies can be formed around any aspect of the development process, but to be effective, they must be definable, enforceable, measureable and auditable. You can define as many policies as necessary to help you achieve your goals, but you should start implementing them on a small scale. Introduce a few policies at a time, and as you become proficient with those policies, you can introduce more in small batches. There are three types of policies that align with different goals and testing methods.
Process policies drive overarching sets of tasks through to completion and usually establish quality gates associated with the completion of a release cycle. Examples include policies that govern:
• Software development processes
• Software life-cycle processes
• Compliance with industry standards or recommendations (e.g., for secure application development)
People (or human) policies can be configured based on role, responsibility, skill-level, etc. They govern processes related to human interactions, for example:
• Task estimation
• Peer review
Quality policies promote business objectives that are defined as nonfunctional requirements. They are measured by process monitors that deliver unprecedented visibility into the software. Examples include policies that cover:
• Application development (monitored by static code analysis)
• Code reliability (monitored by coverage analysis)
• Change impact (monitored by regression testing)
Adopting a combination of these policy types leads to a number of benefits that fundamentally improve the development process. You will be able to:
• Find and isolate potential defects: Code that is in violation of your policies is more likely to contain defects.
• Gain early visibility into potential disasters: As policies are further defined, they form a matrix that enables you to pinpoint specific types of defects.
• Centralize organizational expectations and acceptable performance: Maintaining policy documentation becomes less complex; software engineers actually have a consistent access point for learning about the policies.
• Raise the “policy IQ” of the engineering team: With gentle coaching from the process monitors, engineers will gradually start writing and testing code in the expected manner—as a matter of habit.
• Bring consistency to projects: Consistency is achieved across implementation of requirements, usage of approved test data, and the design and execution of tests for various levels of granularity. This uniformity helps control complexity, as well as reduces risk.
Explain policies in the context of the business goal: Encourage the lead engineer to work with the business analyst to document policies in natural, understandable human language within the context of the associated business goals. If the connection between the policy and goal isn’t clear, the employee can’t be expected to understand why they need to follow the policy. This, of course, is in direct violation of the definition of a policy as setting expectations. For example, if an organization wants a policy that requires all methods to be unit tested, management should describe how the business benefits from the policy.