The document discusses the history and principles of software craftsmanship. It outlines how software craftsmanship values not only working software but well-crafted software, and focuses on steadily adding value through a community of professionals. The document presents the Manifesto of Software Craftsmanship and its emphasis on technical excellence, good design, automation, clean code, and continuous improvement.
Software Craftsmanship vs Software Engineering (Lightning Talk)Andy Maleh
The recent emergence of the Software Craftsmanship movement in the last decade has been accompanied with quite a bit of confusion on what the movement is exactly about and whether it adds any value beyond previous software development movements, such as Agile and Software Engineering. In this short talk, Andy Maleh will define Software Craftsmanship, compare and contrast to Software Engineering, and provide examples on how both disciplines are playing out at the Groupon software development environment.
This is the English version of my talk about agile software development practices at Agile Talks seminars in Ankara, Turkey. I tried to focus on the nature of software development and figure out the development practices that let us build software in natural way.
DevOps & Technical Agility: From Theory to PracticeLemi Orhan Ergin
This is the content I presented in meetups for giving brief information about Agile, Devops, Software Craftsmanship, Opertions and Continuous Delivery and their connection with each other.
Software Craftsmanship vs Software Engineering (Lightning Talk)Andy Maleh
The recent emergence of the Software Craftsmanship movement in the last decade has been accompanied with quite a bit of confusion on what the movement is exactly about and whether it adds any value beyond previous software development movements, such as Agile and Software Engineering. In this short talk, Andy Maleh will define Software Craftsmanship, compare and contrast to Software Engineering, and provide examples on how both disciplines are playing out at the Groupon software development environment.
This is the English version of my talk about agile software development practices at Agile Talks seminars in Ankara, Turkey. I tried to focus on the nature of software development and figure out the development practices that let us build software in natural way.
DevOps & Technical Agility: From Theory to PracticeLemi Orhan Ergin
This is the content I presented in meetups for giving brief information about Agile, Devops, Software Craftsmanship, Opertions and Continuous Delivery and their connection with each other.
Learn about problems of mature teams, about myths of pair programming and pair synergetic behaviors. How to implement pair programming in your company and how we did it in DaftCode.
Professional Software Development, Practices and EthicsLemi Orhan Ergin
This is the slides of my talk in Marmara University Faculty of Engineering to undergraduate students. It is mainly about professionalism in software development, agile, scrum, test driven development, practices and ethics
How Do You Build Software? Software Engineering Practices of an Agile DeveloperLemi Orhan Ergin
These are the slides of my latest talk about agile software engineering practices in Etohum's Software Developers Day. In my talk, I am trying to figure out how to build software by obeying the rules of the nature of software development.
Integrating hardware development processes (using the Waterfall method / V-model) and Agile software development. This presentation explains the basics of the V-model and how it has evolved into an iterative model, but also tells you about managing hardware and software lifecycle processes in a single release. Then, a live demonstration shows you how to integrate these lifecycles (xLM) in practice.
TDD is the elengant way of designing software. People scares from it so much, because software design is hard and it requires discipline. In this talk, I tried to describe what TDD is from software design perspective.
Tried putting things in the deck that I learnt about Extreme programming in XP Conference held in Bangalore. I have tried to keep it at very high level added with light moments, so that it doesn't getting boring and makes sense for most of us
Towards FutureOps: Stable, Repeatable environments from Dev to ProdNaresh Jain
Modern human history is a story of humans inventing new tools to do more with less. "Doing more" has allowed most of us to no longer worry about producing our own food, collecting water, planning long journeys, etc. Instead, we’re able to specialize, buy what we need for less, and to some extent explore ourselves a lot more.
We're far from done, and of course humanity is far from perfect. In this talk, Mitchell Hashimoto discusses the role that automations and computers play in building a brighter future.
More details: https://confengine.com/agile-india-2017/proposal/3618/towards-futureops-stable-repeatable-environments-from-dev-to-prod
Learn about problems of mature teams, about myths of pair programming and pair synergetic behaviors. How to implement pair programming in your company and how we did it in DaftCode.
Professional Software Development, Practices and EthicsLemi Orhan Ergin
This is the slides of my talk in Marmara University Faculty of Engineering to undergraduate students. It is mainly about professionalism in software development, agile, scrum, test driven development, practices and ethics
How Do You Build Software? Software Engineering Practices of an Agile DeveloperLemi Orhan Ergin
These are the slides of my latest talk about agile software engineering practices in Etohum's Software Developers Day. In my talk, I am trying to figure out how to build software by obeying the rules of the nature of software development.
Integrating hardware development processes (using the Waterfall method / V-model) and Agile software development. This presentation explains the basics of the V-model and how it has evolved into an iterative model, but also tells you about managing hardware and software lifecycle processes in a single release. Then, a live demonstration shows you how to integrate these lifecycles (xLM) in practice.
TDD is the elengant way of designing software. People scares from it so much, because software design is hard and it requires discipline. In this talk, I tried to describe what TDD is from software design perspective.
Tried putting things in the deck that I learnt about Extreme programming in XP Conference held in Bangalore. I have tried to keep it at very high level added with light moments, so that it doesn't getting boring and makes sense for most of us
Towards FutureOps: Stable, Repeatable environments from Dev to ProdNaresh Jain
Modern human history is a story of humans inventing new tools to do more with less. "Doing more" has allowed most of us to no longer worry about producing our own food, collecting water, planning long journeys, etc. Instead, we’re able to specialize, buy what we need for less, and to some extent explore ourselves a lot more.
We're far from done, and of course humanity is far from perfect. In this talk, Mitchell Hashimoto discusses the role that automations and computers play in building a brighter future.
More details: https://confengine.com/agile-india-2017/proposal/3618/towards-futureops-stable-repeatable-environments-from-dev-to-prod
COURSE IS NOW FULLY AVAILABLE AND LIVE HERE: https://goo.gl/gVukvc
What you will learn in this second section
Software Testing Methodologies. Waterfall, V-Model and Iterative
What is unity or component system testing
What is integration, system and acceptance means
Differences between functional and non-functional testing
What is a structural testing
Change-related testing
Maintenance testing
Access my blog for much more material and the mock exams.
www.rogeriodasilva.com
Six Principles of Software Design to Empower ScientistsDavid De Roure
Keynote talk for Workshop on Managing for Usability:
Challenges and Opportunities for E-Science Project Management, 10-11 April 2008,
OeRC, University of Oxford, UK
You will learn why naming is really difficult if done right, why coding and style guidelines are crucial, code structuring, exception handling and why other elements of coding often define the tipping point between success and failure of projects. Following the principles of software craftsmanship will allow you to end up with better maintainability and extensibility of your software and the success of the project in the end. All 3 Clean Code presentations provide great value by themselves, but taken together are designed to offer a holistic approach to successful software creation.
Why writing Clean Code makes us more efficient Over the lifetime of a product, maintaining the product is actually one - if not the most - expensive area(s) of the overall product costs. Writing clean code can significantly lower these costs. However, writing clean code also makes you more efficient during the initial development time and results in more stable code. You will be presented design patterns and best practices which will make you write better and more easily maintainable code, seeing code in a holistic way. You will learn how to apply them by using an existing implementation as the starting point of the presentation. Finally, patterns & practices benefits are explained.
This presentation is based on C# and Visual Studio 2013. However, the demonstrated patterns and practice can be applied to every other programming language too.
Note: Moving forwards this presentation will be updated with the latest version of the slides for the last event I did the presentation instead of creating new separate slide decks here on SlideShare.
Presentation dates and locations:
2015-06-27 SoCal Code Camp - San Diego, CA
2014-11-14 SoCal Code Camp - Los Angeles, CA
2014-10-18 Desert Code Camp - Chandler, AZ
Mastering Agile Practices to Build High Performing TeamsAgileThought
These slides are from a talk that I gave to the Tampa Bay Agile Meetup on August 19, 2014. The talk was titled "Mastering Agile Practices to Build High Performing Teams". http://www.meetup.com/tampa-bay-agile/events/193898502/
Description:
You've read the books. You already know what your Agile team SHOULD be doing. Your Daily Standup meeting should be short and sweet. Your deployments should be automated. Your Sprint Retrospectives should inspire improvement.
So if you know what to do, why aren't you doing it?
The short answer is because Agile is hard. It takes real discipline and leadership to master even the most basic practices. Many teams have committed to adopting Agile, but they just don’t know how to get to the next level.
In this talk, I will share my real world experiences from years of coaching high performing Agile teams. I will discuss the key practices that must be mastered for a team to become great. Additionally, I will identify useful measurement techniques so that teams know if they are improving.
Technical Excellence Doesn't Just Happen - AgileIndy 2016Allison Pollard
The ninth principle from the Agile Manifesto states that technical excellence enhances agility, but when the codebase is ugly and the deadlines are tight, most teams don’t choose to refactor mercilessly, adopt TDD, or evaluate automated testing tools—unless they have the proper support. In our experience working with multiple teams in a single codebase, developers can feel victim to a legacy codebase if only a few people are writing clean code or refactoring; guiding them on how to decrease technical debt while delivering their projects helps "unstuck" their other agile practices. We will talk about the challenges we’ve seen with Product Owners, Managers, and Scrum Masters interacting with teams at various stages of agile+technical excellence and how a focus on technical practices sparked a wider interest in craftsmanship. Learn how can you influence the team towards the right practices while fostering their sense of ownership. Getting serious about technical excellence requires support from technical and non-technical roles, and we’ll share how we partnered as coaches to help an organization through a technical turnaround with some tips for others who need to do the same.
DOES15 - Mirco Hering - Adopting DevOps Practices for Systems of Record – An ...Gene Kim
Mirco Hering, Agile & DevOps Lead, Accenture
Systems of record are often seen as especially difficult to deal with in regards to Agile adoption and DevOps practices. But is that a reason to avoid them? Unfortunately often people don’t talk about the messy work that is required to make these systems work in an Agile environment, it looks so much cleaner with web applications or your custom Java application. Let’s get our hands dirty together in this talk.
I will show you that once you drill open the COTS and Enterprise systems you will be surprised to find common ground, that allows you to deal with these systems in a very similar way to your custom development applications. I work with enterprise grade applications (for example Siebel, Mainframe) all the time and I want to share with you what you can do to make your COTS and Enterprise systems work better in an Agile environment. I provide tangible examples from Siebel and Mainframe to illustrate how you can solve some of the problems and will also share some of the areas that I have failed in so far.
Дмитро Бузоверя
Директор Cloud Computing департаменту в компанії AMC Bridge
Agile підхід до управління проектами існує вже більше 15 років, він досі є об’єктом багатьох дискусій та вважається інноваційним у деяких областях.
Дмитро Бузоверя, зробить огляд методології Agile у розробці програмного забезпечення. Він розкаже про історію Agile, його принципи та більш детально зупиниться на різних методиках: Extreme Programming (XP), Scrum, Lean та Kanban.
Ця лекція допоможе зібрати пазл з Agile термінології в єдину картинку.
Continuous delivery requires more that DevOps. It also requires one to think differently about product design, development & testing, and the overall structure of the organization. This presentation will help you understand what it takes and why one would want to deliver value to your customers multiple times each day. #CIC
Jeff "Cheezy" Morgan Ardita Karaj
In his recent book, Clean Agile, Robert C "Uncle Bob" Martin chooses Extreme Programming (XP) for the basis of his explanation of Agile because "of all the Agile processes, XP is the best defined, the most complete, and the least muddled."
So why is it that in my professional life I only hear us speaking about Agile in terms of Scrum, Sprints, and possibly Kanban? Often I mention XP and people are not sure what I mean. Am I sure myself?
Coined in 1999 by Kent Beck and Ward Cunningham, XP has been with us for twenty years, but may of its practices have been with us for much longer. Many of them will be familar to you, but did you know they came from XP?
This talk aims to take us back to what XP is, how it fits in the Agile world, how it sits alongside other methodologies, and why, like Uncle Bob, I believe it is the best defined methodology, and what we should all be talking about.
The talk is based on a heavily refactored talk that Mike gave previously at Agile on the Beach conference, updated for 2020.
Given at Ox:Agile Meetup on February 11th 2020: https://www.meetup.com/OXAGILE/events/nxrdmrybcdbpb/
Why Isn't Clean Coding Working For My TeamRob Curry
Teams fail to achieve the full benefit of the "clean code" approach when they focus on the code and neglect the Agile process. The full title of Uncle Bob's "Clean Code" book is "Clean Code: A Handbook of Agile Software Craftsmanship". This talk presents an depth look at necessary relationship between Clean Code software craftsmanship and the Agile methodology, identifies common scenarios and situations where teams may fall short of recognizing and respecting that relationship, and provides practical recommendations for achieving a fully integrated process of Agile Software Craftsmanship.
Robert Martin's book "Clean Code: A Handbook of Agile Software Craftsmanship" had a huge positive impact on software development teams that adopted his approach to "Agile Software Craftsmanship". But teams sometimes fail to achieve the full benefit of the "clean code" approach because they focus on the code and neglect the Agile process.
It's easy to do: the book provides such clear, practical advice on how to write code that is easier to maintain, more reliable, and less error prone that developers adopt those techniques to great effect and fail to pursue and adopt the harder, agile process recommendations from the book. This is further complicated by the fact that there is now a Software Craftsmanship Manifesto that is separate from the Agile Manifesto.
So, how does using selected clean code techniques break the Agile process defined in the the book? What is the relationship between the two that Uncle Bob wanted us to understand and adopt in toto? Where do we go wrong? Are there some work environment or business driven scenarios that are more likely to break the relationship?
This presentation addresses those questions and more by an taking an in depth look at necessary relationship between Clean Code software craftsmanship and the Agile methodology, identifies common scenarios and situations where teams may fall short of recognizing and respecting that relationship, and provides practical recommendations for achieving a fully integrated process of Agile Software Craftsmanship.
Are you looking to produce online educational content? Join Richard Harrington and team members from RHED Pixel. They'll share secrets to producing effective online content to educate and inspire others. Their past client roster includes Adobe, Apple, lynda.com, Microsoft, the American Red Cross, and many more. Learn how to produce a wide range of projects from simple screen capture videos to complex projects.
Topics Covered:
Setting educational goals
Managing talent and course development
Choosing the right production approach
Measuring the effectiveness of the course
Agile Austin - Peer Code Review An Agile Processgsporar
Slides from Gregg Sporar's presentation on peer code review at the January 2010 meeting of Agile Austin. More information available here: http://blog.smartbear.com/the_smartbear_blog/2010/01/is-pair-programming-like-junior-high-sex.html.html
✊ Join the DEV-olution: A culture of empowered developersSven Peters
Engineering leaders say their organizations struggle with productivity, collaboration, and tracking progress against goals. Some try to fix it by adding more dashboards, making strict rules, and asking for more reports. But just doing more doesn't solve the real issues developers face.
Let’s build a culture that empowers developers to do the right things and starts a dev-olution. Join Sven and hear how empowered teams build trustful relationships, work asynchronously and synchronously, use data smartly, care about outcomes, stay curious, and always try new things. More importantly, you will learn how to establish such a culture evolutionarily.
Empowering your engineers will amplify developer joy and supercharge your development effectiveness.
Beyond the Scrum Team: Delivering "Done" at ScaleTasktop
In this webinar Dave West, CEO and Product Owner of Scrum.org, and Betty Zakheim, VP of Industry Strategy at Tasktop talk about the success of Scrum in the enterprise and techniques that organizations can employ when they have a large IT shop.
Join us for this discussion of the successes and challenges of Scrum at scale, including:
* Scrum.org's Nexus
* how software development teams can deliver "Done" at scale
* how these techniques fit into the broader software delivery lifecycle
One of the 12 principles of the Agile Manifesto states that “The best architecture, requirements, and designs emerge from self-organizing teams.” Why is that? And what exactly are self-organizing teams? How does a team become self-organizing? Teams that have always been used to command and control cannot suddenly become self-organizing overnight. Come to this session to learn what self-organizing really means. Understand the attributes of a self-organizing team and some of the challenges you face in getting your team there. Learn how to use the Self-Organizing Teams Canvas and appropriate delegation to find the right balance between team learning and team empowerment vs. control. Leave with tools and techniques to help you build and foster high-performing self-organizing teams.
This talk was presented at AgileDC2018
Abstract:
Is your team constantly missing delivery dates? Is the velocity decreasing from sprint to sprint while the development costs are rising? Are customers complaining about the increasing number of bugs and the long time it takes to add new features? These are all signs that you are mired in technical debt and probably on your way to bankruptcy or a complete system rewrite. Technical debt is inevitable, whether intentional or unintentional. However, not managing technical debt can paralyze your organization. Fadi Stephan expands on the technical debt metaphor and introduces a technical debt management plan that enables executives and teams to make prudent decisions on code quality and technical debt. Come learn how to measure the quality of your code base and determine the amount of your debt.
Many UX designers struggle to work within a Scrum environment and see Scrum as a framework mainly for developers. Working in time-boxed Sprints and delivering small pieces iteratively and incrementally might force designers to focus on a single story at a time. This in turn can lead to tunnel vision, losing focus of the big picture and resulting in a fragmented user experience. This presentation covers where design fits in Scrum and how to apply design principles in Agile environments and work effectively with Scrum teams to produce a great user experience.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
Search and Society: Reimagining Information Access for Radical FuturesBhaskar Mitra
The field of Information retrieval (IR) is currently undergoing a transformative shift, at least partly due to the emerging applications of generative AI to information access. In this talk, we will deliberate on the sociotechnical implications of generative AI for information access. We will argue that there is both a critical necessity and an exciting opportunity for the IR community to re-center our research agendas on societal needs while dismantling the artificial separation between the work on fairness, accountability, transparency, and ethics in IR and the rest of IR research. Instead of adopting a reactionary strategy of trying to mitigate potential social harms from emerging technologies, the community should aim to proactively set the research agenda for the kinds of systems we should build inspired by diverse explicitly stated sociotechnical imaginaries. The sociotechnical imaginaries that underpin the design and development of information access technologies needs to be explicitly articulated, and we need to develop theories of change in context of these diverse perspectives. Our guiding future imaginaries must be informed by other academic fields, such as democratic theory and critical theory, and should be co-developed with social science scholars, legal scholars, civil rights and social justice activists, and artists, among others.
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
9. History
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
10. History
Software craftsmanship over CRAP!
Craftsmanship over execution
• Most software development teams execute,
but they don’t take care
• We value execution, but we value
craftsmanship more
12. 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
27. I will practice 2 hours every day
I will practice 2 hours every day
I will practice 2 hours every day
I will practice 2 hours every day
I will practice 2 hours every day
I will practice 2 hours every day
Practice
28.
29.
30.
31. I pity the fool
who doesn’t write
test cases!
Test Driven
Development
32. I pity the fool
who breaks the
build!
Continuous
Integration
33. I pity the fool
who doesn’t
collaborate
Pair
Programming
Most of this presentation is based on the work of Robert Martin and Corey Haines
OOPSLA 1991Object-Oriented Programming, Systems, Languages & Applications ConferenceBruce Anderson workshop “Towards a Software Architecture Handbook”Dedicated to developing a handbook for software architectsRichard Helm, Ralph Johnson, John Vlissides and Erich Gamma met here Collaborated for couple of years to produce “Design Patterns” - GOF
OOPSLA 1998Bruce Anderson workshop “Software as a Studio Discipline”Discuss whether developing software is a careful blend of artistry and disciplinePete McBreen inspiredIn2001, published book “Software Craftsmanship”Main theme: Software engineering has run its course Building software systems requires set of skills and experiences beyond just book learning, training courses, methodologies, and certifications
Book presented a craftsman paradigm in which apprentice software developer learns from journeyman like other craftsman based professionsSoftware is a craft: part art, part skill Developers should be measured on quality of work, ability to deliver value to business and be accountable for what they produce. At the time it was published, it did not generate much noise or interest and did not become a hit like the GoF book.Picture: http://www.flickr.com/photos/25507200@N07/3120849218/
Agile 2008 – TorontoKeynote address by uncle BobReviewed Agile manifestoProposed fifth value to agile manifesto: Craftsmanship over crapHuge stage to bring up the same concepts again and created a lot of discussion
A week later Robert Martin revised it to craftsmanship over executionMost software development teams execute, but they don’t care. We value execution, but we value craftsmanship more.“We're tired of writing crap. We are tired of embarrassing ourselves and our employers by delivering lousy software. We have had enough of telling our customers to reboot at midnight. We don't want bug lists that are a thousand pages long. We don't want code that grows more tangled and corrupt with every passing day. We're tired of doing a bad job. We want to start doing a good job.”http://cleancoder.posterous.com/software-craftsmanship-things-wars-commandmenDid not result in change to manifesto, but started a movement of its own. December 2008, group of aspiring software craftsmen got together and tried to solve some problems they were facingCame up with a statement of things they believe in and crafted another manifesto, the Software Craftsmanship manifesto
Software Craftsmanship manifesto
They felt that we are heading in a bad direction. The state of software development was going downhill.
Theory vs. practiceMismatch with teaching and what is needed forworkStrong theoretical knowledge but can’t write good codePicture: http://www.flickr.com/photos/sakeeb/4647211575/sizes/m/in/photostream/
Popularity of Scrum. Scrum focuses on process but does not prescribe technical practices. Ken Schwaber said that we made a fundamental assumption that was wrongDevelopers smart enough to come up with their own practicesButdevelopers spent careers working in large cycles. They were used to it. waiting for 9 months before coding or before QANow they have to figure out how to do things in 30 days or even in 2 weeks.Agile and Scrum requires skilled developers that know how to keep code base healthyDelivering software every 2 to 4 weeks only possible if build up and keep code highly maintainablePicture: www.mountaingoatsoftware.com/scrum
Robert Martin bad code video
Place holder
Big ball of mud most popular way to design and architect softwareIncludes Greenfield projects that have full benefit of hindsight regarding bad design approaches of pastPicture: http://www.flickr.com/photos/24322735@N07/2393833499/sizes/m/in/photostream/
Code unreadable and looked like spaghetti code jungle
Become sloppy Use duck tape to fix thingsThe whole code is covered with duck tape. Picture: http://www.flickr.com/photos/wwworks/4471608005/sizes/m/in/photostream/
In a minefieldAnything you touch might break and explodeNow easier to do it all over again than to read and figure out other people’s codePicture: http://www.flickr.com/photos/timrich26/3308513067/sizes/m/in/photostream/
Need tools like crap4j - Change Risk Analyzer and PredictorCRAP(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m) m = method comp(m) = Cyclometric complexity of method m. cov(m) = Test code coverage for method m. Crap gap measure
Most interesting man in the worldPicture: http://imgur.com/y7Hm9?full
Software craftsmen: good software does not come from processComes from people who care about itPeople have pride in their workStand by what they doWilling to learn from others to improveBy sharing they bring up knowledge of entire team and companyBuilding code requires more than theoretical knowledge, it requires tacit knowledge and experience.
We CareWe consider it our responsibility to gain the trust of the businesses we serve; therefore, we take our customer's problems as seriously as they do and stake our reputation on the quality of the work we produce.We PracticeWe consider it our responsibility to write code that is defect-free, proven, readable, understandable and malleable; therefore, we follow our chosen practices meticulously even under pressure and practice our techniques regularly.We LearnWe consider it our responsibility to hone our craft in pursuit of mastery; therefore, we continuously explore new technologies and read and study the work of other craftsmen.We ShareWe consider it our responsibility to perpetuate the craft of Software; therefore, we enlist apprentices to learn it and actively engage other craftsmen in dialogue and practice.
We Care about quality. We stake our reputation on the quality of the work we produce.We CareWe consider it our responsibility to gain the trust of the businesses we serve; therefore, we take our customer's problems as seriously as they do and stake our reputation on the quality of the work we produce.
We Practice: We practice our techniques regularly and follow our practices even under pressure in order to write defect-free, proven, readable, understandable and malleableWe PracticeWe consider it our responsibility to write code that is defect-free, proven, readable, understandable and malleable; therefore, we follow our chosen practices meticulously even under pressure and practice our techniques regularly.
We Learn: we continuously explore new technologies, read and study the work of other craftsmen.We LearnWe consider it our responsibility to hone our craft in pursuit of mastery; therefore, we continuously explore new technologies and read and study the work of other craftsmen.
We Share: we look for newcomers and actively engage other craftsmen in dialogue and practiceWe ShareWe consider it our responsibility to perpetuate the craft of Software; therefore, we enlist apprentices to learn it and actively engage other craftsmen in dialogue and practice.Picture: http://www.flickr.com/photos/das_butzele/227637183/sizes/z/in/photostream/
Disciplines
TDD – verifies that our code works and makes it possible to refactor and constantly improve code over time.TDD: Follow 3 rules: 1) not allowed to write production code until you have a failing unit test, 2) you are not allowed to write more of unit test than is sufficient to fail (not compile is failing), 3) you are not allowed to write more production code than is sufficient to pass. This forces us to keep the code executing all the time. Tests make the software flexible and maintainable.
CI: Use tools like Hudson, CruiseControl, Bamboo, and TeamCity. If build fails, immediately fix build.
Pairing: If you don’t want to code pair, at least make sure team is communicating, sharing and working closely together.
Pride and attitude that QA should find nothing
Principles
Apply the boy scout rule: Always leave camp ground cleaner than way you found it. That is, whenever you work on a class or function, spend some extra time to refactor it and clean it a little.Picture: http://www.flickr.com/photos/fotoecke/5177140233/sizes/m/in/photostream/
Apply Extract till you drop: Function size should be small. Keeping extracting until you can no longer extract function. This takes all the concepts in the function puts them in well named places.
No argument is best argument. Functions should have smallest number of arguments possible. Try not to exceed 2 arguments. Do not pass Booleans as arguments; instead create two well named functions.Picture: http://www.flickr.com/photos/drinksmachine/3732782275/sizes/m/in/photostream/
Use long names to be as descriptive as possible.
Avoid duplication. Do not copy and paste.Picture: http://www.flickr.com/photos/popilop/331357312/sizes/z/in/photostream/
Design Patterns
SOLID PrinciplesS SRP Single responsibility principle the notion that an object should have only a single responsibility. O OCP Open/closed principle the notion that “software entities … should be open for extension, but closed for modification”.L LSP Liskov substitution principle the notion that “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”. I ISP Interface segregation principle the notion that “many client specific interfaces are better than one general purpose interface.”D DIP Dependency inversion principle the notion that one should “Depend upon Abstractions. Do not depend upon concretions.”[Dependency injection is one method of following this principle.
http://www.flickr.com/photos/70981241@N00/3979767112/Decouple from others: write stubs to ensure your code can run and to define your interface
http://www.flickr.com/photos/11904001@N00/3983980813/Work in small incrementsUse progressive widening: Add a small feature from top to bottom (GUI to database)Use progressive deepening: Get something working in one layer and then move it down to other layers. 1st make it work, then make it right, then make it fast.Avoid grand redesigns. They generally do not work very well. A “tiger” team will constantly be trying to catch up with maintenance team.
YouAin’tgonna need it. Avoid turgid viscous architectures. They do harm than good. They slow you down. Don’t try to create a solution for all possible (imaginable) cases. Just try to solve the problem at hand use a simple architecture. Use good coding techniques (like decoupling and SRP) and adding in new cases as they are need should be easy.Picture: http://www.flickr.com/photos/97041449@N00/5261698908/
Abstract away volatility: look at what is likely to change and separate it from what is not likely to change. (do not mix gui with business rules).
Short iterations (1 or 2 weeks). Plan, code, testing, documentation (complete cycle resulting in deployable software.Participate in the definition process by demonstrating working code.
Commission instead of omission. It is better to experiment than to wait.Never be blocked: always find some way to make progressPicture: http://www.flickr.com/photos/7821771@N05/4679360979/
Automate everything. Playing with system should be explorative testing. The other vast majority of testing should be automated. Builds should be automated. Deployments should be automated.Check out the book “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation” by Jez Humble and David Farley
Test through the right interface.Do not test business rules through the GUI. Test GUIconnected to a dummy (mock) layer.Picture: http://www.flickr.com/photos/37164718@N02/5365226277/
Don’t jump into the debugger. Look at the code 1st. Use TDD. Debugger should be last resort.Picture: http://www.flickr.com/photos/71962092@N00/2874328851/
Clean code: Only way to go fast is to slow down a minute and write clean code. Readable, obvious, small functions, good namesDon’t write bad code: It does not only slow down others months from now but will slow you down immediately.
Software craftsmanship is about pride in work, team work, mentorship, improving skills, practicingYet there is some disagreement
Not everyone agreesDan North, and David HarveyArgue software craftsmanship manifesto is weakJust adds riders or extensions to agile manifestoMost already covered in agile principles
Principle #9: continuous attention to technical excellence and good design enhances agility.
2nd, manifesto is tameManifesto - a statement of belief,a call-to-arms, feisty, opinionated, and brash.Marxand Angels communist manifestoFuturist manifestoSCUM manifestoAll compelling, persuasive, controversial and polarizingShould be something we can disagree withNo reasonable person can disagree with software craftsmanship manifestoNo one can say they don’t care about adding value, create community of professionals, having productive partnerships and writing quality software. Not much of a manifesto
Manifesto is attack on software engineering and scientific researchManifesto is giving permission new generation to ignore all lessons learned from software engineeringLessons like the works of DeMarco, Yourdon, Parnas, Dijkstra, Hoare, Weinberg.
Language matterschoosing inappropriate metaphors, like craftsman, apprentice, journeyman, increases gap between development and business.Software developers have their own definition of craftsmanship, butwhat matters is perception of customersAssociate craft with quality at a flea-market or craft fair - not something can really rely onhttp://www.flickr.com/photos/58289610@N00/3610407879/
Terms "Master", "Journeyman", and "Apprentice“ bring up secretive guilds of middle ages with ritual, mysticism, and intrigueSoftware craftsmen should be egoless, humble, with focus on outcome rather than code or process
Manifesto brought people together and made it easier for them to roll out some ideas on how to practice
Code katas - Dave Thomas from pragmatic programmersSmall problems to solveUncle Bob switched to practice on a solution insteadLike martial arts and how you repeat small motions and practice them until they become natural reflexesDo it over and over again until it becomes reflexKatacasts.com – Corey Haines has various screencasts known as katacast that show folks practicing a small kata
Example Bowling Kata, Poker Kata, Supermarket Kata, Tennis KataPicture: http://www.flickr.com/photos/49715404@N00/3267627038/
Code retreats started worldwideDevelopers get together on Saturday for full day of practiceWork on Conway’s game of life using technique “TDD as if you meant it” Focuses on TDD being all about evolutionary designPair-up, work on it for 45 minutes, then delete code, swap pairs and do it again
2 companies swap employee for weekEmployees learn practices of another company and come back and try to improve their own environment
Craftsman journey – you go to company for 1 week and learn what they doInstead of going to conference, company will give you time off to go and work and learn what others are doing
Craftsman spikes are side projects that you use to practice craftsmanshipCompanies offers employees 20% time to work on side projects
Software craftsmanship conferences established and 2 held each year, one in the UK and one in the USSeveral Software Craftsmanship User groups started