Introduction to Software Craftsmanship
•
0 likes•117 views
This is a high level view of software craftsmanship. The presentation describes what software craftsmanship is, and why do we need it. It highlights the shortcomings of Agile, and how software craftsmanship can address these. I am publishing a series of presentations on the topic. While this is an introductory slide, the upcoming ones will talk about the technical aspects of it such as code smells and refactoring.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Introduction to Software Craftsmanship
Similar to Introduction to Software Craftsmanship (20)
More from Rajat Singla
More from Rajat Singla (8)
Recently uploaded
Recently uploaded (20)
Introduction to Software Craftsmanship
- 3. We are adopting Agile and now things will be GREAT … let the Agile Transformation begin
- 4. But…
- 5. Is it enough? SMALL PROJECTS MEDIUM PROJECTS LARGE PROJECTS ALL PROJECTS 44 7 3 11 +14 +20 +15 +28 % INCREASE IN SUCCESS Waterfall Agile SMALL PROJECTS MEDIUM PROJECTS LARGE PROJECTS ALL PROJECTS 4 11 23 9 -7 -14 -19 -20 % DECREASE IN FAILURE Agile Waterfall
- 6. Business IT What is AGILE? TEAM DAILY STANDUPS USER STORIES ITERATIONS QUICK DELIVERY
- 7. Business IT TEAM DAILY STANDUPS USER STORIES ITERATIONS QUICK DELIVERY We are spending huge amount of time and resources in … processes, people, interactions, team building, ecosystem, reducing waste and bureaucracy… DO NUMBERS JUSTIFY THIS?
- 8. Many Agile projects are still, steadily and iteratively, producing crap mediocre software. The Agile Hangover
- 9. Business IT WHAT ABOUT SOFTWARE QUALITY? Are processes and interactions more important than the actual product? IS OUR SOFTWARE AGILE?
- 12. THE INVISIBLE THREAT CODE QUALITY TIME PER FEATURE
- 14. POOR ROI NOT GOOD ENOUGH SOFTWARE CUSTOMER COLLBORATION INDIVIDUALS AND INTERACTIONS AGILE MANIFESTO
- 16. POOR ROI NOT GOOD ENOUGH SOFTWARE US AND THEM ATTITUDE ISOLATED DEVELOPERS AGILE HANGOVER
- 17. POOR ROI WELL CRAFTED SOFTWARE US AND THEM ATTITUDE ISOLATED DEVELOPERS AGILE HANGOVER
- 18. POOR ROI WELL CRAFTED SOFTWARE US AND THEM ATTITUDE ISOLATED DEVELOPERS AGILE HANGOVER It is not about writing beautiful code It's about continuously delivering value by not writing stinky code but a well-crafted code
- 19. STEADILY ADDING VALUE WELL CRAFTED SOFTWARE US AND THEM ATTITUDE ISOLATED DEVELOPERS AGILE HANGOVER
- 20. STEADILY ADDING VALUE WELL CRAFTED SOFTWARE US AND THEM ATTITUDE ISOLATED DEVELOPERS AGILE HANGOVER It is not about quick delivery and fixing bugs It is about adding business value by avoiding bugs
- 21. STEADILY ADDING VALUE WELL CRAFTED SOFTWARE US AND THEM ATTITUDE COMMUNITY OF PROFESSIONALS AGILE HANGOVER
- 22. STEADILY ADDING VALUE WELL CRAFTED SOFTWARE US AND THEM ATTITUDE COMMUNITY OF PROFESSIONALS AGILE HANGOVER It is about leading by example and showing how we can be better It is not just about building the right things. It is also about building the things right
- 24. STEADILY ADDING VALUE WELL CRAFTED SOFTWARE PRODUCTIVE PARTNERSHIPS COMMUNITY OF PROFESSIONALS SOFTWARE CRAFTSMANSHIP Software Craftsmanship is all about putting responsibility, professionalism, pragmatism and pride back into software development
- 25. RELATIVE PERFORMANCE TIME ORIGINAL PERFORMANCE SOFTWARE CRAFTSMANSHIP INVISIBLE BENEFIT THE INVISIBLE BENEFIT
- 26. SO WHAT IS A QUALITY SOFTWARE? A software which is not only developed using agile methodologies, but is itself an Agile Product CODE QUALITY TIME PER FEATURE
- 27. Agile and Software Craftsmanship complement each other and both are necessary Agile processes assume technical excellence and a professional attitude Software Craftsmanship builds on this technical excellence and professionalism and takes it to a whole new level AGILE IS NOT NECESSARY? IT IS ABSOLUTELY NECESSARY
- 28. As aspiring Software Craftsmen we are of professional software development by practising 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 ofprofessionals Not only customer collaboration, but also productive partnerships
- 30. Adding value through practice Automated Tests TDD Boy Scout Rule/ Refactoring Pair Programming Continuous Integration MASTERING PRACTICES IS HARD THAT IS WHY WE PRACTICE…
- 31. Software Craftsmanship is not enough to guarantee the of a project, but the lack of it can be the main cause of its failure
- 32. Herbert de Souza (Betinho)
Editor's Notes
- This presentation provides a high level view of software craftsmanship and the dire need to establish it on top of Agile as core software development methodology.
- We are making a big transition from traditional SDM to adopting Agile. The primary reason behind it is to increase the value of the software product provided to business.
- Everyone is really excited and optimistic about the journey, and hopefully we get the results we expect from this transformation. We all are working hard for it and will definitely party harder upon its success
- A recent study by Vitality Chicago, a consultancy firm has revealed the following metrics when it comes to project success and failure rates for the two development methodologies. Say we look at the failure rate for large projects, the numbers come down to 23% in Agile from a whopping 42% in Classic SDM. Which is almost a 20 percentage Points improvement. BINGO!!!
- Now, lets look at these numbers from a different perspective. The graphs are plotted showing the percentage increase in project success rates and percentage decrease in project failure rates for Agile over Waterfall. If you think about it, is 23% failure rate for Large Projects good enough? Is 28% increase in success rate over waterfall for all projects really high? Is it enough? We can clearly infer, almost one-forth of the projects developed using Agile are still failing and therefore need to be decommissioned and replaced with a new software in a few years.
- When we talk about Agile, what are the first things that come to your mind? (My answer is mentioned by texts highlighted in blue with the related pictures)
- Agile is not just a methodology, it’s a way of life. We cannot do Agile, we can only be agile. The language doesn’t make sense otherwise. Thus we are spending a lot of resources in trainings and adopting Agile practices. But the numbers we just saw tell us that we are still delivering only a mediocre product to our business 1 out of 4 times. A product that has pretty good chances of failing the customer expectations in the longer run, if not immediately. Do the numbers we saw some time back justify this huge spending?
- This is exactly what we call the Agile hangover. Many companies who have already adopted Agile are currently facing this hangover. That is, the customers are still not satisfied with the product.
- One of the major reasons identified for these project failures is the inability to deliver a quality software. We are spending huge amount of time and resources in processes and interactions, making ourselves agile – which is really great, but is there any use of it if the actual product that we are delivering is not agile? In the end a quality software is what will earn us money. Not this culture. The culture is just an enabler, a journey, a way of achieving this quality. LETS TRY TO FINIGURE OUT THE REASONS FOR THIS HANGOVER/MEDIOCRE SOFTWARE PRODUCTION
- If we take a look at the agile manifesto, we find out that there are the four pillars of agile. The manifesto is great and very well written. We might have all seen this a lot of times. It emphasizes on working software over comprehensive documentation, responding to change over following a plan, individuals and interactions over process and tools and customer collaboration over contract negotiation. These pillars look really strong. But even Achilles had a weak heal.
- Working software The idea of quick working piece of software often overlooks the idea of a flexible software. To solve a software development problem, we break it down to smaller manageable chunks, work on them and then glue it all together at the end. The efficiency of solving a problem boils down to how small these chunks are. Now if we are breaking our software into large chunks to save time of development, and if we want to modify or remove a piece of code inside a chunk, overtime it becomes almost impossible to do so without breaking it. So the solution is to replace the whole chunk which consumes a lot of time. So if you think about it, we are not really saving time by developing these large chunks. Lets try to plot a graph between code quality and time per feature. Code quality is defined by how small you classes and methods are. If we don’t take care of the code quality, we are basically inviting an invisible threat to our software
- What do we mean by a “quality software”? Take a look at the graph. What do you understand? As the code quality decreases, the time per feature increases. And the effect is exponential. By not maintaining code quality, we are inviting an invisible threat to our software!
- In the present scenario, as we target to deliver workable chunks of our software in every iteration every two weeks, the code quality often takes a back seat. In short, solving a problem stems down to 2 things: How we break the problem into manageable, easily understandable chunks How we glue together these chunks after working on them. Doesn’t matter if it is software developments or mathematics or physics or for that matter any field of studies. Does the software we are developing really fit into this philosophy?
- Responding to Change Working under a changing landscape often compels us to overlook things that seem less important at present. These things mostly tend to accumulate as debt which is never taken care of. The effect of any kind of debt is compounding and will ultimately make you bankrupt. The agile methodology has a good solution for delivering a quality product at a decent velocity- which is the technical backlog. So ideally, we try to deliver continuous business value at a good speed and software quality is worked upon in the technical backlog. But in the real world scenario, this is rarely the case. And this leads to the scenario illustrated by the graph we saw earlier In most real time projects, developers see refactoring and clean coding as items to be put into a bucket for taking care of in future, in “free time”. There will never be a “free time” if you don’t find it or ask for it. We are in process accumulating an invisible threat– a technical debt. Which will haunt us for the entire lifecycle of the project and beyond. Software project requires huge investments. In beginning if there are say 50 developers working on a project, by the time of its delivery and maintenance, we would want to reduce that count as much as possible so that we can get a good return of value for our investment. But if code quality is not maintained, as we saw, the time/feature will increase invariably. The software will not be agile enough to be maintained or modified over a longer time. It would still need multiple people to the same job that could have been done by a single person had the software been truly agile. In Other Words… We are constantly changing our software based on customer feedback. The pressure of this forces the code quality to take a back seat. We put tasks such as refactoring into technical backlog which is biggest contributor for technical debt. Its basically a bucket that stinks so much, no one wants to put their hands into it. The effect of this is compounding and overtime it takes almost a month to implement a single feature. Where is the return of investment we all were hoping for?
- Isolated Developers Working and developing something is hard. A developer knows how to solve a problem. How to do the right things. But what about doing things right? Continuous and quick delivery often results in people trying to solve problems by hook and crook. The solution becomes more important than the steps involved in achieving it. What if another person faces the same problem and tries to understand your solution? People often include developing, testing, building and deploying as the major factors when calculating cost of software development. (in decreasing order of cost). What is overlooked is the cost of understanding code, which more often than not sits right at top of sucking money out of your pockets. Understanding a piece of code written by someone else, or even written by you is what consumes most of the time. The solution is always easier. In longer run, this will hinder quick development. You will be basically stuck in a catch 22 situation. The reason you overlooked the steps for a solution was quick delivery, and the same reason is now responsible for delivery delays!! In Other Words… We want individuals to work together and interact. But what are we doing to facilitate it? Understanding a low quality code is very difficult and it is even more difficult to change it. Developers become reluctant to help each other because each of those tasks would take so much time and they are afraid to touch the code. Moreover have there own huge tasks to take care of. So individuals start working in isolation and whole point of interaction is lost.
- Customer Collaboration Collaborating with customers and including their feedback is a really great idea. It ensures we do not miss any requirement, and provides us with a quick feedback loop. Makes us truly agile. But don’t we still consider customers as our employers? If not, then why do we think our job is to deliver what they ask for quickly in response to their requests? What about making sure the product/software stands the test of time? Are we as developers also the stakeholders? If yes, then would we really want something so fast that we are ready to compromise on the quality? In Other Words… We don’t just want to collaborate with the customer and deliver what they want. We also need to make sure what we deliver is quality and should ask time for it. Customer is not just an employer who pays.
- Well Crafted Software What about developing a software that we are not afraid to touch. A well crafted software that is easily relatable to business requirements. That reflects the context of problem and its corresponding solution. Which on click of a button gives you instant feedback of its functionality. A software where if a developer sitting across the world makes a change, it gives every other developer an instant feedback of it success or its failure. Wouldn’t that software be truly agile? Will it not add value to the business? A clean refactored code, development driven through tests provides you exactly that. What more, as a side effect we get a safety net and an executable documentation of the software!!! (TDD Specs)
- Instead of a poorly written code, if we write a well crafted software which is refactored regularly to make sure it is easily understandable and some standard size of methods and classes is maintained, and which is developed using TDD to make sure it is flexible and all the safety nets are in place and so it wont break, people will no longer be afraid to touch it. With just one click of button if we can easily test previous and newly added functionalities and get an instant feedback, wouldn’t we be adding immense business value?
- Steading Adding Value Agile is not about adding features, fixing bugs and delivering a working piece of software. These are just the processes. It is in its true essence about delivering value to the customer not only in short term but in long term for an indefinite amount of time (ideally). That would be a true return for investment for anyone. Finding bug quickly is great. But it is not adding value in any way. At best it ensures we are not losing value. Avoiding bug is what truly adds value. After every iteration we prepare ourselves for a new feature/user stories. Do we make sure the system is ready to accept changes? We make ourselves agile. What about the system? Before starting a new iteration, always make sure you make your system ready for a change. REFACTOR! At the end of the iteration, make sure your system is still agile and works. TDD!
- If the code is flexible, we can modify it throughout its lifecycle and deliver feature quickly for a long amount time. Wouldn’t that provide a good ROI? As a side effect of using TDD, we are essentially avoiding bugs which is in true sense adding business value. Developing and then finding bugs is basically saving value, not adding one.
- Community of Professionals We not only want good developers working together, we want true professionals. A professional always follows sets of discipline and minimum standards of behaviors treating development as a real profession and not just a task. Professionalism is not wasting time on writing excellent code, but writing excellent code without wasting time! Development is not just a job, its an art. For any artist to succeed, he/she should be well equipped with the tools. A musician practices 100 times before his final performance. Any artist for that matter does that. Why should not a developer if development is considered an art. Practice -> attend code retreats. If a developer is a professional, he is no longer just a developer. He is a SOFTWARE CRAFTSMAN!
- We are facilitating interactions by making tasks less difficult. Coding should not be treated as a skill, but an art. And development is not just as a task but a profession. We should be aiming at nurturing professionals and not developers. A developer would know how to do the right things, but only a professional would know how to do those things right. Some minimum standards and rules should be maintained for development.
- Productive Partnerships Treat yourselves as a business partner rather than an employee delivering what is asked for. Ask yourself this question – are you really proud of the code you are writing? If yes, you truly consider yourselves as a partner/a stakeholder of the project. If no, you need to sort out you life priorities. Our goal should be not just to deliver but deliver with great quality. Helping business is helping ourselves! ALL THIS TOGETHER IS THE TRUE ESSENCE OF “SOFTWARE CRAFTSMANSHIP”
- Lets not just collaborate with the customers but also own the product we are delivering. Quality standards should be maintained and customer should be treated as a partner and not just an employer. If we are owning the product, would we be wanting something so fast that we are ready to compromise on quality? These are the four pillars of “SOFTWARE CRAFTSMANSHIP” that try to solve the shortcomings of Agile.
- We talked about the invisible threat. Look at what software craftsmanship can bring on our plate. AN INVISIBLE BENEFIT! Initially, when we are performing tasks such as refactoring and writing tests, it will take time. It would feel like we are wasting time doing the less important things, and not giving importance to the actual problem in hand. This is the time represented by the curve below the straight line. You would feel like jumping directly to the solution – by writing code using hooks and crooks. And we all saw how this turns up. An exponentially increasing time/feature! (refer the invisible threat slide) Stick with these procedures patiently, and in no time you will start seeing the benefits. Your curve will turn in the opposite direction, and then there is no end to it’s exponential growth! Your usual code would bite dust in front of this well crafted software! Isn’t the difference immense? Isn’t it too good to overlook? And all it takes is a little amount of patience and good handle on professional practices as defined by software craftsmanship.
- So, what actually is a quality software? A software which is not only developed using agile methodologies, but it itself is an Agile product. A quality software is crafted to accommodate customer’s changing needs. It is far more easier to add new features and functionalities for several years. With a quality software, we can ensure our organization doesn’t face the agile hangover as others.
- Agile is great! There is no doubt to it. But if are aiming for Mount Everest of all mountains, we should really be looking at building on this foundation using software craftsmanship. Neither is strong without the other. Software craftsmanship when combined with Agile practices leads to a Agile product thereby addressing the Hangover issue…..
- The software craftsmanship manifesto tries not to replace the pillars of Agile, but raises the bar by building its own on top of Agile.
- Each of these practices make a software developer a software craftsman. These practices will be discussed in detail in subsequent sessions. You can explore these meanwhile on internet. The most important out of these in my opinion are refactoring and TDD.
- When I ask people the reason to why they have not yet embarked on this beautiful journey, the most common response I get is – ”The others in my team are not following this. How can I alone make a difference” I usually tell a story to them for motivation. Hope this helps you! This is a story by famous French sociologist – Herbert de Souza. ****BEGIN**** One day, a forest catches fire. All the animals decide to leave their homes and run. While the animal are running, one of the monkeys sees a bird trying to extinguish the fire by collecting a drop of water in its beak from a nearby lake and spraying it over the blistering fire. The monkey starts laughing at the bird. “What a fool! You think you can extinguish the fire alone!” – exclaims the monkey trying to mock the bird. The bird ignores it and continues with the task. Bewildered by the bird’s dedication, the monkey goes to the bird and tries to convince it to leave its home. The bird refuses to do so. It then asks the bird – “Friend, all your efforts will go in vain. It is simply not enough to extinguish the fire. Why are you going through so much pain when others are not doing anything? You should follow others and run for your life. What the bird says next completely changes the monkey’s approach towards life – “Friend, it does not matter whether others are trying or not. What matters is whether I can make a difference! Even if there is a slightest of chance that my efforts can change the outcome of the situation, I will not shy away from it. At the end of the day, I don’t want to look into the mirror with my eyes down, knowing I did not even try!, and thinking what would have been had I did!” Startled by the bird’s attitude and feeling ashamed of itself, the monkey started helping the bird. Similarly, the other animals (feeling ashamed of themselves looking at the bird’s efforts) started joining too! The enthusiasm, hope and positivity spread in the whole animal community, faster than the forest fire itself, and in no time the fire was extinguished! ****END**** My Opinion - Give it a try! Don’t think about the outcome. It is my promise to you that it will definitely make a difference. IT ALWAYS DOES!