System Craftsmanship: Software Craftsmanship in the Cloud Native Era
Table of Contents
As software people like to find bugs in the software systems, they also tend to find the anomalies or bugs in the processes and fix them or propose other ways; other procedures. This is because of an instinct that continuously pushes them to find the best: continuous improvement.
For a long time, there have been a lot of methodologies came along in the software industry like Spiral Development, V-model, and Waterfall model and all these came out because software development is a process that includes “production” in it, and because of that production thing, it has to have a well-working process to create good outputs. Of course, perspective is changed from time to time to these “outputs” (sometimes it became “time and revenue”, sometimes “product quality”, sometimes risks, sometimes all) and this was what pushed the software people to change the methodologies as time goes by for better processes. And these methodologies labeled as “heavyweight”.
So, a few “lightweight” software development methodologies emerged between the late 90s and early millennium, as a solution to the heavyweight ones. Some software experts, as the creators of these “lightweight” methodologies, decided to get together, share what they were doing and discuss a more common alternative to heavyweight, high-ritual and document-based approaches like Waterfall or Rational Unified Process (RUP) that created a lot of problems back in the days.
Agile
It was back in February 2001, in Snowbird, Utah, seventeen influential software experts gathered around a whiteboard to talk over the wretched state of the software development and create a manifesto and a few principles around that manifesto that will deeply influence the software world.
And a manifesto came out…
Agile Manifesto
The following is an excerpt from the Agile Manifesto website:
We are uncovering better ways of developing software by doing it and helping others to do it. Through this work we have come to value:
- Individuals and interactions over process and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Besides the Agile Manifesto, the originators of Agile also came up with twelve principles. In this article, we won’t list or go deep into these principles, but it is important that you read and understand those principles by heart before talking about the practices of agile.
Agile Methodologies
Agile itself is not a problem solver, it is a problem exposer. It is all about quick and short feedback loops that make us see problems sooner. Every time you receive feedback, you have a chance to react or not; this is what makes you more agile or less agile or non-agile.
Sandro Mancuso, in his book The Software Craftsman, mentions that agile is not a single methodology:
Agile is not a single thing. Agile is a combination of methodologies and techniques that, according to the context, can help teams and companies to adapt to the ever-changing nature of software projects and also reduce the risks associated with them. The Agile disciplines and methodologies can be divided into two main groups: process-oriented and technical-oriented.
Process-oriented agile methodologies affect how teams, groups, organizations work, organize things, and collaborate, and focuses on the business processes itself. Lean Software Development and Scrum are two well-known examples of process-oriented methodologies.
As for the technical-oriented agile methodologies, these are more focused practices for developing, maintaining, and delivering the software itself. Extreme Programming is one of the most popular and well-known methodologies amongst other technical ones. This popularity comes from its containing successful practices like Test-Driven Development, Pair Programming, Simple Design, and of course Continuous Integration.
Extreme Programming (XP)
In 1996, Kent Beck introduced and gathered a set of practices that emerged XP practices, and by the time passed with a few important projects like C3 (Chrysler Comprehensive Compensation), it took its final form with subsequent contributions. Since the Agile summit in 2001, XP is considered an Agile methodology.
XP has many technical practices like Test-Driven Development, pair programming, refactoring, collective ownership, and Continuous Integration, all of which have their own benefits for the software development world.
By adopting the Continuous Integration method, that Grady Booch first proposed, and extending it, maybe XP put the key in the keyhole of the door that opens to the DevOps world. So let’s take a short trip to that world.
DevOps
The term “devops” was originally first revealed by Patrick Debois and Andrew Shafer in 2008. As it is stated in the book The Phoenix Project, it began its public journey at Velocity Conference in 2009, by John Allspaw and Paul Hammond, with the presentation “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”.
DevOps is a way of improving the collaboration and shortening the system’s development life cycle with providing continuous methodologies by combining cultural philosophies (people), practices (process), and tools (technology) all of which address the items of the CALMS acronym —which stands for Culture, Automation, Lean (as in Lean management), Measurement, and Sharing— that is a useful acronym for remembering the key points of DevOps philosophy.
For Kief Morris, in his book Infrastructure as Code, DevOps is a movement to remove barriers and friction between organizational silos – development, operations, and other stakeholders involved in planning, building, and running software. Although technology is the most visible, and in some ways simplest face of DevOps, it’s culture, people, and processes that have the most impact on flow and effectiveness.
DevOps has benefitted excessively from the work of the Agile Community. Some methodologies like Lean Software Development and XP helped emerging small releases, frequent release cycles, and maybe most importantly, small teams operate in harmony.
So while building upon the features of XP’s Continuous Integration and other extended practices like Continuous Deployment (by Timothy Fitz), and Continuous Delivery (by Jez Humble and David Farley) which are essential for achieving fast development flow, DevOps also extended those practices with the help of other concepts like “Infrastructure As Code” which should be used to bridge gaps and improve collaboration.
We will come to that shortly, but first, let’s fly a little bit over the clouds.
Cloud Age & Cloud Native
It is for sure that if we stop what we are doing right now and ask some people about what Cloud Native is and how they define them, we will surely get different answers. It is not easy to define Cloud-Native but I like -and prefer- to call it as:
Any technology or methodology that is adapted to run or be used on cloud systems and take full advantage of it.
But of course, Cloud Native is more than this.
I think it is the best to get the definition from Cloud Native Computing Foundation itself:
Cloud-native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
Since “Cloud Age” encourages a dynamic and fast-moving technology era -most probably because of the Agile and DevOps effect- and exploits faster-paced technology to reduce risk and improve quality, Cloud Native is in this case much about speed and agility to deliver better reliability, security, and quality.
Unlike the Iron Age -a definition by Kief Morris from the book Infrastructure as Code-, everything is more dynamic and agile in the Cloud Native Era (aka. Cloud Age). However, this agility and the faster pace of change -and also the risk that comes with this package- can not be efficiently managed with the traditional methodologies that belong to Pre-Cloud Native Era (aka. Iron Age).
So an approach like Infrastructure As Code comes as a savior.
Infrastructure As Code
Infrastructure as Code is an approach for building automated infrastructures that comprise continuous change for high reliability and quality with the help of practices from software development.
According to Kief Morris’ book, the core practices of Infrastructure as Code are:
- Define everything as code
- Continuously validate all work in progress
- Build small, simple pieces that can be changed independently
The “everything”, in the first practice “define everything as code” is the whole infrastructure system that can be defined in three layers:
- Infrastructure Platform
- Application Runtime Platform
- Applications
While defining everything as code will help reusability, consistency, and transparency, continuously validating all work in progress will help to improve the quality. Building small, simple pieces that can be changed independently practice is all about loosely coupling systems. Just like the microservices’ mentality, each piece will be easy to change, deploy, and test in isolation.
Continuous change is inevitable in the Cloud Native Era, and regarding to the research “Accelerate State of the DevOps Report”, making these changes both rapidly and reliably is correlated to organizational success.
Kief Morris states in his book “Infrastructure As Code”:
A fundamental truth of the Cloud Age is: Stability comes from making changes.
And since Infrastructure as Code applies software engineering practices to the infrastructure for better reliability, security, and quality, why not use it?!
As we’ve been saying “software engineering practices”, and “code” -for a few times actually- how about taking a step or two back and look how the “Agile” world is doing while these all kind of technology or cultural transformation stuff are coming up rapidly in a short period of time?
Agile Hallucination
We got excited when we all first heard about Agile. Many of us -the developers- came from the “Waterfall Factory” mentality and it was a kind of hope for us.
Consultancy services for Agile methodologies purchased by companies, training and related certifications are done, use-cases became user stories and Project Managers became Scrum masters.
Many of the companies benefited from the Agile transformation and could pass to the next phase -DevOps- and can now deploy software to production multiple times in a day as a single unit; as a single team.
But it did not end for many others like this. There became a couple of problems:
- Doing Agile ceremonies like standup meetings, estimations, sprints, using post-it notes, etc. felt like they are Agile. Ceremonies made those practices useless by forgetting the real purpose. And yes, the real purpose is forgotten.
- Managers and Agile coaches who became “secret managers”, started to push developers to work faster because the process from their Agile perspective is more important than engineering and technical practices. So Agile mentality “fix the process and engineering will be fixed”, which is not even an AgileBut.
- As developers did write fast code to finish their work in time -in the current sprint- the code quality is reduced so the bugs and the related operational problems became the hot topics of the daily standup meetings and especially retrospective meetings.
In short, the focus was not on the technical work, design architecture, engineering which is the core of the project, but was on the highest-priority item in the backlog which has to be done as soon as possible. They thought they are Agile or doing Agile like this, but it was not and they even wasn’t aware of that until “the Agile Hangover”.
“And then one day, after a few months, or years in some cases, of having fun in the Post-It party, teams and companies woke up with a massive headache—the Agile hangover,” says Sandro Mancuso, in his book The Software Craftsman: Professionalism, Pragmatism, Pride.
However, I prefer to call this “Agile Hallucination”, because, regarding to Sandro’s definition, you have to be really Agile, or even did AgileBut in the past to be in an Agile Hangover presently. Mostly it is not like this: the series of ceremonies that many of the companies do is not even Agile, so there is no “hangover” afterward.
That’s why I call this Agile Hallucination; because in many companies they can not be Agile -or even DO Agile-, but they think they are…
Software Craftsmanship
“At the Snowbird meeting in 2001, Kent Beck said that Agile was about the healing of the divide between development and business. Unfortunately, as the project managers flooded into the Agile community, the developers—who had created the Agile community in the first place—felt dispossessed and undervalued. So, they left to form the Craftsmanship movement. Thus, the ancient distrust continues” says Robert C. Martin (Uncle Bob) in his book Clean Agile: Back to Basics
A group of software people met in November 2008 in Chicago to create a new movement to raise the bar of software development and heal some of the Agile goals. The movement’s name was: Software Craftsmanship.
Software Craftsmanship is a journey to mastery. It is about responsibility, professionalism, pragmatism, and pride in software development.
Uncle Bob Martin, in his same book Clean Agile, defines Craftsmanship as follows which gives a more clear understanding:
Craftsmanship promotes software development as a profession. There is a difference between having a job and having a profession. A job is a thing we do but it is not part of who we are. A profession, on the other hand, is part of who we are. When asked, “What do you do?”, a person with a job would normally say something like “I work for company X,” or “I work as a software developer.” But a person with a profession would generally say, “I am a software developer.” A profession is something we invest in. It’s something we want to get better at. We want to gain more skills and have a long-lasting and fulfilling career
Software Craftsmanship doesn’t have any practices. So it is not -or set of-:
- Clean Code
- Test-Driven Development
- A specific set of technologies or methodologies
- Software Architecture or Design
- A selected group of people
- Religion or Cult
Software Craftsmanship itself, on the other hand, promotes a perpetual search for better practices and ways of working. Practices are just tools and good practices are replaced until better ones discovered. For example since 2008 -the foundation year of Software Craftsmanship Community- Extreme Programming (XP) is strongly advocated since it still provides the best set of Agile development practices currently. However, the practices of XP, are still the practices of XP, not the practices of Software Craftsmanship. XP is not the only practice that is proposed. There are principles like Clean Code and SOLID, or methodologies like Continuous Delivery, small releases, etc. that are promoted in Software Craftsmanship
Rather than technical practices, Software Craftsmanship is about putting the “craftsmanship” mindset in software development. Think about this, if you were an apprentice who works with a master of the handmade comb, what would you do? Watch? Learn? Ask? Be Better? Reflect as you learn? Expose your ignorance? Practice?
As Uncle Bob says in his book Clean Agile, “Craftsmanship is not only about technical practices, engineering, and self-improvement. It is also about professionalism and enabling clients to achieve their business goals.”
Responsibility. Professionalism. Pragmatism. Pride. Practices. Those all are shaped and gathered in a manifesto at the end of the meeting that happened in November 2008, just like the one that formed the Agile Manifesto in 2001.
Software Craftsmanship Manifesto
“In that meeting, similar to what happened during the Agile summit in 2001, they agreed on a core set of values and came up with a new manifesto that was built on top of the Agile Manifesto” says Uncle Bob Martin, in his book Clean Agile.
As aspiring Software Craftsmen, we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:
- Not only working software, but also well-crafted software
- Not only responding to change, but also steadily adding value
- Not only individuals and interactions, but also a community of professionals
- Not only customer collaboration, but also productive partnerships
That is, in pursuit of the items on the left we have found the items on the right to be indispensable.
Well-crafted Software
Well-crafted software is about its being well tested and well designed. It means it can be changed without any fear to break things -because of the tests and other mechanisms- and enables any business to respond fast. It is the legacy code that every software developer would want to work with.
Steadily Adding Value
“Value” here is not just about the investments for the relevant project, or more technically, adding new features, fixing the current bugs. It is about being committed to continuously provide increasing value to clients, employers, project stakeholders, etc. This value can be increased both ways: collaborative improvement (a community of professionals) and improving the structure of code, keeping it clean, extendable, testable, and most importantly, easy to maintain.
A Community of Professionals
The only way to move the software industry forward is by doing continuous collaborative improvement. But what does this mean? This means that we all are expected to share what we learn, learn from each other, and mentoring the newcomers of the industry. We are responsible for raising and preparing the next generation of craftspeople, and one way to do this, is by sharing your experiences and exposing what you know and you don’t know.
Productive Partnerships
Having a professional relationship with the clients and employers is very important. Behaving both ethically and respectfully is the base of productive partnerships. Think of this kind of partnership as an invisible kind of contract that is a symbol of mutual professionalism that is essential to make any project succeed.
Agile and Software Craftsmanship
Software Craftsmanship is not a movement that replaces Agile. They both are mutually exclusive and both movements want to achieve same things like customer satisfaction, collaboration, and value short feedback loops, deliver high-quality valuable work and professionalism.
People in Agile movement may criticize Software Craftsmanship for it lacks the focus of business and people, and people in the Craftsmanship movement may criticize Agile movement for its lack of focus on engineering and low-level process. However, these two movements complement each other nicely. As Sandro Mancuso says in his book The Software Craftsman, while Agile methodologies help companies do the right thing, with focusing the low-level things like writing good and well-crafted code and promoting doing more to customers than just writing code, Software Craftsmanship with this way helps customers to do the thing right.
So the cure for Agile Hallucination is the Software Craftsmanship mindset and culture. What about the DevOps world? Do you think everything is wonderful in the DevOps-land?
DevOps Hallucination
Think of a company -let’s call it ACME-, that may be the one once you were in, purchased some Scrum training, did some workshops internally, and certified some people as Scrum Masters. How cool is that!
With these Scrum masters, they created a pilot group and selected a pilot project. They started with the Kick-off meeting and did the all planning, the sprints, etc. All Agile right?
After some time, when things seem to be ok with the pilot project and the team, even if the only topic at the retrospectives are the bugs, problems, and fatty backlog of the current sprint, they reported to managers “Agile is perfect, we can start to do the other projects like this; sprints are cool!”
However, as we discussed before, they were not doing Agile, not even from the start. It was an Agile Hallucination.
Now think of the same company, starting to adopt DevOps with this kind of “Agility”. Do you think that will they be able to really do DevOps?
DevOps needs agility and collaboration, which comes from the Agile culture. Of course, one can go backward and try to implement first DevOps itself, but be sure that he/she will end up with being Agile.
Back to the company, if we ask the “DevOps team” how they implemented their DevOps processes, probably they will first explain to us how they automated things -if there is any-, which tools they used, how many deployments they do -or most probably try to do- in one day, etc. Where is CALMS here? Is this DevOps?
No, because like Agile, DevOps is a culture change; starting from people, continuing with the process, and the last one as technology. It is not only tools and practices. It is a loose set of practices, guidelines, and culture designed to break down silos in IT units.
If you just implemented some Continuous Integration and Deployment tool and using it to automate your deployments with just a “git commit/push” command, it is cool. But you are doing is not DevOps.
I call this situation “DevOps Hallucination”. Like Agile Hallucination, companies may be in a state that they think they are doing DevOps, but like Agile, DevOps is not a thing that you can just do. You can BE in a DevOps culture but can not DO DevOps.
It is the situation of seeing “Dancing Elephant(s)”.
I use this metaphor because the “Elephant” metaphor is widely used for explaining DevOps (as we did above as well). And a “Dancing Elephant” most of the times used for “a good working DevOps mechanism -and of course a well structured DevOps culture”
DevOps Hallucination occurs in two ways:
- You are Agile and do all practices perfectly while developing your software. You automated things, CI/CD mechanisms work perfectly, automation works perfectly. But there are no tests of the automation code, no single source of truth, or no code review mechanisms. Or there are DevOps teams who just do DevOps with titles of DevOps Engineers. No cross-functional teams, or any organizational reflection of DevOps culture itself, like collaboration. This is also an AgileBut alert!
- You are not Agile. You are in an Agile Hallucination and you did automate everything just like the first way above. Because of the non-Agile situation, there is no base to create a real DevOps culture. Your sprints and daily standup meetings make you think you are Agile, and written automation makes you think you are “doing” DevOps.
In either ways, there is no DevOps, just its hallucination. Creating a real Agile culture in the team will lead to a real DevOps culture, but it is hard to achieve unless companies start to focus on people, rather than processes and technologies.
People, Process, Technology
Focus on DevOps should always be in order of:
- People
- Process
- Technology
If you want to build a culture, start with the lowest level: people, then focus on the process, and the last focus always should be technology.
Nowadays most of the companies tend to start in reverse order. They start with technology or process -or both in parallel- then -when they come up- try to fix the organizational problems which are tightly related to each “person”‘s problem.
Focusing on people doesn’t mean that recruiting some DevOps Engineers -which is totally a fake title; sorry for that-, who can “do” DevOps and put them in an isolated group aka. silos and made them automate stuff around a couple of cool tools that can do CI/CD or IaC, like Jenkins, Ansible, Chef, Terraform, ArgoCD, GoCD, etc.
But how to focus on people? Before explaining this, let’s answer “who are these people?” question.
Who are these “people”?
These people are Software Engineers/Developers, Software Architects, System Engineers, System Administrators, and Service Reliability Engineers (SRE) – and of course, many others who are highly related to the DevOps process as technical people. For now, we will just focus on some of them.
- Software Developer/Engineer: Mostly develops applications. Highly aware of the Agile and CI/CD process. If there is an Agile culture constructed, he/she is in. Or there is a DevOps culture constructed, he/she is in as well.
- System Engineer: The guy between the triangle of the system (including cloud), middleware, and the applications. We know them sometimes as Software Architects in some companies, as DevOps Engineers in some others.
- System Administrator: Person who knows about a specific system or infrastructure and most probably certified around it. He/she is the system infrastructure folk who likes the “God” access. He/she doesn’t write too much code like System Engineers (I don’t count the exceptions), mostly uses UI for administration management and operation purposes.
- Service Reliability Engineer (SRE): Regarding an article by David Hixon and Betsy Beyer (one of the authors of the famous book of SRE), the roles of Software Engineer and System Engineer lie at the two poles of the SRE continuum, skills, and interests. So this somehow means that SRE is the person who can do both software development at the application level, and system engineering at the infrastructure level. This title is the most confused one with the title “DevOps Engineer” because as it is stated in the short article How SRE relates to DevOps by Murphy, Jones, and Beyer, in many ways, DevOps and SRE sit, in both practice and philosophy, very close to each other in the overall landscape of IT operations.
- DevOps Engineer: I am joking:)
Did you notice which roles above are related to the application development and which are not?
When an Agile transformation process is being started in a company if there is no plan for DevOps, the transformation sticks at the application level. This is mostly not a problem from the software project’s stakeholder’s perspective, because as long as you can do sprints without any problem and do CI/CD and other technical stuff, there is no issue for them. But what about the “system people”‘s or operations people’s perspective?
DevOps culture is a way to do this of course. Merging the development and the operations in a cultural way, but in this case, isn’t it be a kind of starting with the “process” rather than “people”?
If you directly merge Dev and Ops cultures with either starting with technology -or tools- (which is a very very common case by the way) or starting with the processes like “guys we will include you system engineers, or SREs to our X project that we use Agile methodologies and we will do some awesome sprints together” or recruiting -yes again:)- DevOps Engineers and make them be a part of this “new” kind of “cross-functional team” just to do the “automation stuff”, you end up with a DevOps Hallucination!
In this DevOps Hallucination let’s put the Cloud in the equation and see what happens.
When Software Engineers of let’s say “Project Roadrunner” realize they have to write some code around the new Cloud technology -for example Kubernetes resource YAML files-, they begin to say “it is the system/infrastructure, I am a Java Developer, I can do magic with Spring Framework, but this Kubernetes thing is not my responsibility”.
All these will go in a loop while “system people” or “DevOps Engineers” who are merged into the Agile workflow of Project Roadrunner try to “automate” things to “do” DevOps, without any test, review, or any kind of quality. A loop that will never break unless anyone focuses on the “inner” level of the problem, focusing on the “people” before trying to solve how to structure the process and technology flows.
The Problem(s)
Project Roadrunner current status:
- SW Engineers don’t want to write cloud-related code that is actually related to the application. They think it is the responsibility of the “DevOps team” (a legendary team that has DevOps Engineers).
- System Admins/Engineers don’t know how they will manage some cloud-related common resources. They don’t know who will be responsible for resource A and B.
- Regarding this responsibility issue, some people made a “heads up” and teams made a couple of meetings to create a RACI matrix, which is a part of the “process”, not “people”. After those meetings, it is still not clear who will be responsible for what, or how to achieve these organizational goals.
- System Engineers/SREs or “DevOps Engineers”, who are responsible to make the automation for just labeling the whole process as “DevOps”, write poor-quality infrastructure code, that has no tests and no validation. That’s because Project Roadrunner is in an Agile Hallucination, so managers -and of course the Mighty Scrum Masters- micromanage these “system people” as they do to “software people”. This made them write code as fast as they can, just to finish in time in the current sprint.
- Apart from there is an Agile or non-Agile culture, maybe the System Engineers/SREs or “DevOps Engineers” just don’t care about the tests, or validation, because they are not Software Engineers! They are not developing applications in the end(!)
- No real collaboration between Dev and Ops. No single source of truth that is shared across teams.
- …
Do you think they can solve these problems? Do you think to focus these problems just on the organizational level will fix all? Or should we focus on the “people” and start the transformation from there?
System Craftsmanship
As we discussed before, Software Craftsmanship came out as a response to the problems of the implementation of Agile. Not the Agile itself, but the implementations were so bad that as Sandro Mancuso said once “Many Agile projects are now, steadily and iteratively, producing crap code.”
Software Craftsmanship is a mindset change that leads you think like a Crafter from the old times, who loves his/her profession, who only cares about quality and beauty of his/her product, and the “value” it gives to public.
The same mindset and ideology, just because of the similar problems we have in DevOps; like the ones we had while implementing Agile, can be implemented to DevOps culture that is inevitably in a Cloud Native Era right now.
I wanted to call this ideology System Craftsmanship.
System Craftsmanship’s purpose is to put the passion and craft into DevOps culture and raise the bar even further to create more value by caring about quality and profession in the DevOps ecosystem.
System Craftsmanship is not a “yet another Craftsmanship”. It is an extension of Software Craftsmanship, that is, in pursuit of the items that Software Craftsmanship Manifesto has, I’ve found the following extension of the first item indispensible:
Not only well-crafted software, but also well-crafted infrastructure
This means that by accepting all the things that Software Craftsmanship reveals, all the principles and values, expanding its boundaries from “software people” to “system people” and encourage them to be System Crafters to gain a better DevOps culture.
Like Software Craftsmanship, System Craftsmanship -as a matter of course- has no practices but benefits from a lot of technical practices and patterns that come from craftsmanship or apprenticeship culture.
For example, Clean Code and SOLID are two of the practices that Craftsmanship movement benefits. From the Infrastructure of Code (IaC) perspective, you have to create clean infrastructure code to create clean infrastructure. In his book Infrastructure As Code, Kief Morris agrees with us by saying the following:
To keep an infrastructure codebase clean, you need to treat it as a first-class concern. Too often, people don’t consider infrastructure code to be “real” code. They don’t give it the same level of engineering discipline as application code.
Design and manage your infrastructure code so that it is easy to understand and maintain.
Besides, he discusses other practices like code review, pair programming, automated testing by saying: “Follow code quality practices, such as code reviews, pair programming, and automated testing. Your team should be aware of technical debt and strive to minimize it.”
Do you recall the problem that Project Roadrunner System Engineers face? They had some low-quality issues that damage the DevOps environment. They either had no time to follow the best practices to write maintainable code or did not be in need of to do any. With System Craftsmanship mindset, they should be aware of they have to produce well-crafted code in order to create a well-crafted infrastructure. They have to implement CI/CD, maybe do Test Driven Development, write some specifications about their own code to be clean, and keeping it clean, which also leads to a collaboration culture. As it comes to collaboration they can even do Pair Programming, both for improving the quality of their code and collective ownership. This collective ownership solves the responsibility of the resource A and B problems they had. Because by implementing a “single source of truth” mechanism and collaboration, everybody will be responsible from everything mutually.
Apart from the technical practices, Craftsmanship mindset improves professionalism manner. With expanding a known terminology to “Software Craftsmanship” to something new “System Craftsmanship” developers will understand that this is not just a software or application matter, this is a system-wide thing to implement because -as we discussed before- we are in a Cloud Native Era right now and infrastructure transformed to code, and cloud transformed to code, so it is inevitable to application developers to just write application code. That application is a Cloud Native Application right now which is a piece of the Cloud, has pieces from the Cloud.
Remember the application developers of the Project Roadrunner, who don’t want to write cloud-related code within the project. Does the definition above fix this problem and fix the responsibility issue? Responsibility is just a matter of professionalism in many cases, so in this case, it just needs a bit of professionalism from the System Craftsmanship culture.
As it is about professionalism and passion, having his/her job as a profession requires to follow a bunch of Apprenticeship Patterns to practice.
For example, an SRE can be a better SRE by finding mentors for herself/himself, work with them, or just follow them by doing pairing sessions with them. This will improve that SRE’s way of working. Remember the famous Zen poem that Eric S. Raymond also mentions in his famous article How to Become A Hacker:
To follow the path:
look to the master,
follow the master,
walk with the master,
see through the master,
become the master.
Or what about exposing one’s ignorance. It is all about putting your ego under your shoes. It sounds quite painful, right? Some of the Software Developers do this because they are already aware of this craftsmanship movement. But how about “system people”?
Let’s take System Administrators for example. We discussed this -maybe in a joking way- that they have the “God” access to the systems. They can do whatever they want in a system because of their privileges. Because of this, some of these people may have a kind of big ego and it is very hard for them time to time tell what they don’t know. Same for the Security Administrators/Engineers. Because of their duty, they have to ask every action’s reason, so this makes them feel “in control” of the flow just like it is for the System Admins. Well, it is not their fault, it is just human nature, but it can be fixed with practices like “exposing the ignorance” or do activities like “pair programming” or “code review”.
Notice that at the beginning of the Cloud Native Era, these people became a little bit “shocked” because of the adaptation of the cloud. “A place where you can define everything as a code! How will I keep the privileges on myself/my team” or “how will I keep this component secure? It is not even on my network topology”. Collective Ownership -doesn’t mean that everybody can change security configurations-, Single Source of Truth and Code Reviews -by exposing the ignorance-, and maybe more. These are all they have to do.
Conclusion
I believe all these patterns and practices, that originally come from many Agile practices like Extreme Programming or others like Clean Code, or Apprenticeship Patterns are beneficial for System Engineers, System Admins, Security Admins/Engineers, SREs and many others who I kept calling “system people” in this long-ish article.
And I hope these practices and patterns, and the “Craftsmanship” mindset, which I believe raised the bar of software development for many years, will raise the bar even further in this Cloud Native Era, for the people and communities who are passionate about DevOps and Infrastructure as Code and for the companies who are in a plan of (or in the middle of) a DevOps transformation and need to give it a right start with focusing on the “people” first.
For this, I created a manifesto that extends Software Craftsmanship Manifesto. Feel free to sign it!