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/
We’re all doing Agile nowadays, aren’t we? We’ll all delivering software in an Agile way. But what does that mean? Does it mean sprints and stand-ups? Kanban even? But what about Extreme Programming? If as a development team we’re not using pair programming, test driven development, continuous integration, and other XP practices, then we’re not really doing Agile software development and we may be on a march to frustration, or even failure.
I’m going to look at why the current trend of companies and projects adopting Scrum, calling themselves Agile, but not transitioning their development to XP, is a recipe for disaster. I’d like to cover the main practices of XP as well as other good practices that can really help a team deliver quality software, whether they’re doing two-week sprints, Kanban, or even Waterfall.
https://www.youtube.com/watch?v=aZgnY9fAHOA
DevOps emphasizes communication, collaboration and integration between the developers and the operations folks. Some teams figure out DevOps on their own, but most struggle in their effort to implement DevOps practices, such as, automated builds, automated tests, automated deployments, continuous integration, and continuous delivery.
Many consider these practices essential for the success of any software development project, but they require a new way of thinking. In other words: DevOps requires agility.
We’re all doing Agile nowadays, aren’t we? We’ll all delivering software in an Agile way. But what does that mean? Does it mean sprints and stand-ups? Kanban even? But what about Extreme Programming? If as a development team we’re not using pair programming, test driven development, continuous integration, and other XP practices, then we’re not really doing Agile software development and we may be on a march to frustration, or even failure.
I’m going to look at why the current trend of companies and projects adopting Scrum, calling themselves Agile, but not transitioning their development to XP, is a recipe for disaster. I’d like to cover the main practices of XP as well as other good practices that can really help a team deliver quality software, whether they’re doing two-week sprints, Kanban, or even Waterfall.
https://www.youtube.com/watch?v=aZgnY9fAHOA
DevOps emphasizes communication, collaboration and integration between the developers and the operations folks. Some teams figure out DevOps on their own, but most struggle in their effort to implement DevOps practices, such as, automated builds, automated tests, automated deployments, continuous integration, and continuous delivery.
Many consider these practices essential for the success of any software development project, but they require a new way of thinking. In other words: DevOps requires agility.
It was back in ‘97 when Brian Foote and I first opined that: while much attention had been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture had seldom been discussed: the Big Ball of Mud. A Big Ball of Mud is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems. Somewhat to our astonishment, since our original statement, no one has ever undertaken to dispute this premise. Still, this approach endures and thrives. Why is this architecture so popular? Is it as bad as it seems, or might it serve as a way-station on the road to more enduring, elegant artifacts? What forces drive good programmers to build ugly systems? Can we avoid this? Should we? How can we make such systems better?
This keynote will examine the paradoxes that underlie Big Balls of Mud, what causes them, and why they are so prominent. What Agile Practices help us avoid or cope with mud? Does Agile practices such as TDD really help minimize mud? What are we doing RIGHT? What Agile Practices contribute to the problem? Encourage mud? Is Mud really the best that Agile can do? Is Agility’s utilitarian focus on process rather than design its secret weapon, or its Achilles heel?
Continuously Deploying Culture: Scaling Culture at Etsy - Velocity Europe 2012Patrick McDonnell
There was a time not long ago when Etsy was laden with barriers, silos, broken communication, and noncooperation. This talk will focus on the various stages of Etsy's cultural development from the early days to present. We will tell of how Etsy overcame numerous challenges and built a strong company culture while continuing to scale.
When going into the development of a software product, a possible source of mistake is the incorrect evaluation of the complexity that lies behind an idea , as well as a clutter coming from the massive amounts of technologies enabled. This presentation explains a possible way to deal with such issues.
Becoming a Software Craftsman takes a lot of practice. Using Code Katas in Coding Dojos is an excellent way to get that practice in a low stress fun way. Discover how to do that.
Mob Programming delivers the very best from your entire team, technical and business alike. Learn about mob programming and how to bring mob programming to remote teams.
Taming Big Balls of Mud with Diligence, Agile Practices, and Hard WorkJoseph Yoder
Big Ball of Mud (BBoM) architectures are viewed as the culmination of many design decisions that, over time, result in a system that is hodgepodge of steaming and smelly anti-patterns. It can be arguably claimed that one of the reasons for the growth and popularity of agile practices is partially due to the fact that the state of the art of software architectures was not that good. Being agile, with its focus on extensive testing and frequent integration, has shown that it can make it easier to deal with evolving architectures (possibly muddy) and keeping systems working while making significant improvements and adding functionality. Time has also shown that Agile practices are not sufficient to prevent or eliminate Mud. It is important to recognize what is core to the architecture and the problem at hand when evolving an architecture.
This talk will examine the paradoxes that underlie Big Balls of Mud, what causes them, and why they are so prominent. I’ll explore what agile practices can help us avoid or cope with mud. I’ll also explain why continuous delivery and TDD with refactoring is not enough to help ensure clean architecture and why it is important to understand what is core to the architecture and the problem at hand. Understanding what changes in the system and at what rates can help you prevent becoming mired in mud. By first understanding where a system’s complexities are and where it keeps getting worse, we can then work hard (and more intelligently) at sustaining the architecture. This can become a key value to the agile team. The results will leave attendees with practices and patterns that help clean your code (refactor) as well as keeping the code clean or from getting muddier.
Additionally, I’ll talk about some practices and patterns that help keep the code clean or from getting muddier. Some of these include: Testing, Divide & Conquer, Gentrification, Demolition, Quarantine, Refactoring, Craftmanship and the like.. The original Big Ball of Mud paper described some best practices such as SHEARING LAYERS and SWEEPING IT UNDER THE RUG as a way to help deal with muddy architectures. Additionally there are some other practices such as PAVING OVER THE WAGON TRAIL and WIPING YOUR FEET AT THE DOOR that can make code more habitable.
Not every continuous delivery initiative starts with someone saying "drop everything. Let's do DevOps." Sometimes you have grow your practice incrementally. And sometimes, you don’t set out to grow a practice at all-- you are just fixing problems with your process, trying to make things better.
I'll walk through a case study of how our team worked on an exemplar project for the Department of Defense to show that agile could work in a decidedly waterfall culture. I’ll also discuss techniques and tools we used to bring a DevOps mindset and continuous delivery practices into an environment that wasn't already Agile.
I'll talk about how we were able to start in development, where we had the most control, with a "let's starting being Agile" initiative and working on "why is continuous integration important?" From there, we tackled one problem after another, each time making the release a little easier and a little less risky. We incrementally brought our practices through other environments until the project was confidently delivering working, QA-tested, security-tested releases that were ready for production every two weeks. I’ll discuss the journey we took and the tools we used to get to build quality into our product, our releases, and our release process.
This session is aimed at people that are trying to adopt agile and continuous delivery, but might be worried that it can’t work in their particular environment due to the enterprise, the culture, or the regulations that surround them.
#NoVSM: Understanding and Mapping Your Knowledge Discovery Processazheglov
Presented as a short talk at Lean Kanban North America 2014 conference in San Francisco on May 7, 2014.
Sorry, the words actually said during the talk and the words on the slides don't have much overlap. This is by design. I don't want to be seen reading slides even if I have memorized them. As I understand, attendees will get the video.
The Journey of devops and continuous delivery in a Large Financial InstitutionKris Buytaert
The Journey of devops and continuous deliverey in a Large Financial Institution,
as presented by @markheistek and myselve at Velocity Conf 2013, Longon
Presentation from the August 2012 NBIC (Netherlands Bioinformatics Centre) BioAssist programmer's meeting. Overview of the content:
1. what are code reviews, some different ways of reviewing code
2. why would you want to do code reviews, what makes sense and what not
3. how can you do code reviews (or formal inspections), some real world experience
4. using tools for code reviews
5. some links for more information
6. two bonus slides with a few links to gems from the Triumph of the Nerds documentary, well worth watching!
Effective Code Review (Or How To Alienate Your Coworkers)Perforce
In this talk, the architects of Perforce Swarm will guide you through the process of starting and updating a code review. They will also share some of their secrets for performing effective reviews. Learn how to start and update code reviews using Swarm, best practices for performing effective review, and the benefits of pre-commit automated testing and deployment.
Beyond TDD: Enabling Your Team to Continuously Deliver SoftwareChris Weldon
Many project teams have adopted unit testing as a necessary step in their development process. Many more use a test-first approach to keep their code lean. Yet, far too often these teams still suffer from many of the same impediments: recurrent integration failures with other enterprise projects, slow feedback with the customer, and sluggish release cycles. With a languishing feedback loop, the enterprise continues to put increasing pressure on development teams to deliver. How does an aspiring agile team improve to meet the demands of the enterprise?
Continuous integration is the next logical step for the team. In this talk, you’ll learn how continuous integration solves intra and inter-project integration issues without manual overhead, the value added by continuous integration, and how to leverage tools and processes to further improve the quality of your code. Finally, we discuss the gold standard of agile teams: continuous deployment. You’ll learn how continuous deployment helps close the feedback loop with your customers, increases visibility for your team, and standardizes the deployment process.
Prashant technical practices-tdd for xebia eventXebia India
Theme: Agile Technical Practices
Epic: TDD implementation
Stories:
Context of TDD
What is TDD
Response of Developers to TDD implementation
Practices complimenting TDD
Success with TDD
It was back in ‘97 when Brian Foote and I first opined that: while much attention had been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture had seldom been discussed: the Big Ball of Mud. A Big Ball of Mud is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems. Somewhat to our astonishment, since our original statement, no one has ever undertaken to dispute this premise. Still, this approach endures and thrives. Why is this architecture so popular? Is it as bad as it seems, or might it serve as a way-station on the road to more enduring, elegant artifacts? What forces drive good programmers to build ugly systems? Can we avoid this? Should we? How can we make such systems better?
This keynote will examine the paradoxes that underlie Big Balls of Mud, what causes them, and why they are so prominent. What Agile Practices help us avoid or cope with mud? Does Agile practices such as TDD really help minimize mud? What are we doing RIGHT? What Agile Practices contribute to the problem? Encourage mud? Is Mud really the best that Agile can do? Is Agility’s utilitarian focus on process rather than design its secret weapon, or its Achilles heel?
Continuously Deploying Culture: Scaling Culture at Etsy - Velocity Europe 2012Patrick McDonnell
There was a time not long ago when Etsy was laden with barriers, silos, broken communication, and noncooperation. This talk will focus on the various stages of Etsy's cultural development from the early days to present. We will tell of how Etsy overcame numerous challenges and built a strong company culture while continuing to scale.
When going into the development of a software product, a possible source of mistake is the incorrect evaluation of the complexity that lies behind an idea , as well as a clutter coming from the massive amounts of technologies enabled. This presentation explains a possible way to deal with such issues.
Becoming a Software Craftsman takes a lot of practice. Using Code Katas in Coding Dojos is an excellent way to get that practice in a low stress fun way. Discover how to do that.
Mob Programming delivers the very best from your entire team, technical and business alike. Learn about mob programming and how to bring mob programming to remote teams.
Taming Big Balls of Mud with Diligence, Agile Practices, and Hard WorkJoseph Yoder
Big Ball of Mud (BBoM) architectures are viewed as the culmination of many design decisions that, over time, result in a system that is hodgepodge of steaming and smelly anti-patterns. It can be arguably claimed that one of the reasons for the growth and popularity of agile practices is partially due to the fact that the state of the art of software architectures was not that good. Being agile, with its focus on extensive testing and frequent integration, has shown that it can make it easier to deal with evolving architectures (possibly muddy) and keeping systems working while making significant improvements and adding functionality. Time has also shown that Agile practices are not sufficient to prevent or eliminate Mud. It is important to recognize what is core to the architecture and the problem at hand when evolving an architecture.
This talk will examine the paradoxes that underlie Big Balls of Mud, what causes them, and why they are so prominent. I’ll explore what agile practices can help us avoid or cope with mud. I’ll also explain why continuous delivery and TDD with refactoring is not enough to help ensure clean architecture and why it is important to understand what is core to the architecture and the problem at hand. Understanding what changes in the system and at what rates can help you prevent becoming mired in mud. By first understanding where a system’s complexities are and where it keeps getting worse, we can then work hard (and more intelligently) at sustaining the architecture. This can become a key value to the agile team. The results will leave attendees with practices and patterns that help clean your code (refactor) as well as keeping the code clean or from getting muddier.
Additionally, I’ll talk about some practices and patterns that help keep the code clean or from getting muddier. Some of these include: Testing, Divide & Conquer, Gentrification, Demolition, Quarantine, Refactoring, Craftmanship and the like.. The original Big Ball of Mud paper described some best practices such as SHEARING LAYERS and SWEEPING IT UNDER THE RUG as a way to help deal with muddy architectures. Additionally there are some other practices such as PAVING OVER THE WAGON TRAIL and WIPING YOUR FEET AT THE DOOR that can make code more habitable.
Not every continuous delivery initiative starts with someone saying "drop everything. Let's do DevOps." Sometimes you have grow your practice incrementally. And sometimes, you don’t set out to grow a practice at all-- you are just fixing problems with your process, trying to make things better.
I'll walk through a case study of how our team worked on an exemplar project for the Department of Defense to show that agile could work in a decidedly waterfall culture. I’ll also discuss techniques and tools we used to bring a DevOps mindset and continuous delivery practices into an environment that wasn't already Agile.
I'll talk about how we were able to start in development, where we had the most control, with a "let's starting being Agile" initiative and working on "why is continuous integration important?" From there, we tackled one problem after another, each time making the release a little easier and a little less risky. We incrementally brought our practices through other environments until the project was confidently delivering working, QA-tested, security-tested releases that were ready for production every two weeks. I’ll discuss the journey we took and the tools we used to get to build quality into our product, our releases, and our release process.
This session is aimed at people that are trying to adopt agile and continuous delivery, but might be worried that it can’t work in their particular environment due to the enterprise, the culture, or the regulations that surround them.
#NoVSM: Understanding and Mapping Your Knowledge Discovery Processazheglov
Presented as a short talk at Lean Kanban North America 2014 conference in San Francisco on May 7, 2014.
Sorry, the words actually said during the talk and the words on the slides don't have much overlap. This is by design. I don't want to be seen reading slides even if I have memorized them. As I understand, attendees will get the video.
The Journey of devops and continuous delivery in a Large Financial InstitutionKris Buytaert
The Journey of devops and continuous deliverey in a Large Financial Institution,
as presented by @markheistek and myselve at Velocity Conf 2013, Longon
Presentation from the August 2012 NBIC (Netherlands Bioinformatics Centre) BioAssist programmer's meeting. Overview of the content:
1. what are code reviews, some different ways of reviewing code
2. why would you want to do code reviews, what makes sense and what not
3. how can you do code reviews (or formal inspections), some real world experience
4. using tools for code reviews
5. some links for more information
6. two bonus slides with a few links to gems from the Triumph of the Nerds documentary, well worth watching!
Effective Code Review (Or How To Alienate Your Coworkers)Perforce
In this talk, the architects of Perforce Swarm will guide you through the process of starting and updating a code review. They will also share some of their secrets for performing effective reviews. Learn how to start and update code reviews using Swarm, best practices for performing effective review, and the benefits of pre-commit automated testing and deployment.
Beyond TDD: Enabling Your Team to Continuously Deliver SoftwareChris Weldon
Many project teams have adopted unit testing as a necessary step in their development process. Many more use a test-first approach to keep their code lean. Yet, far too often these teams still suffer from many of the same impediments: recurrent integration failures with other enterprise projects, slow feedback with the customer, and sluggish release cycles. With a languishing feedback loop, the enterprise continues to put increasing pressure on development teams to deliver. How does an aspiring agile team improve to meet the demands of the enterprise?
Continuous integration is the next logical step for the team. In this talk, you’ll learn how continuous integration solves intra and inter-project integration issues without manual overhead, the value added by continuous integration, and how to leverage tools and processes to further improve the quality of your code. Finally, we discuss the gold standard of agile teams: continuous deployment. You’ll learn how continuous deployment helps close the feedback loop with your customers, increases visibility for your team, and standardizes the deployment process.
Prashant technical practices-tdd for xebia eventXebia India
Theme: Agile Technical Practices
Epic: TDD implementation
Stories:
Context of TDD
What is TDD
Response of Developers to TDD implementation
Practices complimenting TDD
Success with TDD
Have you heard of TDD? Are you interested or familiar with this practice but have never been able to understand it?
Join this session to see the benefits of Test-Driven Development (TDD), understand how it works and its benefits. In a more detailed approach, we will see this way of developing software, where our code is always built guided by tests.
We will go over some history about TDD, which is the main process we must follow when we work with this mechanic and the rules that surround it. We will also list the main advantages and disadvantages that most developers who practice TDD find and whether the arguments in favour add up to more than those that subtract. Finally, we will review some good habits and practices when applying TDD and see how to do it step by step with an example of a "live" coding session with Java.
At the end of the session, I hope that you will have a wider understanding of what TDD is, what advantages it brings, why it is interesting to master it and also that you will take with you some tricks and good practices to be able to apply them in your day-to-day life when writing code
===
Presentation (revisited & updated) shared at JDD 2022:
https://jdd.org.pl/lecture_2022/#id=78434
Lean-Agile Development with SharePoint - Bill AyersSPC Adriatics
SharePoint gives us a great platform for developing sophisticated intranet portals and collaboration sites and many other workloads. But it can also be a challenge to use modern software development frameworks like Scrum and XP. Wouldn’t it be great if we could get all the benefits of Agile practices – faster development, predictable deliveries, better quality, less stress and happy stakeholders? In this session we will cover the definitions of Lean, Agile, Scrum, Kanban, XP, and TDD. Then we will look at the specific challenges around Agile SharePoint development and some development techniques to overcome these obstacles. This talk covers both project delivery and engineering. We’ll look at unit tests, integration tests, UI tests, continuous integration and, of course, test-driven development (TDD) with practical experiences from real-life Agile SharePoint projects.
(SPOT205) 5 Lessons for Managing Massive IT Transformation ProjectsAmazon Web Services
Choice Hotels is undertaking a multiyear, $20 million project to recreate our core business engines on AWS. In trying to approach this complex undertaking, we determined that the project itself is a system too. You can apply principles of good architecture and design work in how you approach the project structure and management. Come to this talk by Choice Hotels’ CTO to learn five key lessons and 20 concrete takeaways that you can implement today to help your AWS projects succeed.
Software developers love tools for coding, debugging, testing, and configuration management. The more these tools improve the How of coding, the more we see that we're behind the curve on improving the What, Why, and When. If you've been on a project that seemed vague, adrift, and endless, this talk can help. Make your projects run SMART.
A presentation on PHP's position in the enterprise, its past & present, how to get ready for developing for enterprise.
Inspired by Ivo Jansch's "PHP in the real wolrd" presentation.
Presented at SoftExpo 2010, Dhaka, Bangladesh.
In the world of agile, there is theory and then there is practice. We like to talk about self-organizing teams, asynchronous execution, BDD, TDD, and emergent architecture. We also talk about cross-functional teams: how analysts, testers, architects, technical writers, and UX designers belong on the same team, right next to programmers. It all sounds nice in theory, but how does this work in reality? What do these people actually do? How do they interact? What does it look like? Is there really a pragmatic way to make this work?
In this simulation, a cross-functional team will actually build a piece of software. Every specialist will have a hand in the process. Every specialist will also act as a generalist. Everyone will add value. And as a team, we’ll get something DONE.
This is your opportunity to see agile development in practice, and to bridge the gap between what agilists say and what teams do. And it’s not as new or as difficult as you think – affinity between testers, BA’s, coders, and other team members has really been at the root of effective development practices all along. Let’s just finally acknowledge that it works, demonstrate its capabilities, and encourage it going forward.
This IS agile development.
TDD - Seriously, try it! - Trójmiasto Java User Group (17th May '23)ssusercaf6c1
Have you heard of TDD? Are you interested or familiar with this practice but have never been able to understand it?
Join this session to see the benefits of Test-Driven Development (TDD), understand how it works and its benefits. In a more detailed approach, we will see this way of developing software, where our code is always built guided by tests.
We will go over some history about TDD, which is the main process we must follow when we work with this mechanic and the rules that surround it. We will also list the main advantages and disadvantages that most developers who practice TDD find and whether the arguments in favour add up to more than those that subtract. Finally, we will review some good habits and practices when applying TDD and see how to do it step by step with an example of a "live" coding session with Java.
At the end of the session, I hope that you will have a wider understanding of what TDD is, what advantages it brings, why it is interesting to master it and also that you will take with you some tricks and good practices to be able to apply them in your day-to-day life when writing code
---
Presentation shared at Trójmiasto Java User Group
Public group 17th of May '23
TDD - Seriously, try it! - Trjjmiasto JUG (17th May '23)Nacho Cougil
Have you heard of TDD? Are you interested or familiar with this practice but have never been able to understand it?
Join this session to see the benefits of Test-Driven Development (TDD), understand how it works and its benefits. In a more detailed approach, we will see this way of developing software, where our code is always built guided by tests.
We will go over some history about TDD, which is the main process we must follow when we work with this mechanic and the rules that surround it. We will also list the main advantages and disadvantages that most developers who practice TDD find and whether the arguments in favour add up to more than those that subtract. Finally, we will review some good habits and practices when applying TDD and see how to do it step by step with an example of a "live" coding session with Java.
At the end of the session, I hope that you will have a wider understanding of what TDD is, what advantages it brings, why it is interesting to master it and also that you will take with you some tricks and good practices to be able to apply them in your day-to-day life when writing code
---
Presentation shared at Trójmiasto Java User Group (17th May '23)
Kotlin is a fairly new programming language from JetBrains, the people behind InteliJ. It's draws on the best bits of languages like Java, C#, Groovy, to provide us with an easy-to-learn powerful tool for writing great software
How I Learned to Stop Worrying and Love Legacy Code - Ox:Agile 2018Mike Harris
I never wrote it; everybody else did! How many times have you waded through an ageing, decaying, tangled forrest of code and wished it would just die? How many times have you heard someone say that what really needs to happen is a complete rewrite? I have heard this many times, and, have uttered that fatal sentence myself. But shouldn’t we love our legacy code? Doesn’t it represent our investment and the hard work of ourselves and our predecessors? Throwing it away is dangerous, because, before we do, we’ll need to work out exactly what it does, and we’ll need to tweeze out that critical business logic nestled in a deeply entangled knot of IF statements. It could take us years to do, and we’ll have to maintain two systems whilst we do it, inevitably adding new features to them both. Yes we get to reimplement using the latest, coolest programming language, instead of an old behemoth, but how long will our new cool language be around, and who will maintain that code, when it itself inevitably turns to legacy? We can throw our arms in the air, complaining and grumbling about how we didn’t write the code, how we would never have written it the way it is, how those that wrote it were lesser programmers, possibly lesser humans themselves, but the code still remains, staring us in the face and hanging around for longer that we could possibly imagine. We can sort it out, we can improve it, we can make it testable, and we can learn to love our legacy code.
https://www.youtube.com/watch?v=qRP45l5UugE
Ever come to the point of releasing that code into production only to find that the third-party API you're integrating with for some reason doesn't do what you expected? Ever spent time on remote calls fiddling with the third-party's engineers to get that piece of work out of the door? If you have then you know that can be stressful, unpredictable,
Contract Testing can help. They permit an agreement to be drawn up in the form of tests between the provider and consumer that both code to. They allow the two sides to continue development at their own paces, allow developers to test locally without external dependencies, and greatly increase the certainly that your code in test will integrate in production.
This is heavy doc! Lessons on just in time architecture - Adrian PotterMike Harris
Doc Brown's De Lorrean is an icon of time travel genius. But it wasn't always plain sailing. From flight, to fusion, to steam power, time travel evolved as neccessity demanded. Is the same thing true of our software? Whether we're binning our up-front design effort one sprint in, recoiling in horror at our emergenet architecture, or wondering why we built a million dollar space pen when a pencil will do, spending just the right amount of time on our architecture is a tricky business. Come join me on a journey with the Back To The Future team as we accelerate 1600 journals to 88mph and jump them from Evise to EM. What worked, what went wrong, and what can we learn to prevent universe ending paradoxes?
Talk from Ox:Agile 2019 conference by Adrian Potter.
Working towards ideal ux, product and tech partnershipMike Harris
“More often UX role is the interloper between product and technology, what does it take to work effectively in the UX role, keep product and technology in touch with the user needs and to ensure that the product outcomes are ‘delighting the user’.”
- Talk given by Liz Brandshaw and Anna Peniaskova for Ox:Agile Conference 2019
How To Handle Your Tech Debt Better - Sean MoirMike Harris
Technical Debt, Legacy Code, Legacy Systems … whatever you want to call it, is a common problem. It needs to be surfaced to the people whose lives it affects the most: the users; stakeholders; purse holders; and any other recipients of a poor experience. Through awareness of these issues, these stakeholders can understand and endorse a need to change.
Human made systems which once met a need and now cannot change to meet our emerging needs become like a tail wagging a dog. Who is in control here? The system? We humans created these systems - we ought to be able to change them. Note: this doesn’t just apply to technology.
In this session, Sean introduces a simple yet effective way to identify and prioritise what to work on, in a way which makes most sense for stakeholders and custodians.
- Given by Sean Moir for Ox:Agile Conference 2019.
Welcome to Elsevier - presentation for Ox:Agile ConferenceMike Harris
Elsevier's Richard Mclean's introduction to Elsevier and it's approach to software development. Presented at Ox:Agile Conference 2019. https://www.meetup.com/OXAGILE/events/263553769/?isFirstPublish=true
HacktionLab: how LEAN is your non-hierarchical community education projectMike Harris
My own personal perspective on HacktionLab, BarnCamp, and how I arrived there. Plus an introduction to LEAN and an assessment of how LEAN HacktionLab has been. Oh, and a few of my favourite book recommendation.
How I Learned to Stop Worrying and Love Legacy Code.....Mike Harris
Legacy Code. I never wrote it; everybody else did!
How many times have you waded through an ageing, decaying, tangled forrest of code and wished it would just die?
How many times have you heard someone say that what really needs to happen is a complete rewrite?
I have heard this many times, and, have uttered that fatal sentence myself.
But shouldn’t we love our legacy code?
Doesn’t it represent our investment and the hard work of ourselves and our predecessors?
Throwing it away is dangerous, because, before we do, we’ll need to work out exactly what it does, and we’ll need to tweeze out that critical business logic nestled in a deeply entangled knot of IF statements. It could take us years to do, and we’ll have to maintain two systems whilst we do it, inevitably adding new features to them both. Yes we get to reimplement using the latest, coolest programming language, instead of an old behemoth, but how long will our new cool language be around, and who will maintain that code, when it itself inevitably turns to legacy?
We can throw our arms in the air, complaining and grumbling about how we didn’t write the code, how we would never have written it the way it is, how those that wrote it were lesser programmers, possibly lesser humans themselves, but the code still remains, staring us in the face and hanging around for longer that we could possibly imagine. We can sort it out, we can improve it, we can make it testable, and we can learn to love our legacy code.
SOCRadar Research Team: Latest Activities of IntelBrokerSOCRadar
The European Union Agency for Law Enforcement Cooperation (Europol) has suffered an alleged data breach after a notorious threat actor claimed to have exfiltrated data from its systems. Infamous data leaker IntelBroker posted on the even more infamous BreachForums hacking forum, saying that Europol suffered a data breach this month.
The alleged breach affected Europol agencies CCSE, EC3, Europol Platform for Experts, Law Enforcement Forum, and SIRIUS. Infiltration of these entities can disrupt ongoing investigations and compromise sensitive intelligence shared among international law enforcement agencies.
However, this is neither the first nor the last activity of IntekBroker. We have compiled for you what happened in the last few days. To track such hacker activities on dark web sources like hacker forums, private Telegram channels, and other hidden platforms where cyber threats often originate, you can check SOCRadar’s Dark Web News.
Stay Informed on Threat Actors’ Activity on the Dark Web with SOCRadar!
top nidhi software solution freedownloadvrstrong314
This presentation emphasizes the importance of data security and legal compliance for Nidhi companies in India. It highlights how online Nidhi software solutions, like Vector Nidhi Software, offer advanced features tailored to these needs. Key aspects include encryption, access controls, and audit trails to ensure data security. The software complies with regulatory guidelines from the MCA and RBI and adheres to Nidhi Rules, 2014. With customizable, user-friendly interfaces and real-time features, these Nidhi software solutions enhance efficiency, support growth, and provide exceptional member services. The presentation concludes with contact information for further inquiries.
Top Features to Include in Your Winzo Clone App for Business Growth (4).pptxrickgrimesss22
Discover the essential features to incorporate in your Winzo clone app to boost business growth, enhance user engagement, and drive revenue. Learn how to create a compelling gaming experience that stands out in the competitive market.
Climate Science Flows: Enabling Petabyte-Scale Climate Analysis with the Eart...Globus
The Earth System Grid Federation (ESGF) is a global network of data servers that archives and distributes the planet’s largest collection of Earth system model output for thousands of climate and environmental scientists worldwide. Many of these petabyte-scale data archives are located in proximity to large high-performance computing (HPC) or cloud computing resources, but the primary workflow for data users consists of transferring data, and applying computations on a different system. As a part of the ESGF 2.0 US project (funded by the United States Department of Energy Office of Science), we developed pre-defined data workflows, which can be run on-demand, capable of applying many data reduction and data analysis to the large ESGF data archives, transferring only the resultant analysis (ex. visualizations, smaller data files). In this talk, we will showcase a few of these workflows, highlighting how Globus Flows can be used for petabyte-scale climate analysis.
Understanding Globus Data Transfers with NetSageGlobus
NetSage is an open privacy-aware network measurement, analysis, and visualization service designed to help end-users visualize and reason about large data transfers. NetSage traditionally has used a combination of passive measurements, including SNMP and flow data, as well as active measurements, mainly perfSONAR, to provide longitudinal network performance data visualization. It has been deployed by dozens of networks world wide, and is supported domestically by the Engagement and Performance Operations Center (EPOC), NSF #2328479. We have recently expanded the NetSage data sources to include logs for Globus data transfers, following the same privacy-preserving approach as for Flow data. Using the logs for the Texas Advanced Computing Center (TACC) as an example, this talk will walk through several different example use cases that NetSage can answer, including: Who is using Globus to share data with my institution, and what kind of performance are they able to achieve? How many transfers has Globus supported for us? Which sites are we sharing the most data with, and how is that changing over time? How is my site using Globus to move data internally, and what kind of performance do we see for those transfers? What percentage of data transfers at my institution used Globus, and how did the overall data transfer performance compare to the Globus users?
Globus Connect Server Deep Dive - GlobusWorld 2024Globus
We explore the Globus Connect Server (GCS) architecture and experiment with advanced configuration options and use cases. This content is targeted at system administrators who are familiar with GCS and currently operate—or are planning to operate—broader deployments at their institution.
Prosigns: Transforming Business with Tailored Technology SolutionsProsigns
Unlocking Business Potential: Tailored Technology Solutions by Prosigns
Discover how Prosigns, a leading technology solutions provider, partners with businesses to drive innovation and success. Our presentation showcases our comprehensive range of services, including custom software development, web and mobile app development, AI & ML solutions, blockchain integration, DevOps services, and Microsoft Dynamics 365 support.
Custom Software Development: Prosigns specializes in creating bespoke software solutions that cater to your unique business needs. Our team of experts works closely with you to understand your requirements and deliver tailor-made software that enhances efficiency and drives growth.
Web and Mobile App Development: From responsive websites to intuitive mobile applications, Prosigns develops cutting-edge solutions that engage users and deliver seamless experiences across devices.
AI & ML Solutions: Harnessing the power of Artificial Intelligence and Machine Learning, Prosigns provides smart solutions that automate processes, provide valuable insights, and drive informed decision-making.
Blockchain Integration: Prosigns offers comprehensive blockchain solutions, including development, integration, and consulting services, enabling businesses to leverage blockchain technology for enhanced security, transparency, and efficiency.
DevOps Services: Prosigns' DevOps services streamline development and operations processes, ensuring faster and more reliable software delivery through automation and continuous integration.
Microsoft Dynamics 365 Support: Prosigns provides comprehensive support and maintenance services for Microsoft Dynamics 365, ensuring your system is always up-to-date, secure, and running smoothly.
Learn how our collaborative approach and dedication to excellence help businesses achieve their goals and stay ahead in today's digital landscape. From concept to deployment, Prosigns is your trusted partner for transforming ideas into reality and unlocking the full potential of your business.
Join us on a journey of innovation and growth. Let's partner for success with Prosigns.
OpenFOAM solver for Helmholtz equation, helmholtzFoam / helmholtzBubbleFoamtakuyayamamoto1800
In this slide, we show the simulation example and the way to compile this solver.
In this solver, the Helmholtz equation can be solved by helmholtzFoam. Also, the Helmholtz equation with uniformly dispersed bubbles can be simulated by helmholtzBubbleFoam.
Code reviews are vital for ensuring good code quality. They serve as one of our last lines of defense against bugs and subpar code reaching production.
Yet, they often turn into annoying tasks riddled with frustration, hostility, unclear feedback and lack of standards. How can we improve this crucial process?
In this session we will cover:
- The Art of Effective Code Reviews
- Streamlining the Review Process
- Elevating Reviews with Automated Tools
By the end of this presentation, you'll have the knowledge on how to organize and improve your code review proces
Field Employee Tracking System| MiTrack App| Best Employee Tracking Solution|...informapgpstrackings
Keep tabs on your field staff effortlessly with Informap Technology Centre LLC. Real-time tracking, task assignment, and smart features for efficient management. Request a live demo today!
For more details, visit us : https://informapuae.com/field-staff-tracking/
Software Engineering, Software Consulting, Tech Lead.
Spring Boot, Spring Cloud, Spring Core, Spring JDBC, Spring Security,
Spring Transaction, Spring MVC,
Log4j, REST/SOAP WEB-SERVICES.
Accelerate Enterprise Software Engineering with PlatformlessWSO2
Key takeaways:
Challenges of building platforms and the benefits of platformless.
Key principles of platformless, including API-first, cloud-native middleware, platform engineering, and developer experience.
How Choreo enables the platformless experience.
How key concepts like application architecture, domain-driven design, zero trust, and cell-based architecture are inherently a part of Choreo.
Demo of an end-to-end app built and deployed on Choreo.
How to Position Your Globus Data Portal for Success Ten Good PracticesGlobus
Science gateways allow science and engineering communities to access shared data, software, computing services, and instruments. Science gateways have gained a lot of traction in the last twenty years, as evidenced by projects such as the Science Gateways Community Institute (SGCI) and the Center of Excellence on Science Gateways (SGX3) in the US, The Australian Research Data Commons (ARDC) and its platforms in Australia, and the projects around Virtual Research Environments in Europe. A few mature frameworks have evolved with their different strengths and foci and have been taken up by a larger community such as the Globus Data Portal, Hubzero, Tapis, and Galaxy. However, even when gateways are built on successful frameworks, they continue to face the challenges of ongoing maintenance costs and how to meet the ever-expanding needs of the community they serve with enhanced features. It is not uncommon that gateways with compelling use cases are nonetheless unable to get past the prototype phase and become a full production service, or if they do, they don't survive more than a couple of years. While there is no guaranteed pathway to success, it seems likely that for any gateway there is a need for a strong community and/or solid funding streams to create and sustain its success. With over twenty years of examples to draw from, this presentation goes into detail for ten factors common to successful and enduring gateways that effectively serve as best practices for any new or developing gateway.
Paketo Buildpacks : la meilleure façon de construire des images OCI? DevopsDa...Anthony Dahanne
Les Buildpacks existent depuis plus de 10 ans ! D’abord, ils étaient utilisés pour détecter et construire une application avant de la déployer sur certains PaaS. Ensuite, nous avons pu créer des images Docker (OCI) avec leur dernière génération, les Cloud Native Buildpacks (CNCF en incubation). Sont-ils une bonne alternative au Dockerfile ? Que sont les buildpacks Paketo ? Quelles communautés les soutiennent et comment ?
Venez le découvrir lors de cette session ignite
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...Juraj Vysvader
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I didn't get rich from it but it did have 63K downloads (powered possible tens of thousands of websites).
Providing Globus Services to Users of JASMIN for Environmental Data AnalysisGlobus
JASMIN is the UK’s high-performance data analysis platform for environmental science, operated by STFC on behalf of the UK Natural Environment Research Council (NERC). In addition to its role in hosting the CEDA Archive (NERC’s long-term repository for climate, atmospheric science & Earth observation data in the UK), JASMIN provides a collaborative platform to a community of around 2,000 scientists in the UK and beyond, providing nearly 400 environmental science projects with working space, compute resources and tools to facilitate their work. High-performance data transfer into and out of JASMIN has always been a key feature, with many scientists bringing model outputs from supercomputers elsewhere in the UK, to analyse against observational or other model data in the CEDA Archive. A growing number of JASMIN users are now realising the benefits of using the Globus service to provide reliable and efficient data movement and other tasks in this and other contexts. Further use cases involve long-distance (intercontinental) transfers to and from JASMIN, and collecting results from a mobile atmospheric radar system, pushing data to JASMIN via a lightweight Globus deployment. We provide details of how Globus fits into our current infrastructure, our experience of the recent migration to GCSv5.4, and of our interest in developing use of the wider ecosystem of Globus services for the benefit of our user community.
Cyaniclab : Software Development Agency Portfolio.pdfCyanic lab
CyanicLab, an offshore custom software development company based in Sweden,India, Finland, is your go-to partner for startup development and innovative web design solutions. Our expert team specializes in crafting cutting-edge software tailored to meet the unique needs of startups and established enterprises alike. From conceptualization to execution, we offer comprehensive services including web and mobile app development, UI/UX design, and ongoing software maintenance. Ready to elevate your business? Contact CyanicLab today and let us propel your vision to success with our top-notch IT solutions.
2. My Plan
• Introduce myself
• Give the background to why I think this is important
• Introduce eXtreme Programming
• Look at how XP works alongside other methodologies
• Outline some XP-like practices I use and think are helpful
• Sum up
3. Me
• Developed The Fractal Engine for Atari ST in
GFA BASIC and 68000 assembler
• Degree in Computing for Real-Time Systems
• On and off software engineer since then
• Developed CMS systems through the nineties
and noughties in ColdFusion, Perl, and PHP
• Heard about XP first in 2005; dismissed it!
• Finally started to pay attention to XP in 2013
• Have since evangelised it wherever I’ve
worked in software development teams
• Recently I’ve been working in ColdFusion
again!
FOR a&=line_start& TO line_end&
'
temp%=real%(a&)
reg%(0)=temp%
temp=temp%
temp_2%=temp*temp/jul_div% ! x2
reg%(4)=temp_2% ! 16 BIT ONLY
reg%(8)=temp_2% ! 32 BIT ONLY
temp%=imag%(line_pos&)
reg%(1)=temp%
temp=temp%
temp_2%=temp*temp/jul_div% ! x2
reg%(5)=temp_2% ! 16 BIT ONLY.
reg%(9)=temp_2% ! 32 BIT ONLY.
reg%(7)=max_it&
reg%(10)=c_re%
reg%(11)=c_im%
RCALL address%,reg%()
'
it%=reg%(7)
IF NOT it%=65535
it%=(2+max_it&-it%) DIV spread|
PSET a&,line_pos&,col_index|(it% MOD 14+2)
ENDIF
'
NEXT a&
4. Why this talk?
If you’re not practising XP, you’re probably not writing your best software.
5. Project X – From the Outside
• Experienced crew on same platform for years
• Huge backlog of unprioritized work
• Unavailable in the mornings
• Customer had no faith in team’s ability to deliver
• Strong lead developer with clear vision
• Delivery unpredictable
• Large spreadsheet of backlog representing “The Grand Scheme”
• Plan to stop all other work and deliver TGS
6. Project X – From the Inside
• Almost all code is legacy code (no tests at all)
• Complex tightly-coupled system (hard to change)
• Dragon infested areas of the code (can’t be changed)
• Priorities based on biggest manager ego
• Master developer telling everyone what to do
• Other developers unable to make decisions for themselves
• No version control
• Single shared dev environment
• Dev was never equal to Prod
7. Project Y – From the Outside
• A high performing delivery team
• Experienced crew on same platform for years
• Great relations with customer
• Excellent inter-personal relations in team
• Perception of delivery fast and on time
• Well managed customer relations and expectations
• Lovely cycle-time graphs produced
• Nice burn-up charts delivered
• Excellent Scrum ceremony management
8. Project Y – From the Inside
• Almost all code was legacy code (not tested)
• Complex tightly-coupled system (hard to change)
• Dragon infested areas of the code (can’t be changed)
• BDD test suite was retro fitted and took a long time to run, often failing
unpredictably (and therefore was not run often)
• Large overhead of story writing, development, QA hand-offs
• Deployment took up to a day to arrange
• And several hours to do
• Production version of code did not exist in version control
• Lots of siloed knowledge amongst developers
• SysOps and Devs siloed; not shared understanding of full tech stack
10. So, what is XP?
A brief recap of eXtreme Programming
11. Hang on, but what is Agile?
Agile is not about going fast,
it’s about knowing, as early as possible,
just how screwed we are.
- Robert C. Martin
12. Agile Values
• Individuals and Interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
13. So, what is XP?
A brief recap of eXtreme Programming
14. What is XP?
• Coined by Kent Beck approx. 1996-03-06
• Who had worked previously with Ward Cunningham at Tektronix
in the 1980s
• Refined methodology he’d used on the payroll project
Chrysler Comprehensive Compensation System (C3)
• Into his book ”Extreme Programming Explained”
• Which was published way back in October 1999
• (The 2nd Edition of the book was published in 2004)
• He didn’t invent all the practices (such as TDD)
• He codified them into an umbrella methodology: XP
16. XP Principles
• Humanity
Safe space for collaboration and growth
• Economics
Must be affordable, must meet business values
• Mutual Benefit
What we do we do for the benefit of everyone
• Self-Similarity
Reuse solutions even at different scales
• Improvement
Perfect your process; not a perfect process
• Diversity
Team members have a variety of skills, celebrate this
• Reflexion
Think about how and why we’re working in the way we are
• Flow
Deliver a steady flow of valuable software
• Opportunity
Problems are opportunities for change and improvement
• Redundancy
Solve critical difficult to solve problems in several different ways
• Failure
Don’t be afraid of it
• Quality
Do not accept lower quality to make products go faster
• Baby Steps
Do things a little bit at a time
• Accepted Responsibility
You decide if you are responsible or if you’re not
22. XP and the Agile Manifesto
• Individuals and Interactions over processes and tools
• Whole Team, Metaphor, Collective Ownership, Pairing, Sustainable Pace
• Working software over comprehensive documentation
• Acceptance Tests, TDD, Simple Design, Refactoring, Continuous Integration
• Customer collaboration over contract negotiation
• Small Releases, Planning Game, Acceptance Tests, Consistent Metaphor
• Responding to change over following a plan
• Small Releases, Planning Game, Sustainable Pace, TDD, Refactoring,
Acceptance Tests
23. Kanban with XP
• Whole Team
• Consistent Metaphor
• Collective Ownership
• Pairing
• Sustainable Pace
• Acceptance Tests
• TDD
• Simple Design
• Refactoring
• Continuous Integration
• Small Releases
• Planning Game
看
板
24. Scrum with XP
• Whole Team
• Consistent Metaphor
• Collective Ownership
• Pairing
• Sustainable Pace
• Acceptance Tests
• TDD
• Simple Design
• Refactoring
• Continuous Integration
• Small Releases
• Planning Games Delivery
25. Waterfall with XP
• Whole Team
• Consistent Metaphor
• Collective Ownership
• Pairing
• Sustainable Pace
• Acceptance Tests
• TDD
• Simple Design
• Refactoring
• Continuous Integration
• Small Releases
• Planning Game
26. But hang on one minute….
Winston W. Royce's final model illustrated that feedback could (should, and often
would) lead from code testing to design and from design back to requirements. In the
same paper Royce also advocated large quantities of documentation, doing the job
"twice if possible" (a sentiment similar to that of Fred Brooks, famous for writing the
Mythical Man Month, an influential book in software project management, who
advocated planning to "throw one away"), and involving the customer as much as
possible (a sentiment similar to that of Extreme Programming).
30. Royce’s Five Practices
1. Design Comes First
- Customer should know roughly what they want.
- Stories should be minimally scoped
2. Document the Design
- Document architecture and integration points
- Code should be self-documenting
3. Do It Twice
- Spikes, MVPs, Prototypes
- Cross-functional teams
4. Plan, Control, Monitor Testing
- This is most changed, due to CI/CB and move away from siloed QA
5. Involve the Customer
- Customer collaboration over contract negotiation
31. XP’s Technical & Team Practices
Filling in the Software Project Hole
32. Simple Design
• Keep your design as simple as possible (KISS)
• Only implement what you need
• Practise YAGNI (You Ain’t Gonna Need It)
• Practise the Rule of Three
• Domain Driven approaches will help you
• Test Driven Development will make your code simpler
• Don’t write code unless you really need to
33. Do TDD. Like really do it.
• Write your test first
• Make it pass
• Refactor
• Write another test
• Repeat
35. Refactor
• Do it all the time
• Do it constantly
• Do it as soon as possible
• Don’t ask for permission
• Don’t make it a story
• Don’t leave doing it
• Your code will rot if you don’t!
36. Write Self-Documenting Code
• Our code should be self-explanatory
• Comments should document whys not whats or hows
• Classes, methods, variables, etc, should have meaningful names.
• When starting out, call something a foo; until you know what it does
• Use your IDE to help improve your code’s readability
• Spend time refactoring every bit of code you touch
• Even the code that isn’t yours
• In fact all code is yours if you’re working with it
37. Continuous Integration
• Learn how to use Git
• Like, really learn how to use the different Git commands
• Regularly merge/rebase master if using feature branch
• But, aim for trunk-based development
• Regularly merge back to master and push
• Like regularly, measured in minutes, not hours, nor days
39. Pair Programming
• Reduces need for code reviews, QA checks, etc
• Helps share knowledge in the team
• Helps eliminate silos
• Two heads really are better than one
• Just do it!
• But it is a practice
• Make sure you do it right
• And don’t do it all the time
40. Tiny Tasking
• Great technique to use with pair programming
• Break a small story into baby steps
• Agree first with your pairing partner
• Put the critical path on sticky notes and place them on the desk in front
• Go into a correct level of detail
• Too many tiny tasks indicate:
• Too much up front planning
• A story that’s too big
• Tiny tasks are too small
• A new person rolling on to a story can catch up on the tasks left to do
• This gives you both a way of transferring knowledge and establishing context
41. Mob Programming
• Great for on-boarding new team
members
• Great for new project/work inception
• Take breaks regularly
• Avoid ‘mob Googling’
• Hold daily retros
• Have a mob programming charter
42. Collective Ownership
• You may have wrote it, but it’s not your code
• The team owns the code
• Not you
• Be prepared to work on other code
• Be prepared for someone to change, or even delete, your code
• Be prepared to jump onto a story when someone is away
43. Technical Debt Wall
• It’s about knowing what the risks are
• Keep a Tech Debt Wall (Trello is a good tool for this)
• Note down any technical debt you accrue as you develop
• Consider the risk of postponing resolution vs the cost of sorting now
• Don’t engineer the future: resolve in the next iteration
• Regularly review the Tech Debt Wall
• Categorise the debt on the wall
• Take highest risk technical debt into backlog and resolve
• Delete technical debt that no longer is, or is no longer relevant
45. Project Z – Where we were
• We were doing pretty much all of the XP and other practices outlined
• Our Tech Lead and founding architect left for a Start Up
• Two other contracted developers moved on at the same time
• We took on two new developers shortly afterwards
• We were a small team with lots of risk
• Loosing critical mass on our dev practices was a possibility
• There was potentially a lot of overhead onboarding new folks
• And this would slow us down
46. Project Z – The Results
• The fact we’d done pair programming meant
• All developers had some knowledge of every part of the software
• Within weeks we were able to do a complete hand-over
• And made a smooth transition to a new tech lead
• Pairing and mobbing meant that new developers could do valuable
work from day one
• Our code was self-documenting and covered by descriptive tests
• Helped with onboarding new members
• No balls were dropped
47. In Summary
• Adopting Scrum, Kanban, or a hybrid, on it’s own is not enough
• They won’t lead you to do Agile Software Development
• As they are primarily methods for managing software projects
• XP helps you write better software
• XP helps you to mitigate against legacy code
• You may not be able to do everything
• But at least do some of the things
• It can be hard to change
• But keep at it; you will get there
• XP will even work with Waterfall methodologies
• The Fractal Engine was the best software project I’ve been involved in
• ColdFusion is still a thing
48. Perhaps Uncle Bob puts it better?
Without TDD, Refactoring, Simple Design,
and yes, even Pair Programming,
Agile becomes an ineffectual flaccid
shell of what it was intended to be.
- Robert C. Martin
49. What happened to Frank?
• The Author of GFA BASIC
• And Turbo-Basic XL for Atari 8 bit
• Atari ST support ended in 1991
• By 2002 GFA was Bankrupt
Frank Ostrowski 1960 - 2011
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.
Oldest reference may be in “Digital Computer Programming” Daniel D. McCracken, 1957
Ward Cunningham, the granddaddy, invented the Wiki (WikiWikiWeb)
Martin Fowler at the board, then Dave Thomas, not sure, Bob Martin, Jim Highsmith, not sure, Ron Jeffries, James Grenning
Important to note speed as a factor, for example we have Git, he had probably punch cards, to work with.Also the programming languages, such as Fortran, BASIC, COBOL, Algol, PL/1
YAGNI grows from a too much future anticipation, overzealous workers if you may. KISS is a strategy that tries to counteract human tendency for design creep.