NoDev — Too Many Projects Rush Into Coding
NoDev — Too Many Projects Rush Into Coding
In my time, I've seen IT departments recreate all manner of existing applications: databases, enterprise service buses, continuous build and delivery tools. Before jumping into coding a solution the business needs to make sure that there's not already a working solution on the market.
Join the DZone community and get the full member experience.
Join For FreeLearn how integrating security into DevOps to deliver "DevSecOps" requires changing mindsets, processes and technology.
NoDev is one of the principles of the Trivector Transformation ideology that makes a number of assertions designed to inform IT decision makers when choosing how to proceed with the creation of a new product or service that has a dependency on IT.
The principle of NoDev along with NoOps and NoIT are the result of over twenty years of observations in software development and the assertions they make will undoubtedly cause consternation among many people involved with IT today.
I have generally found that the loudest voices of dissent arise from the groups and individuals that have a litany of IT projects that have resulted in dubious value generation for customers, employees, shareholders, and other stakeholders. In any event, I look forward to arguing my case should anyone wish to pick up the gauntlet.
One assertion of NoDev is:
"Only engage in development projects that deliver applications which demonstrably, unambiguously, and unequivocally generate revenue for the business or enhance customer experience."
To put it another way:
"If you're not in the business of IT, stop making IT your business"
This may be a difficult message for many IT decision makers to hear, including those in the financial sector with mature IT divisions or those teams that take pride in building every piece of IT they use in house and have lofty perceptions of the quality of their code. But, history is on my side, and the trend is inextricable. Many aspects of IT are fast becoming commodities or being delivered and consumed as utilities.
In my time, I've seen IT departments recreate all manner of existing applications: databases, enterprise service buses, continuous build and delivery tools, and all under the thin disguises of project names. If the business was fully aware of what they were doing, these projects would never have seen the light of day—at least in the past, IT has always been good at pulling the wool over the eyes of the business.
If you are not in the business of IT—that is, if your primary business activity is not selling IT hardware and software—then I would be very careful to question the IT department to ensure they are not building a product that exists on the market today.
Before jumping into coding a solution the business needs to make sure IT has evaluated:
Community Software alternatives (business friendly versions of FOSS)
Proprietary Software
Open Source APIs
Proprietary libraries
The last option should be to jump in and start coding from scratch.
Learn how enterprises are using tools to automate security in their DevOps toolchain with these DevSecOps Reference Architectures.
Like This Article? Read More From DZone
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}