Recommandé
Contenu connexe
Tendances
Tendances (11)
Similaire à Encouraging Agile Discipline
Similaire à Encouraging Agile Discipline (20)
Plus de PatchSpace Ltd
Plus de PatchSpace Ltd (10)
Dernier
Dernier (20)
Encouraging Agile Discipline
- 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?
- 9. Some Technical Solutions Move to a more powerful language Python, Ruby, Erlang, Smalltalk
- 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”
- 14. Our Example Problem We want our HTML web app available as a web service...
- 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
- 27. Our Example Problem ctnd.
- 28. Our Example Problem ctnd. ...we were left needing to refactor our code
- 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?
- 36. A Field Guide to Post-Legacy Developers
- 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.”
- 40. A Field Guide to Post-Legacy Developers
- 41. Stick vs Carrot
- 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?
- 46. Stick vs Carrot
- 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?
- 51. Skill vs Discipline Or do you just need more nerds?
- 53. Agile Practices (not an exhaustive list)
- 54. Agile Practices (not an exhaustive list) Acceptance tests Automated deployments Unit tests Continuous integration Refactoring Simplicity / elegance Source control Collective ownership Knowledge sharing Coding standards
- 55. Agile Practices (not an exhaustive list)
- 56. Agile needs...
- 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
- 59. Agile needs...
- 61. The Underlying Solution A highly-disciplined bunch of über-geeks
- 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
Notes de l'éditeur
- 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.