The document discusses motivating developers to follow agile practices when transitioning from legacy software development. It notes that simply adopting new technologies does not ensure good practices are followed and that the underlying issue is developing discipline among the development team. It suggests upgrading the team from legacy to agile practices through focusing initially on basic disciplines like source control, testing and continuous integration.
[QaOps] Continuouss Integration | Pipeline strategyRafael Lima
In this presentation (https://youtu.be/ViVwbrylP2E) I talk about Continuous Integration and pipeline strategy, showing many shapes of the test pyramid and which strategy to use when facing them. I also talk about monoliths, microservices and the relevance of the test pyramid nowadays.
QaOps channel: http://videos.qa-ops.com
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.
This presentation was at the Japanese Perl Association Seminar #1 in Akihabara on April 21st, 2009.
It covers ideas for how to have establish good habits one by one, and strategies to get them to stick.
This is my talk aimed at helping teams to grow their skills and for individual developers to reach for their next stage of career development. Given in Poland at phpconpl in 2011
[QaOps] Continuouss Integration | Pipeline strategyRafael Lima
In this presentation (https://youtu.be/ViVwbrylP2E) I talk about Continuous Integration and pipeline strategy, showing many shapes of the test pyramid and which strategy to use when facing them. I also talk about monoliths, microservices and the relevance of the test pyramid nowadays.
QaOps channel: http://videos.qa-ops.com
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.
This presentation was at the Japanese Perl Association Seminar #1 in Akihabara on April 21st, 2009.
It covers ideas for how to have establish good habits one by one, and strategies to get them to stick.
This is my talk aimed at helping teams to grow their skills and for individual developers to reach for their next stage of career development. Given in Poland at phpconpl in 2011
Paving the Way for Agile Engineering PracticesAman King
Talk focused on preparing to apply Agile Engineering Practices on an existing code base. Most existing projects differ in structure and quality compared to greenfield Agile projects. They often suffer from Code Smells, Architectural Smells, and Deployment Smells. Overcoming these in an evolutionary manner is key to paving the way for successful application of Agile Engineering Practices. Failure to do so could lead to stress and counterproductive results. This presentation covers why, what, and how of some useful techniques.
Presented at Agile in Business conference at Pune, India, during India Agile Week (Oct 2013).
Clients need to know how much a project will cost. Waterfall development is always late and over-budget. Agile development is done when it's done. You're left with estimates that you know are too low and then you squeeze them anyway. It shouldn't be this way. We'll look at how this happens, early warning signs, ways out and ways of avoiding it in the first place.
Effective Strategies for Distributed TestingAnand Bagmar
Thoughts, experiences and case studies on how to convert Testing principles into practices. We focus on the practices of making testing effective on distributed teams by keeping things simple, yet effective.
http://testing.thoughtworks.com/events/effective-strategies-distributed-testing
Slides from David Laribee's presentation at Agile Day Twin Cities 2019, hosted on November 20th at the RiverCentre in Saint Paul, MN.
https://www.agiledaytwincities.com/
As companies mature their software development practices, automated acceptance-level testing is becoming more commonplace. In particular, Cucumber and its Gherkin-based equivalents are enjoying widespread use. Through observing and facilitating the adoption and implementation of Cucumber test suites, I have found ways in which the technology has helped teams greatly, but I have also found ways in which it hindered them. I realized that Cucumber and its kin are appropriate tools in fewer situations than the ones in which they are currently employed. In other words, many teams that use such frameworks need to reevaluate whether they are right for the job, and perhaps replace them. I invite all involved in automated acceptance testing to attend as I try to build a compelling case for this notion.
So you want to go Git, but other stakeholders in your organization aren't quite convinced it's worth the effort? This talk will explain why migrating to Git is a win for the whole business – not just developers. We'll give you the ammunition you need to convince your team that the switch to Git is a no-brainer.
Presented at JAX London 2013.
Software craftsman and co-founder of the London Software Craftsmanship Community (LSCC). Sandro has been coding since a very young age but just started his professional career in 1996. He has worked for startups, software houses, product companies and international consultancy companies. Having worked as a consultant for the majority of his career, he had the opportunity to work in a good variety of projects, with different languages and technologies, and across many industries. Currently he is a director at UBS Investment Bank, where he works as a hands-on mentor, giving technical directions, looking after the quality of the systems and pair-programming with developers in the UK and abroad. His main objective is to help developers to become real software craftsmen.
Paris Web - Javascript as a programming languageMarco Cedaro
How to setup up a stable javascript continuous integration environment and why you need it. Through a real life example, the talk explains all the benefits of having a development process that brings real control over javascript codebase. A deep analysis of developer and webapps needs and of the tools that fit those requirements.
Achieving Technical Excellence in Your Software Teams - from Devternity Peter Gfader
Our industry has a problem: We are not lacking software methodologies, programming languages, tools or frameworks but we need great software engineers.
Great software engineer teams build quality-in and deliver great software on a regular basis. The technical excellence of those engineers will help you escape the "Waterfall sandwich" and make your organization a little more agile, from the inception of an idea till they go live.
I will talk about my experiences from the last 15 years, including small software delivery teams until big financial institutions.
Why would a company like to be "agile"?
How can a company achieve that?
How can you achieve Technical Excellence in your software teams?
What developer skills are more important than languages, methods or frameworks?
This will be an interactive session with a Q&A at the end.
James Whittaker - Pursuing Quality-You Won't Get There - EuroSTAR 2011TEST Huddle
EuroSTAR Software Testing Conference 2011 presentation on Pursuing Quality-You Won't Get There by James Whittaker. See more at: http://conference.eurostarsoftwaretesting.com/past-presentations/
Paving the Way for Agile Engineering PracticesAman King
Talk focused on preparing to apply Agile Engineering Practices on an existing code base. Most existing projects differ in structure and quality compared to greenfield Agile projects. They often suffer from Code Smells, Architectural Smells, and Deployment Smells. Overcoming these in an evolutionary manner is key to paving the way for successful application of Agile Engineering Practices. Failure to do so could lead to stress and counterproductive results. This presentation covers why, what, and how of some useful techniques.
Presented at Agile in Business conference at Pune, India, during India Agile Week (Oct 2013).
Clients need to know how much a project will cost. Waterfall development is always late and over-budget. Agile development is done when it's done. You're left with estimates that you know are too low and then you squeeze them anyway. It shouldn't be this way. We'll look at how this happens, early warning signs, ways out and ways of avoiding it in the first place.
Effective Strategies for Distributed TestingAnand Bagmar
Thoughts, experiences and case studies on how to convert Testing principles into practices. We focus on the practices of making testing effective on distributed teams by keeping things simple, yet effective.
http://testing.thoughtworks.com/events/effective-strategies-distributed-testing
Slides from David Laribee's presentation at Agile Day Twin Cities 2019, hosted on November 20th at the RiverCentre in Saint Paul, MN.
https://www.agiledaytwincities.com/
As companies mature their software development practices, automated acceptance-level testing is becoming more commonplace. In particular, Cucumber and its Gherkin-based equivalents are enjoying widespread use. Through observing and facilitating the adoption and implementation of Cucumber test suites, I have found ways in which the technology has helped teams greatly, but I have also found ways in which it hindered them. I realized that Cucumber and its kin are appropriate tools in fewer situations than the ones in which they are currently employed. In other words, many teams that use such frameworks need to reevaluate whether they are right for the job, and perhaps replace them. I invite all involved in automated acceptance testing to attend as I try to build a compelling case for this notion.
So you want to go Git, but other stakeholders in your organization aren't quite convinced it's worth the effort? This talk will explain why migrating to Git is a win for the whole business – not just developers. We'll give you the ammunition you need to convince your team that the switch to Git is a no-brainer.
Presented at JAX London 2013.
Software craftsman and co-founder of the London Software Craftsmanship Community (LSCC). Sandro has been coding since a very young age but just started his professional career in 1996. He has worked for startups, software houses, product companies and international consultancy companies. Having worked as a consultant for the majority of his career, he had the opportunity to work in a good variety of projects, with different languages and technologies, and across many industries. Currently he is a director at UBS Investment Bank, where he works as a hands-on mentor, giving technical directions, looking after the quality of the systems and pair-programming with developers in the UK and abroad. His main objective is to help developers to become real software craftsmen.
Paris Web - Javascript as a programming languageMarco Cedaro
How to setup up a stable javascript continuous integration environment and why you need it. Through a real life example, the talk explains all the benefits of having a development process that brings real control over javascript codebase. A deep analysis of developer and webapps needs and of the tools that fit those requirements.
Achieving Technical Excellence in Your Software Teams - from Devternity Peter Gfader
Our industry has a problem: We are not lacking software methodologies, programming languages, tools or frameworks but we need great software engineers.
Great software engineer teams build quality-in and deliver great software on a regular basis. The technical excellence of those engineers will help you escape the "Waterfall sandwich" and make your organization a little more agile, from the inception of an idea till they go live.
I will talk about my experiences from the last 15 years, including small software delivery teams until big financial institutions.
Why would a company like to be "agile"?
How can a company achieve that?
How can you achieve Technical Excellence in your software teams?
What developer skills are more important than languages, methods or frameworks?
This will be an interactive session with a Q&A at the end.
James Whittaker - Pursuing Quality-You Won't Get There - EuroSTAR 2011TEST Huddle
EuroSTAR Software Testing Conference 2011 presentation on Pursuing Quality-You Won't Get There by James Whittaker. See more at: http://conference.eurostarsoftwaretesting.com/past-presentations/
Kickass Agile Development - Agile & Beyond ConferenceDan Chuparkoff
Watch Dan Chuparkoff as he shares some of the secrets to kick-ass software development at Atlassian. He gives us a glimpse at a new Agile paradigm. Feedback cycles are short, code quality is awesome, and customers get the features they lust after. Hear how Atlassian uses pull-requests for better code quality; collaborates fast to develop ideas; avoids meetings; tightens feedback loops to fail fast; shortens release cycles and work together happily from different corners of the globe. Sound like paradise? It is!
The Agile Manifesto in the Star Wars UniverseAaron Griffith
What better way to study the Agile Manifesto, than in the fun and easily understandable context of Star Wars?!
When discussing the Agile Manifesto it some times help to put it in easily understandable terms. What better way to do that, than presenting the Agile Manifesto in the context of Star Wars. This talk looks at the Agile Manifesto and using examples from the Star Wars Universe shows the similarities and differences in the way the Rebel Alliance and Empire put the Agile Manifesto into practice. Those new to Agile Software Development will find it a light hearted, fun, and easily understood explanation of the Agile Manifesto and Agile Principles in the context of Star Wars. Agile veterans that are already familiar with the Agile Manifesto will get a better understanding and new perspective that is meant to be interesting and humorous.
Key Learnings
At a minimum attendees at this talk will become aware of the Agile Manifesto in a fun and interesting way.
Those that are already familiar with the Agile Manifesto will get a better understanding and new perspective that is meant to be interesting and humorous.
Talk that introduces useful techniques to bring agility into a legacy codebase. Covers code smells, design smells, architectural smells, and deployment smells. Examples are representative of typical Java legacy projects. Includes refactoring screencasts.
Presented at GIDS.Java 2015 in Bangalore, India.
A version of the Conflict Resolution Diagram / Evaporating Cloud talk/workshop I prepared for a SCiO Open Day in Manchester: http://www.scio.org.uk/node/760
These are the slides to a lightning talk on I gave at the PHPNW meetup on 6 Aug 2013. It's an incomplete, slightly skewed look at how I apply Personal Kanban myself. - Ash
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
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
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.
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
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.
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
1. Encouraging Agile Discipline
Motivating developers to follow agile practices
This work is released under the terms of the Ashley Moran
Creative Commons Attribution-Share Alike licence PatchSpace Ltd
3. The Business Problem
You have have to upgrade your legacy software to
keep your competitive advantage
4. The Business Problem
You have have to upgrade your legacy software to
keep your competitive advantage
Upgrading your legacy software is taking too long -
you’re falling behind and wasting money
5. The Business Problem
You have have to upgrade your legacy software to
keep your competitive advantage
Upgrading your legacy software is taking too long -
you’re falling behind and wasting money
Software is a technical endeavour, so there’s a
technical solution to your business problem
6. The Business Problem
You have have to upgrade your legacy software to
keep your competitive advantage
Upgrading your legacy software is taking too long -
you’re falling behind and wasting money
Software is a technical endeavour, so there’s a
technical solution to your business problem
Right?
10. Some Technical Solutions
Move to a more powerful language
Python, Ruby, Erlang, Smalltalk
Create a more flexible architecture
Marc Johnson: Laying Your Legacy to REST
11. Some Technical Solutions
Move to a more powerful language
Python, Ruby, Erlang, Smalltalk
Create a more flexible architecture
Marc Johnson: Laying Your Legacy to REST
Go “Agile”
15. Our Example Problem
We want our HTML web app available as a web
service...
...but half of our business logic is in the JavaScript and
half is on the server.
16. Our Example Problem
We want our HTML web app available as a web
service...
...but half of our business logic is in the JavaScript and
half is on the server.
We need to refactor our code
17. Our Example Problem
We want our HTML web app available as a web
service...
...but half of our business logic is in the JavaScript and
half is on the server.
We need to refactor our code
We’re scared to refactor because previous attempts
have broken other parts of our app
18. Our Example Problem
We want our HTML web app available as a web
service...
...but half of our business logic is in the JavaScript and
half is on the server.
We need to refactor our code
We’re scared to refactor because previous attempts
have broken other parts of our app
to be continued...
20. The Underlying Problem
Software technologies don’t make you follow good
practices, they just remove obstacles to them
21. The Underlying Problem
Software technologies don’t make you follow good
practices, they just remove obstacles to them
You could have followed good practices with your old
technologies
22. The Underlying Problem
Software technologies don’t make you follow good
practices, they just remove obstacles to them
You could have followed good practices with your old
technologies
Fred Brooks wrote automated tests in the 1970s
23. The Underlying Problem
Software technologies don’t make you follow good
practices, they just remove obstacles to them
You could have followed good practices with your old
technologies
Fred Brooks wrote automated tests in the 1970s
You still have the same team of developers for the new
application that you had for the old one
24. The Underlying Problem
Software technologies don’t make you follow good
practices, they just remove obstacles to them
You could have followed good practices with your old
technologies
Fred Brooks wrote automated tests in the 1970s
You still have the same team of developers for the new
application that you had for the old one
Some of them see the need to improve the process
25. The Underlying Problem
Software technologies don’t make you follow good
practices, they just remove obstacles to them
You could have followed good practices with your old
technologies
Fred Brooks wrote automated tests in the 1970s
You still have the same team of developers for the new
application that you had for the old one
Some of them see the need to improve the process
Some of them don’t
29. Our Example Problem ctnd.
...we were left needing to refactor our code
In order to refactor we need a comprehensive test suite
30. Our Example Problem ctnd.
...we were left needing to refactor our code
In order to refactor we need a comprehensive test suite
Why don’t we have one?
31. Our Example Problem ctnd.
...we were left needing to refactor our code
In order to refactor we need a comprehensive test suite
Why don’t we have one?
Need unapparent?
32. Our Example Problem ctnd.
...we were left needing to refactor our code
In order to refactor we need a comprehensive test suite
Why don’t we have one?
Need unapparent?
Perceived lack of time?
33. Our Example Problem ctnd.
...we were left needing to refactor our code
In order to refactor we need a comprehensive test suite
Why don’t we have one?
Need unapparent?
Perceived lack of time?
Apathy?
34. Our Example Problem ctnd.
...we were left needing to refactor our code
In order to refactor we need a comprehensive test suite
Why don’t we have one?
Need unapparent?
Perceived lack of time?
Apathy?
Oh shit, it’s too late
35. Our Example Problem ctnd.
...we were left needing to refactor our code
In order to refactor we need a comprehensive test suite
Why don’t we have one?
Need unapparent?
Perceived lack of time?
Apathy?
Oh shit, it’s too late
If we tried to create one, would we be successful?
37. A Field Guide to
Post-Legacy Developers
Enthusiastic
“The last project was slow and painful. I was here deploying at 2am on Friday
night and we spent days firefighting the week after. I want to learn how to
release software smoothly like the successful agile teams.”
38. A Field Guide to
Post-Legacy Developers
Enthusiastic
“The last project was slow and painful. I was here deploying at 2am on Friday
night and we spent days firefighting the week after. I want to learn how to
release software smoothly like the successful agile teams.”
Neutral
“This agile thing sounds like it could work, but I’m not convinced. It seems like
a lot of work for me. We already know our software works, why should we
spend time refactoring and testing it?”
39. A Field Guide to
Post-Legacy Developers
Enthusiastic
“The last project was slow and painful. I was here deploying at 2am on Friday
night and we spent days firefighting the week after. I want to learn how to
release software smoothly like the successful agile teams.”
Neutral
“This agile thing sounds like it could work, but I’m not convinced. It seems like
a lot of work for me. We already know our software works, why should we
spend time refactoring and testing it?”
Lazy
“Why should I learn agile? I’ve been programming the same way for years and
I’m not going to change now.”
“By the way it’s 5.30pm, I’m off home. Have fun with the deploy.”
42. Stick vs Carrot
Are the members of your team enthusiastic, neutral, or
lazy?
43. Stick vs Carrot
Are the members of your team enthusiastic, neutral, or
lazy?
Will they try not to break the continuous integration
server...
44. Stick vs Carrot
Are the members of your team enthusiastic, neutral, or
lazy?
Will they try not to break the continuous integration
server...
because they want to to keep the code deployable?
45. Stick vs Carrot
Are the members of your team enthusiastic, neutral, or
lazy?
Will they try not to break the continuous integration
server...
because they want to to keep the code deployable?
or because they get shouted at?
48. Skill vs Discipline
Technical skill
Low High
Poor Daily WTF Nerd
Discipline
Rockstar
Good N00b
developer
49. Skill vs Discipline
Technical skill
Low High
Poor Daily WTF Nerd
Discipline
Rockstar
Good N00b
developer
Do you need to move the team in this direction?
50. Skill vs Discipline
Technical skill
Low High
Or do you
Poor Daily WTF Nerd
Discipline
just need
more
nerds?
Rockstar
Good N00b
developer
Do you need to move the team in this direction?
57. Agile needs...
Technical skill
Low High
Poor Simplicity / elegance
Discipline
Continuous integration
Source control Test-driven development
Collective ownership Refactoring
Good Coding standards Building deployment scripts
Basic testing Building CI environments
Using deployment scripts
58. Agile needs...
Technical skill
Low High
Poor Simplicity / elegance
Discipline
Continuous integration
Source control Test-driven development
Collective ownership Refactoring
Good Coding standards Building deployment scripts
Basic testing Building CI environments
Using deployment scripts
Discipline is your initial bottle-neck to becoming agile
62. The Underlying Solution
A highly-disciplined bunch of über-geeks
If you are willing to pay 50k+ a head
63. The Underlying Solution
A highly-disciplined bunch of über-geeks
If you are willing to pay 50k+ a head
Maybe
64. The Underlying Solution
A highly-disciplined bunch of über-geeks
If you are willing to pay 50k+ a head
Maybe
Maybe not
65. The Underlying Solution
A highly-disciplined bunch of über-geeks
If you are willing to pay 50k+ a head
Maybe
Maybe not
To upgrade your code from legacy to agile,
upgrade your team from legacy to agile
Introduce self. This is my first talk/led discussion. If I speak to fast, or too quietly, please stop me as soon as possible. I’ve prepared 12 slides to introduce the subject.
To begin with, let’s look at the typical business situation that highlights the need for a technological improvement.
AT END:
The most concrete part of this is the programming language. Expressing business logic in Ruby is easier than expressing it in Java. Building a fault-tolerant media server is easier in Erlang than in C++.
A more abstract part of the solution is to define the boundaries of your app and build a service-oriented solution. Now your billing and site admin code can be in Ruby, and your video processing code can be in Erlang. The inspiration for this talk was Marc Johnson’s huddle at the previous Sheffield GeekUp, “Laying Your Legacy to REST”. The key idea being that creating a service-oriented suite of web-services will produce more powerful software quicker.
Of course, you can’t just go rewriting random bits of you app in a new language, and you can’t just go slicing pieces from your legacy code and turning them into services.
To do either of these you will need to follow agile practices. I will present a sample of these layer, but for now I want to give a specific example of a problem they could help solve.
AT END:
The most concrete part of this is the programming language. Expressing business logic in Ruby is easier than expressing it in Java. Building a fault-tolerant media server is easier in Erlang than in C++.
A more abstract part of the solution is to define the boundaries of your app and build a service-oriented solution. Now your billing and site admin code can be in Ruby, and your video processing code can be in Erlang. The inspiration for this talk was Marc Johnson’s huddle at the previous Sheffield GeekUp, “Laying Your Legacy to REST”. The key idea being that creating a service-oriented suite of web-services will produce more powerful software quicker.
Of course, you can’t just go rewriting random bits of you app in a new language, and you can’t just go slicing pieces from your legacy code and turning them into services.
To do either of these you will need to follow agile practices. I will present a sample of these layer, but for now I want to give a specific example of a problem they could help solve.
AT END:
The most concrete part of this is the programming language. Expressing business logic in Ruby is easier than expressing it in Java. Building a fault-tolerant media server is easier in Erlang than in C++.
A more abstract part of the solution is to define the boundaries of your app and build a service-oriented solution. Now your billing and site admin code can be in Ruby, and your video processing code can be in Erlang. The inspiration for this talk was Marc Johnson’s huddle at the previous Sheffield GeekUp, “Laying Your Legacy to REST”. The key idea being that creating a service-oriented suite of web-services will produce more powerful software quicker.
Of course, you can’t just go rewriting random bits of you app in a new language, and you can’t just go slicing pieces from your legacy code and turning them into services.
To do either of these you will need to follow agile practices. I will present a sample of these layer, but for now I want to give a specific example of a problem they could help solve.
AT END:
The most concrete part of this is the programming language. Expressing business logic in Ruby is easier than expressing it in Java. Building a fault-tolerant media server is easier in Erlang than in C++.
A more abstract part of the solution is to define the boundaries of your app and build a service-oriented solution. Now your billing and site admin code can be in Ruby, and your video processing code can be in Erlang. The inspiration for this talk was Marc Johnson’s huddle at the previous Sheffield GeekUp, “Laying Your Legacy to REST”. The key idea being that creating a service-oriented suite of web-services will produce more powerful software quicker.
Of course, you can’t just go rewriting random bits of you app in a new language, and you can’t just go slicing pieces from your legacy code and turning them into services.
To do either of these you will need to follow agile practices. I will present a sample of these layer, but for now I want to give a specific example of a problem they could help solve.
AFTER 2: And who knows which half of the business logic is in the front end? Probably nobody...
AFTER 4: And not just broken something once, but turned development into a game of whack-a-mole. Every time we deploy, some random part of the app breaks. And worse, some parts we fix break again later. In short, creating a web service version of our app could put us out of action for weeks if it goes live with serious bugs.
AFTER 2: And who knows which half of the business logic is in the front end? Probably nobody...
AFTER 4: And not just broken something once, but turned development into a game of whack-a-mole. Every time we deploy, some random part of the app breaks. And worse, some parts we fix break again later. In short, creating a web service version of our app could put us out of action for weeks if it goes live with serious bugs.
AFTER 2: And who knows which half of the business logic is in the front end? Probably nobody...
AFTER 4: And not just broken something once, but turned development into a game of whack-a-mole. Every time we deploy, some random part of the app breaks. And worse, some parts we fix break again later. In short, creating a web service version of our app could put us out of action for weeks if it goes live with serious bugs.
AFTER 2: And who knows which half of the business logic is in the front end? Probably nobody...
AFTER 4: And not just broken something once, but turned development into a game of whack-a-mole. Every time we deploy, some random part of the app breaks. And worse, some parts we fix break again later. In short, creating a web service version of our app could put us out of action for weeks if it goes live with serious bugs.
AFTER 2: And who knows which half of the business logic is in the front end? Probably nobody...
AFTER 4: And not just broken something once, but turned development into a game of whack-a-mole. Every time we deploy, some random part of the app breaks. And worse, some parts we fix break again later. In short, creating a web service version of our app could put us out of action for weeks if it goes live with serious bugs.
AFTER 1: The Ruby community is probably the most test-obsessed, especially since RSpec was released. The quality of good RSpec code is far higher than most JUnit and NUnit tests I’ve seen because RSpec is a more powerful library (in part because it sits on a more powerful language). But even still, I’m fairly sure most Ruby code is poorly tested, or not tested at all.
AFTER 2: Fred Brooks had neither RSpec nor JUnit, and he still automated tests. They certainly weren’t of the quality we can achieve today (now that object-oriented design theory has been embraced), but they were still valuable.
AFTER 3, before 3b: Service-oriented architecture was meant to help create good software design. But the idea of single-responsibility, which is very similar, was already a good design principle before SoA. And that didn’t help before, because not all developers followed it.
AFTER 1: The Ruby community is probably the most test-obsessed, especially since RSpec was released. The quality of good RSpec code is far higher than most JUnit and NUnit tests I’ve seen because RSpec is a more powerful library (in part because it sits on a more powerful language). But even still, I’m fairly sure most Ruby code is poorly tested, or not tested at all.
AFTER 2: Fred Brooks had neither RSpec nor JUnit, and he still automated tests. They certainly weren’t of the quality we can achieve today (now that object-oriented design theory has been embraced), but they were still valuable.
AFTER 3, before 3b: Service-oriented architecture was meant to help create good software design. But the idea of single-responsibility, which is very similar, was already a good design principle before SoA. And that didn’t help before, because not all developers followed it.
AFTER 1: The Ruby community is probably the most test-obsessed, especially since RSpec was released. The quality of good RSpec code is far higher than most JUnit and NUnit tests I’ve seen because RSpec is a more powerful library (in part because it sits on a more powerful language). But even still, I’m fairly sure most Ruby code is poorly tested, or not tested at all.
AFTER 2: Fred Brooks had neither RSpec nor JUnit, and he still automated tests. They certainly weren’t of the quality we can achieve today (now that object-oriented design theory has been embraced), but they were still valuable.
AFTER 3, before 3b: Service-oriented architecture was meant to help create good software design. But the idea of single-responsibility, which is very similar, was already a good design principle before SoA. And that didn’t help before, because not all developers followed it.
AFTER 1: The Ruby community is probably the most test-obsessed, especially since RSpec was released. The quality of good RSpec code is far higher than most JUnit and NUnit tests I’ve seen because RSpec is a more powerful library (in part because it sits on a more powerful language). But even still, I’m fairly sure most Ruby code is poorly tested, or not tested at all.
AFTER 2: Fred Brooks had neither RSpec nor JUnit, and he still automated tests. They certainly weren’t of the quality we can achieve today (now that object-oriented design theory has been embraced), but they were still valuable.
AFTER 3, before 3b: Service-oriented architecture was meant to help create good software design. But the idea of single-responsibility, which is very similar, was already a good design principle before SoA. And that didn’t help before, because not all developers followed it.
AFTER 1: The Ruby community is probably the most test-obsessed, especially since RSpec was released. The quality of good RSpec code is far higher than most JUnit and NUnit tests I’ve seen because RSpec is a more powerful library (in part because it sits on a more powerful language). But even still, I’m fairly sure most Ruby code is poorly tested, or not tested at all.
AFTER 2: Fred Brooks had neither RSpec nor JUnit, and he still automated tests. They certainly weren’t of the quality we can achieve today (now that object-oriented design theory has been embraced), but they were still valuable.
AFTER 3, before 3b: Service-oriented architecture was meant to help create good software design. But the idea of single-responsibility, which is very similar, was already a good design principle before SoA. And that didn’t help before, because not all developers followed it.
AFTER 1: The Ruby community is probably the most test-obsessed, especially since RSpec was released. The quality of good RSpec code is far higher than most JUnit and NUnit tests I’ve seen because RSpec is a more powerful library (in part because it sits on a more powerful language). But even still, I’m fairly sure most Ruby code is poorly tested, or not tested at all.
AFTER 2: Fred Brooks had neither RSpec nor JUnit, and he still automated tests. They certainly weren’t of the quality we can achieve today (now that object-oriented design theory has been embraced), but they were still valuable.
AFTER 3, before 3b: Service-oriented architecture was meant to help create good software design. But the idea of single-responsibility, which is very similar, was already a good design principle before SoA. And that didn’t help before, because not all developers followed it.
AFTER 1: The Ruby community is probably the most test-obsessed, especially since RSpec was released. The quality of good RSpec code is far higher than most JUnit and NUnit tests I’ve seen because RSpec is a more powerful library (in part because it sits on a more powerful language). But even still, I’m fairly sure most Ruby code is poorly tested, or not tested at all.
AFTER 2: Fred Brooks had neither RSpec nor JUnit, and he still automated tests. They certainly weren’t of the quality we can achieve today (now that object-oriented design theory has been embraced), but they were still valuable.
AFTER 3, before 3b: Service-oriented architecture was meant to help create good software design. But the idea of single-responsibility, which is very similar, was already a good design principle before SoA. And that didn’t help before, because not all developers followed it.
AFTER “Need unapparent?”: it might be that the code is old, or the app started out simple, and at the time nobody realised how essential it would be in the long run.
AFTER “Perceived lack of time?”: maybe somebody thought that writing tests would take too long. That’s fine, because time spent fixing bugs in live code is really cheap. The decision not to pay overtime was ingenious!
AFTER “Apathy?”: probably the strongest force in human nature: things are the way they are because nobody could be bothered to change them. A successful team can’t afford to be apathetic. A team that turns apathetic will stagnate.
AFTER “Oh shit, it’s too late”: The previous three attitudes have dug you into a hole.
AT END: I’m going to assume that we have no major technical or political obstacles to going agile. That means it’s up to our team to implement agile. Let’s look at some of the attitudes developers can have.
AFTER “Need unapparent?”: it might be that the code is old, or the app started out simple, and at the time nobody realised how essential it would be in the long run.
AFTER “Perceived lack of time?”: maybe somebody thought that writing tests would take too long. That’s fine, because time spent fixing bugs in live code is really cheap. The decision not to pay overtime was ingenious!
AFTER “Apathy?”: probably the strongest force in human nature: things are the way they are because nobody could be bothered to change them. A successful team can’t afford to be apathetic. A team that turns apathetic will stagnate.
AFTER “Oh shit, it’s too late”: The previous three attitudes have dug you into a hole.
AT END: I’m going to assume that we have no major technical or political obstacles to going agile. That means it’s up to our team to implement agile. Let’s look at some of the attitudes developers can have.
AFTER “Need unapparent?”: it might be that the code is old, or the app started out simple, and at the time nobody realised how essential it would be in the long run.
AFTER “Perceived lack of time?”: maybe somebody thought that writing tests would take too long. That’s fine, because time spent fixing bugs in live code is really cheap. The decision not to pay overtime was ingenious!
AFTER “Apathy?”: probably the strongest force in human nature: things are the way they are because nobody could be bothered to change them. A successful team can’t afford to be apathetic. A team that turns apathetic will stagnate.
AFTER “Oh shit, it’s too late”: The previous three attitudes have dug you into a hole.
AT END: I’m going to assume that we have no major technical or political obstacles to going agile. That means it’s up to our team to implement agile. Let’s look at some of the attitudes developers can have.
AFTER “Need unapparent?”: it might be that the code is old, or the app started out simple, and at the time nobody realised how essential it would be in the long run.
AFTER “Perceived lack of time?”: maybe somebody thought that writing tests would take too long. That’s fine, because time spent fixing bugs in live code is really cheap. The decision not to pay overtime was ingenious!
AFTER “Apathy?”: probably the strongest force in human nature: things are the way they are because nobody could be bothered to change them. A successful team can’t afford to be apathetic. A team that turns apathetic will stagnate.
AFTER “Oh shit, it’s too late”: The previous three attitudes have dug you into a hole.
AT END: I’m going to assume that we have no major technical or political obstacles to going agile. That means it’s up to our team to implement agile. Let’s look at some of the attitudes developers can have.
AFTER “Need unapparent?”: it might be that the code is old, or the app started out simple, and at the time nobody realised how essential it would be in the long run.
AFTER “Perceived lack of time?”: maybe somebody thought that writing tests would take too long. That’s fine, because time spent fixing bugs in live code is really cheap. The decision not to pay overtime was ingenious!
AFTER “Apathy?”: probably the strongest force in human nature: things are the way they are because nobody could be bothered to change them. A successful team can’t afford to be apathetic. A team that turns apathetic will stagnate.
AFTER “Oh shit, it’s too late”: The previous three attitudes have dug you into a hole.
AT END: I’m going to assume that we have no major technical or political obstacles to going agile. That means it’s up to our team to implement agile. Let’s look at some of the attitudes developers can have.
AFTER “Need unapparent?”: it might be that the code is old, or the app started out simple, and at the time nobody realised how essential it would be in the long run.
AFTER “Perceived lack of time?”: maybe somebody thought that writing tests would take too long. That’s fine, because time spent fixing bugs in live code is really cheap. The decision not to pay overtime was ingenious!
AFTER “Apathy?”: probably the strongest force in human nature: things are the way they are because nobody could be bothered to change them. A successful team can’t afford to be apathetic. A team that turns apathetic will stagnate.
AFTER “Oh shit, it’s too late”: The previous three attitudes have dug you into a hole.
AT END: I’m going to assume that we have no major technical or political obstacles to going agile. That means it’s up to our team to implement agile. Let’s look at some of the attitudes developers can have.
AFTER “Need unapparent?”: it might be that the code is old, or the app started out simple, and at the time nobody realised how essential it would be in the long run.
AFTER “Perceived lack of time?”: maybe somebody thought that writing tests would take too long. That’s fine, because time spent fixing bugs in live code is really cheap. The decision not to pay overtime was ingenious!
AFTER “Apathy?”: probably the strongest force in human nature: things are the way they are because nobody could be bothered to change them. A successful team can’t afford to be apathetic. A team that turns apathetic will stagnate.
AFTER “Oh shit, it’s too late”: The previous three attitudes have dug you into a hole.
AT END: I’m going to assume that we have no major technical or political obstacles to going agile. That means it’s up to our team to implement agile. Let’s look at some of the attitudes developers can have.
AFTER “Need unapparent?”: it might be that the code is old, or the app started out simple, and at the time nobody realised how essential it would be in the long run.
AFTER “Perceived lack of time?”: maybe somebody thought that writing tests would take too long. That’s fine, because time spent fixing bugs in live code is really cheap. The decision not to pay overtime was ingenious!
AFTER “Apathy?”: probably the strongest force in human nature: things are the way they are because nobody could be bothered to change them. A successful team can’t afford to be apathetic. A team that turns apathetic will stagnate.
AFTER “Oh shit, it’s too late”: The previous three attitudes have dug you into a hole.
AT END: I’m going to assume that we have no major technical or political obstacles to going agile. That means it’s up to our team to implement agile. Let’s look at some of the attitudes developers can have.
AFTER 1:
Please raise your hands if your team is, or your past teams have been:
• Largely enthusiastic
• Largely neutral
• Largely lazy
AT END: IS IT REALLY THAT SIMPLE?
AFTER 1:
Please raise your hands if your team is, or your past teams have been:
• Largely enthusiastic
• Largely neutral
• Largely lazy
AT END: IS IT REALLY THAT SIMPLE?
AFTER 1:
Please raise your hands if your team is, or your past teams have been:
• Largely enthusiastic
• Largely neutral
• Largely lazy
AT END: IS IT REALLY THAT SIMPLE?
AFTER 1:
Please raise your hands if your team is, or your past teams have been:
• Largely enthusiastic
• Largely neutral
• Largely lazy
AT END: IS IT REALLY THAT SIMPLE?
AFTER 1:
Please raise your hands if your team is, or your past teams have been:
• Largely enthusiastic
• Largely neutral
• Largely lazy
AT END: IS IT REALLY THAT SIMPLE?
This is a story I found on the net
"Some years ago I was looking for a job and did a lot of online résumé form filling,"
"One of those many sites had a form that took about a second to uppercase my name when I hit Tab, before putting the focus on the next field.
"That puzzled me. One second to uppercase a single-lined string?!
"The javascript was something like this:
This is a story I found on the net
"Some years ago I was looking for a job and did a lot of online résumé form filling,"
"One of those many sites had a form that took about a second to uppercase my name when I hit Tab, before putting the focus on the next field.
"That puzzled me. One second to uppercase a single-lined string?!
"The javascript was something like this:
BEFORE SHOWING CHART: On the other hand
AFTER CHART:
Daily WTF: If his own code isn’t bad enough, he’ll probably try to fix yours.
Nerd: Good news - rewrote the slowest part of you app in a day and now you only need 5% of your server farm; Bad news - he patched it live and left the code on a USB stick, at home.
N00b: Can’t fix the problems your Nerd solves in his sleep, but keeps everything running smoothly.
Rockstar developer: Rebuilt your whole app last week. Comes in Monday and presses one button that runs every acceptance test, deploys to the live servers, mails the output to the client and makes everyone a brew.
BEFORE SHOWING CHART: On the other hand
AFTER CHART:
Daily WTF: If his own code isn’t bad enough, he’ll probably try to fix yours.
Nerd: Good news - rewrote the slowest part of you app in a day and now you only need 5% of your server farm; Bad news - he patched it live and left the code on a USB stick, at home.
N00b: Can’t fix the problems your Nerd solves in his sleep, but keeps everything running smoothly.
Rockstar developer: Rebuilt your whole app last week. Comes in Monday and presses one button that runs every acceptance test, deploys to the live servers, mails the output to the client and makes everyone a brew.
BEFORE SHOWING CHART: On the other hand
AFTER CHART:
Daily WTF: If his own code isn’t bad enough, he’ll probably try to fix yours.
Nerd: Good news - rewrote the slowest part of you app in a day and now you only need 5% of your server farm; Bad news - he patched it live and left the code on a USB stick, at home.
N00b: Can’t fix the problems your Nerd solves in his sleep, but keeps everything running smoothly.
Rockstar developer: Rebuilt your whole app last week. Comes in Monday and presses one button that runs every acceptance test, deploys to the live servers, mails the output to the client and makes everyone a brew.
BEFORE SHOWING CHART: On the other hand
AFTER CHART:
Daily WTF: If his own code isn’t bad enough, he’ll probably try to fix yours.
Nerd: Good news - rewrote the slowest part of you app in a day and now you only need 5% of your server farm; Bad news - he patched it live and left the code on a USB stick, at home.
N00b: Can’t fix the problems your Nerd solves in his sleep, but keeps everything running smoothly.
Rockstar developer: Rebuilt your whole app last week. Comes in Monday and presses one button that runs every acceptance test, deploys to the live servers, mails the output to the client and makes everyone a brew.
BEFORE SHOWING CHART: On the other hand
AFTER CHART:
Daily WTF: If his own code isn’t bad enough, he’ll probably try to fix yours.
Nerd: Good news - rewrote the slowest part of you app in a day and now you only need 5% of your server farm; Bad news - he patched it live and left the code on a USB stick, at home.
N00b: Can’t fix the problems your Nerd solves in his sleep, but keeps everything running smoothly.
Rockstar developer: Rebuilt your whole app last week. Comes in Monday and presses one button that runs every acceptance test, deploys to the live servers, mails the output to the client and makes everyone a brew.
BEFORE SHOWING CHART: On the other hand
AFTER CHART:
Daily WTF: If his own code isn’t bad enough, he’ll probably try to fix yours.
Nerd: Good news - rewrote the slowest part of you app in a day and now you only need 5% of your server farm; Bad news - he patched it live and left the code on a USB stick, at home.
N00b: Can’t fix the problems your Nerd solves in his sleep, but keeps everything running smoothly.
Rockstar developer: Rebuilt your whole app last week. Comes in Monday and presses one button that runs every acceptance test, deploys to the live servers, mails the output to the client and makes everyone a brew.
BEFORE SHOWING CHART: On the other hand
AFTER CHART:
Daily WTF: If his own code isn’t bad enough, he’ll probably try to fix yours.
Nerd: Good news - rewrote the slowest part of you app in a day and now you only need 5% of your server farm; Bad news - he patched it live and left the code on a USB stick, at home.
N00b: Can’t fix the problems your Nerd solves in his sleep, but keeps everything running smoothly.
Rockstar developer: Rebuilt your whole app last week. Comes in Monday and presses one button that runs every acceptance test, deploys to the live servers, mails the output to the client and makes everyone a brew.
BEFORE SHOWING CHART: On the other hand
AFTER CHART:
Daily WTF: If his own code isn’t bad enough, he’ll probably try to fix yours.
Nerd: Good news - rewrote the slowest part of you app in a day and now you only need 5% of your server farm; Bad news - he patched it live and left the code on a USB stick, at home.
N00b: Can’t fix the problems your Nerd solves in his sleep, but keeps everything running smoothly.
Rockstar developer: Rebuilt your whole app last week. Comes in Monday and presses one button that runs every acceptance test, deploys to the live servers, mails the output to the client and makes everyone a brew.
BEFORE SHOWING CHART: On the other hand
AFTER CHART:
Daily WTF: If his own code isn’t bad enough, he’ll probably try to fix yours.
Nerd: Good news - rewrote the slowest part of you app in a day and now you only need 5% of your server farm; Bad news - he patched it live and left the code on a USB stick, at home.
N00b: Can’t fix the problems your Nerd solves in his sleep, but keeps everything running smoothly.
Rockstar developer: Rebuilt your whole app last week. Comes in Monday and presses one button that runs every acceptance test, deploys to the live servers, mails the output to the client and makes everyone a brew.
BEFORE SHOWING CHART: On the other hand
AFTER CHART:
Daily WTF: If his own code isn’t bad enough, he’ll probably try to fix yours.
Nerd: Good news - rewrote the slowest part of you app in a day and now you only need 5% of your server farm; Bad news - he patched it live and left the code on a USB stick, at home.
N00b: Can’t fix the problems your Nerd solves in his sleep, but keeps everything running smoothly.
Rockstar developer: Rebuilt your whole app last week. Comes in Monday and presses one button that runs every acceptance test, deploys to the live servers, mails the output to the client and makes everyone a brew.
ALLOW A FEW SECONDS TO ABSORB THE CATEGORISATIONS
AFTER CHART:
Most of the practices lie in the good-discipline band, not in the high-skill band.
This does NOT mean that using agile practices reduces your need for technical skill. It does NOT mean that having highly-skilled developers is not a big advantage. It DOES mean that a disciplined team of mediocre programmers has more chance of going agile than an errant bunch of über-geeks.
ALLOW A FEW SECONDS TO ABSORB THE CATEGORISATIONS
AFTER CHART:
Most of the practices lie in the good-discipline band, not in the high-skill band.
This does NOT mean that using agile practices reduces your need for technical skill. It does NOT mean that having highly-skilled developers is not a big advantage. It DOES mean that a disciplined team of mediocre programmers has more chance of going agile than an errant bunch of über-geeks.
ALLOW A FEW SECONDS TO ABSORB THE CATEGORISATIONS
AFTER CHART:
Most of the practices lie in the good-discipline band, not in the high-skill band.
This does NOT mean that using agile practices reduces your need for technical skill. It does NOT mean that having highly-skilled developers is not a big advantage. It DOES mean that a disciplined team of mediocre programmers has more chance of going agile than an errant bunch of über-geeks.
ALLOW A FEW SECONDS TO ABSORB THE CATEGORISATIONS
AFTER CHART:
Most of the practices lie in the good-discipline band, not in the high-skill band.
This does NOT mean that using agile practices reduces your need for technical skill. It does NOT mean that having highly-skilled developers is not a big advantage. It DOES mean that a disciplined team of mediocre programmers has more chance of going agile than an errant bunch of über-geeks.