This content originally appeared on Level Up Coding - Medium and was authored by HD.
Enterprise-grade software demands Full Spec, irrespective of the delivery model, cloud or on-premise. Full Spec software has no masters, gurus, belts, headbands, etc. It is essentially back to the basics of solid engineering across the organization. Because of its simple premise, there is no room for creating an ancillary industry around the Full Spec software movement.
This is an attempt at simplification by getting rid of proliferated roles and responsibilities in enterprise-grade software projects. Training, recruiting, mobility, and career development would directly benefit from such simplification. The current industry landscape is far from simple, especially with various textbook implementations of roles and responsibilities.
1. What is Full Spec Software?
It is the practice of designing and writing code with all the attributes of enterprise-grade software, such as reliability, resiliency, security, testability, operability, accessibility, security, compliance, privacy, etc., in mind. In other words, ensuring that all these attributes are built-in from requirements to specification to coding.
2. How practical is this?
It is not — without proper role and responsibility adjustments. It is unrealistic to expect every developer to become an expert in all elements of Full Spec Software. However, it is plausible to (re)train developers to become competent enough to understand the basics for each attribute and achieve Full Spec with the help of a set of services, tools, and frameworks.
3. Who will provide the services, tools, and frameworks to achieve Full Spec?
It is the responsibility of the Platform Engineering (PE) team. Platform Engineering is a horizontal function that drives the development of common services, tools, and frameworks. Keeping the code base for all the PE artifacts open to contribution by the broader engineering organization is recommended. This practice is called inner sourcing.
The metrics for the Platform Engineering deliverables are ideally higher than those of services built on top.
4. Is “Platform Engineer” a title?
No. Platform Engineering is an organizational construct. The skillset for the members of Platform Engineering must be no different than product engineering teams. There should be no difference in hiring and interviewing practices for the roles in PE organizations. A solid understanding of computer science fundamentals, design, and coding skills are all must-haves.
5. Where are DevOps, DevSecOps, SRE, etc., in this model?
Even though DevOps started as a cultural construct for a tighter collaboration for faster delivery cadence and improved predictability, it became a role. “DevOps Engineers” primarily provide a new sort of operations function for the development teams, breaking the build-&-operate paradigm for the ownership. Writing secure code has been a phenomenon since the early 2000s. There is no Full Spec Software without a high degree of emphasis on security, compliance, and privacy. So, none of these attributes require an explicit call out. Site Reliability Engineering (SRE), as a role, has somewhat similar qualification requirements as Platform Engineering. So far, SRE has been mostly a desirable title conversion for the existing operational staff without ensuring the skillset for engineering. Also, Platform Engineering is not limited to infrastructure. Any capability that contributes to developing any Full Spec attribute is in the scope.
6. How can we transition to Full Spec?
It should be relatively easier to build a Platform Engineering function if you have solid engineers who are willing to specialize in one or more of the Full Spec attributes. Your existing SREs and “DevOps Engineers” who meet the technical qualifications can certainly be members of the PE team as well.
7. What would be the funding model for Platform Engineering?
Companies must fund Platform Engineering organizations centrally to drive a one-for-all approach. Minor divergencies can be delivered in collaboration with the product teams through inner sourcing.
NOTE
This is a living document that will continue to evolve through edits, primarily to address the feedback from all enthusiasts and interested parties who want to drive simplification in enterprise software development. So, please share your opinion and feedback through comments.
A Manifesto for Full Spec Software was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by HD.
HD. | Sciencx (2022-10-11T22:06:54+00:00) A Manifesto for Full Spec Software. Retrieved from https://www.scien.cx/2022/10/11/a-manifesto-for-full-spec-software/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.