Notes on Sandro Mancuso — Software Craftsmanship @Talk

Originally published at https://eduardstefanescu.dev/2020/05/05/notes-on-sandro-mancuso-software-craftsmanship-talk/.

Talk: https://www.youtube.com/watch?v=9OhXqBlCmrM

Highlights

• The attitude of software craftsmanship should be: passion, career ownership, "perfect" practice and boy scout rule;
• We should produce more to receive more, and not waiting to receive something from our company because we are owning our career;
• When we are working on an organization don't excuse, like "No one does that, so I'm not going to do it also". Either you do it or you leave the company;
• A good developer is not Java, C# or Ruby developer. A good developer is a developer. We use the tools that we find useful for our job;

Notes

• In February 2001, 17 people meet in a ski resort in Utah to create an Agile Methodology. The people there were people like Uncle Bob, Martin Fowler;
• In agile processes and tools became more important than technical practices and excellence;
• In the beginning there, were more "shits" scrum masters than developers. Some of those scrum masters know nothing about software development;
• Without agile processes there will be no good delivered software;
• "Insanity: doing the same thing over and over again, and expecting different results" --- Albert Einstein;
• When we are under pressure we tend to cut corners, by thinking that we deliver faster, even when the managers do not push us;
• We think that we don't have, but we do. Is our fault that we think that we don't have, and by doing so, we are delivering low-quality products;
• Agile is about shorting the feedback loop;
• By reacting to that feedback is what gives us the agility;
• Agility is reacting constantly to feedback;
• We don't do agile, because it's not logical. We are agile;
• The most important deliver is the software itself;
• To have good software, we need to have a good process;
• Businesses are hostages of their software;
• The business will move as fast as we developers create or change software;
• As the software grows and no attention paid to the quality of it, the thing is that will become much harder;
• In agile we are splitting stories, but delivering all the user stories doesn't mean that the delivered software is it the required one or at the quality that we want;
• Every bug found by the QA team, is something we developers haven't done; QA should contribute in defining user stories and read newspapers;
• We don't want software that breaks, we want software that makes us happy to work with;
• Software that makes us happy is not about beautiful code, but instead is easy to maintain, to change and to test;
• For him, the software is an asset, a huge investment that we need to care about because costs a fortune;
• It doesn't matter the contract type, the relationship shouldn't be employer and employee, it should be a partnership;
• We are not keeping the heads down and doing what we are told as in a factory because we are creative people;
• Every craftsman or professional that are working on a project, he or she should strive to make it a success;
• Software craftsmanship in his opinion is professionalism in software development;
• Feedback in software development is based on XP Practices;
• We should not need the authorization to use practices that improve the quality of the product, like Unit Tests, we should just do it;
• Managers are interested in value, we are adding value through practices like: TDD, Continuous Integration, Refactoring, Pair Programming, and Automated Tests;
• When we are talking about business, we should not discuss practices, instead, we should discuss about the value;
• On a new project, at the beginning we will be slower until we will be better and faster;
• Quality depends on who is doing the job, not the time or money;
• "Developers are not football players" and should not cost millions of euros to create quality software;
• Quality cannot be measure and defined precisely because there are so many variables, it means different people, in different places and different points in time;
• Code coverage is a dangerous metric and should never be used as a target or management tool because the percentage of tested code is not the same as the percentage of the executed code. For example, we can have 80% tested code from a 50% executed code;
• "How it is done is as important as having it done" --- Eduardo Namur;