As the world requires more code, more applications, more interfaces, and more digital services, the coding pipeline must scale to industrial manufacturing levels. Software engineering techniques are adapting to make, generate, test, and deploy code at greater rates of efficiency utilizing a DevSecOps approach. The potential paradigm of this system is that working faster equals lower quality. The expectation is that low-quality code will be inherently weak and vulnerable. That is, until we introduce agility into the process. Agile teams identify processes that improve not only speed to deliver but also include better non-functional requirements (NFR).
Balancing non-functional requirements such as reliability, dependability, and security is just as important as the underlying feature of the application or service being designed. But some manufacturers, developers, and service providers tend to use their patch management cycles to deal with those all-important non-functional requirements. Mistakes, the technical debt of accelerated deployments, and even purposeful decisions made are solved by simply addressing the issue with a patch. This approach or “do over” is not the best way forward.
Instant gratification is part of the supply and demand balance. Recalls across other industries indicate less importance placed on building the appliance that will “last a lifetime.” The new priority seems to be “making it last long enough for the next consumer push or newest version.” Coding practices face similar challenges. Programmers implement and deploy new facets of coding and become more agile. It just so happens that doing agile is not the same as performing as an agile practitioner. I can say I “do” agile but without looking at retrospective input, constant stakeholder communication, and living a culture of agile, it doesn’t represent the philosophy.
Managers must understand that web platforms are different from system platforms, OS development, and other such constructs. To compare coding practices may be “apples to oranges.” However, the same principles should apply across those in the development operations with security. Different coding practices should not be a cause for division. The focus should be on the principle of a defensive approach to code and the protection of the underlying integration. My next series of blog posts will approach this subject with some ideas for applying security practices to development operations.
Do you experience the paradigm of quicker coding and development = lower quality?
Have you found a unique balance to meet functional and non-functional requirements of projects harmoniously?
If not DevSecOps, then what will allow for streamlined processes and security applied to design, coding, deployment, and operational practices?