Agile
In February 2001, 17 people came together to a ski resort in Utah to discuss a better way to develop software. They are the representatives of Scrum, Extreme Programming, Feature Driven Development, Crystal Methods, DSDM.
Because there are so many software development methodologies that look better than the Waterfall model, but there is no consensus among these models. These people have come together to find a common alternative to Waterfall.
And they wrote a manifesto known as the Manifesto for Agile Software Development, and that's when the Agile Alliance was formed and began to become dominant in software development.
As a result, many companies looked at Agile, and the Agile era began from there. Many companies see Agile as a charm, and any software project that uses Agile will work like a charm. Activities like daily Stand-up meetings, iteration, user stories appeared everywhere, and they gradually became a symbol to say that "Our company is doing Agile."
Agile Hangover
Ten years after the rise of Agile, many companies experienced a lot of pain and lessons from the Agile transformation, and they were starting to ask the question: "Is it the right thing to use Agile?"
Were they drinking too much Agile spirit and forgetting that the real problem which should be solved is still there.
Let's imagine one day you wake up in the morning with a headache and realize that after the agile transformation efforts, your project is still the same as before.
The only difference now is that you can quickly see the results of your development every two weeks (or less) and can check how well you've done the software.
But the old problems are still there. More technical debt occurs in Agile projects, where we cut corners using less effort to solve a long-term problem. When we don't have enough time to complete the increment in the iteration, we start to break the principle and cause the cobra effect.
What exactly is Agile?
Agile is all about quick and short feedback loops.
When you have a quick and short feedback loop, you will be able to inspect new information, which can be risky information that you may not have known about before. As a result, you can react or revise the source code continuously. So the faster and shorter the feedback loop, the better your chances of becoming Agile.
Agility doesn't solve the problem. Agile exposes the issues, shows you what's wrong, and then you have to decide for yourself what to do to solve the problem, and that's Agility.
Software Craftsmanship
The software experts perceived that something was wrong with Agile, and they tried to define what was wrong together. Agile is essential, but it's not enough. It needs craftsmanship, so they developed Manifesto for Software Craftsmanship.
Through this work, they 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
In a nutshell, the manifesto puts what was stated in the Agile manifesto on the left and adds some important things on the right. That means we don't just do things on the left side, and we also need to do something on the right side.
How it's done is as important as having it done.
Good software is not just working software. Good software is well-crafted from within its source code, which means any software craftsman can easily understand it and process the source code.
A developer team won't lose their pace on such software, no matter how old the software is (3 years, five years, or ten years longer)
New developers prefer to delete old software and rewrite a new one with better technology and cheaper cost. However, any new software will become old, and only steadily adding value makes software up-to-date. Moreover, from investors' perspective, they have spent too much money on the software project. They want to see the project succeed instead of deleting it and reinvesting.
Agile vs. Craftsmanship
Agile: Are we coding the right thing?
Craftsmanship: Are we coding the thing right?
Agile will help a lot if you want to answer the question, "Are we building the right thing?". In Agile, we have a feedback loop, so we get feedback from the stakeholders, and that helps us reprioritize the user stories so that the important part could be done first, so that's where Agile will shine.
When trying to answer the second question, "Are we coding the thing right." Thanks to Agile, we soon know what is right and wrong. But after knowing that, will we have enough craftsmanship to handle the problem in the right way? That's where Software Craftsmanship will shine.
The community of professionals
Community of professionals is all about sharing and mentoring.
Learning from each other is by far a good way for us to become better (Besides googling and self-learning). Remember to double-check.
Writing blogs, contributing to open source projects, making our code publicly available, becoming part of our local communities, and pairing with other developers are some of the ways we can contribute to the greater good of our industry.
Apprentice
Did you understand what I said?
If you have to do it again, would you know how to do it?
After that, he closed my merge requests.
Then he turned to me and said I had to code it again?
And then, when I went down a bit, I realized that after all these years, I was coding myself. It was the first time someone took the time to teach me, to show me how to be proud of my code.
This blog is for a software craftsman who taught me Software Craftsmanship, and he didn't even mention this concept when he taught me.
References
Software Craftsman, The: Professionalism, Pragmatism, Pride (Robert C. Martin Series) 1st Edition
Manifesto for Software Craftsmanship