How not to do a demo, a story in timeline sequence
-
Over the last few months: Developer A has written the back-end Django models, unit tests, and third party e-commerce integration, with unit tests. Two weeks to go: Developer B has written the back-end Django REST endpoints and unit tests to interface with Developer A's code. One week to go: Developer A and B work together to fix problems found in the business logic for managing the models and third party e-commerce and update the unit tests for both models and endpoints. Four days to go: Developer C (as in CTO) implements Javascript client-side models and Backbone AJAX functions to call endpoints but no unit tests. Three days to go: Developer B finally gets to integrate the AJAX calls into a complicated e-commerce workflow and discovers problems with C's work, which get fixed. Developer B also fixes minor assumptions made when he created the workflows that are now incorrect now that he sees the actual test data coming from the back-end and e-commerce test endpoints. Two days to go: With the UI now calling the back-end, additional problems are discovered on the back a) not covered by the unit tests and b) because the e-commerce test endpoints require specific test data sets that were not communicated. Easy to fix. At this point, the UI works, and Developer B uploads some custom hardware screens to the hardware at the actual (remote) demo location... BUT: a) Developer A and B are running local VM-hosted instances of the server. b) Developer B is the only one with the rest of the hardware needed for the UI to actually test against real hardware, rather than mock data, and is actually missing one major component, the MICR (check routing/acct #) reader. c) Developer B Slacks Developer C that everything is working locally, but because the server is not yet hosted somewhere on the cloud, Developer C needs to get that set up. One day to go: Developer C Slacks Developer B that the server is now hosted on the cloud. Developer B can't log in because the account registration email links to the old server. Easy to fix. 6 hours to go: Developer C gets around to tasking some locally to test the app running against the cloud server and all the hardware. Newbie 1 plugs in hardware. PC says "Power Surge Detected on USB Port" 5 hours to go: Powered USB hub located, system fully rebooted, hardware has "moved" on its COM port assignments, no problem, it's a configuration change (auto-detection doesn't work because sending "are you there?" querie
-
Over the last few months: Developer A has written the back-end Django models, unit tests, and third party e-commerce integration, with unit tests. Two weeks to go: Developer B has written the back-end Django REST endpoints and unit tests to interface with Developer A's code. One week to go: Developer A and B work together to fix problems found in the business logic for managing the models and third party e-commerce and update the unit tests for both models and endpoints. Four days to go: Developer C (as in CTO) implements Javascript client-side models and Backbone AJAX functions to call endpoints but no unit tests. Three days to go: Developer B finally gets to integrate the AJAX calls into a complicated e-commerce workflow and discovers problems with C's work, which get fixed. Developer B also fixes minor assumptions made when he created the workflows that are now incorrect now that he sees the actual test data coming from the back-end and e-commerce test endpoints. Two days to go: With the UI now calling the back-end, additional problems are discovered on the back a) not covered by the unit tests and b) because the e-commerce test endpoints require specific test data sets that were not communicated. Easy to fix. At this point, the UI works, and Developer B uploads some custom hardware screens to the hardware at the actual (remote) demo location... BUT: a) Developer A and B are running local VM-hosted instances of the server. b) Developer B is the only one with the rest of the hardware needed for the UI to actually test against real hardware, rather than mock data, and is actually missing one major component, the MICR (check routing/acct #) reader. c) Developer B Slacks Developer C that everything is working locally, but because the server is not yet hosted somewhere on the cloud, Developer C needs to get that set up. One day to go: Developer C Slacks Developer B that the server is now hosted on the cloud. Developer B can't log in because the account registration email links to the old server. Easy to fix. 6 hours to go: Developer C gets around to tasking some locally to test the app running against the cloud server and all the hardware. Newbie 1 plugs in hardware. PC says "Power Surge Detected on USB Port" 5 hours to go: Powered USB hub located, system fully rebooted, hardware has "moved" on its COM port assignments, no problem, it's a configuration change (auto-detection doesn't work because sending "are you there?" querie
B. I have no doubt.
Michael Martin Australia "I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible." - Mr.Prakash One Fine Saturday. 24/04/2004
-
Vincent Maverick Durano wrote:
B. Now where's my prize?
Correct! No prize was stated. ;) Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
:omg: did you get fired? ;P
-
Over the last few months: Developer A has written the back-end Django models, unit tests, and third party e-commerce integration, with unit tests. Two weeks to go: Developer B has written the back-end Django REST endpoints and unit tests to interface with Developer A's code. One week to go: Developer A and B work together to fix problems found in the business logic for managing the models and third party e-commerce and update the unit tests for both models and endpoints. Four days to go: Developer C (as in CTO) implements Javascript client-side models and Backbone AJAX functions to call endpoints but no unit tests. Three days to go: Developer B finally gets to integrate the AJAX calls into a complicated e-commerce workflow and discovers problems with C's work, which get fixed. Developer B also fixes minor assumptions made when he created the workflows that are now incorrect now that he sees the actual test data coming from the back-end and e-commerce test endpoints. Two days to go: With the UI now calling the back-end, additional problems are discovered on the back a) not covered by the unit tests and b) because the e-commerce test endpoints require specific test data sets that were not communicated. Easy to fix. At this point, the UI works, and Developer B uploads some custom hardware screens to the hardware at the actual (remote) demo location... BUT: a) Developer A and B are running local VM-hosted instances of the server. b) Developer B is the only one with the rest of the hardware needed for the UI to actually test against real hardware, rather than mock data, and is actually missing one major component, the MICR (check routing/acct #) reader. c) Developer B Slacks Developer C that everything is working locally, but because the server is not yet hosted somewhere on the cloud, Developer C needs to get that set up. One day to go: Developer C Slacks Developer B that the server is now hosted on the cloud. Developer B can't log in because the account registration email links to the old server. Easy to fix. 6 hours to go: Developer C gets around to tasking some locally to test the app running against the cloud server and all the hardware. Newbie 1 plugs in hardware. PC says "Power Surge Detected on USB Port" 5 hours to go: Powered USB hub located, system fully rebooted, hardware has "moved" on its COM port assignments, no problem, it's a configuration change (auto-detection doesn't work because sending "are you there?" querie
I believe that in this psychodrama, you are "A." But, perhaps this article might help you understand C.'s behavior and "state:" [^]. commiseration is, Bill
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
-
Over the last few months: Developer A has written the back-end Django models, unit tests, and third party e-commerce integration, with unit tests. Two weeks to go: Developer B has written the back-end Django REST endpoints and unit tests to interface with Developer A's code. One week to go: Developer A and B work together to fix problems found in the business logic for managing the models and third party e-commerce and update the unit tests for both models and endpoints. Four days to go: Developer C (as in CTO) implements Javascript client-side models and Backbone AJAX functions to call endpoints but no unit tests. Three days to go: Developer B finally gets to integrate the AJAX calls into a complicated e-commerce workflow and discovers problems with C's work, which get fixed. Developer B also fixes minor assumptions made when he created the workflows that are now incorrect now that he sees the actual test data coming from the back-end and e-commerce test endpoints. Two days to go: With the UI now calling the back-end, additional problems are discovered on the back a) not covered by the unit tests and b) because the e-commerce test endpoints require specific test data sets that were not communicated. Easy to fix. At this point, the UI works, and Developer B uploads some custom hardware screens to the hardware at the actual (remote) demo location... BUT: a) Developer A and B are running local VM-hosted instances of the server. b) Developer B is the only one with the rest of the hardware needed for the UI to actually test against real hardware, rather than mock data, and is actually missing one major component, the MICR (check routing/acct #) reader. c) Developer B Slacks Developer C that everything is working locally, but because the server is not yet hosted somewhere on the cloud, Developer C needs to get that set up. One day to go: Developer C Slacks Developer B that the server is now hosted on the cloud. Developer B can't log in because the account registration email links to the old server. Easy to fix. 6 hours to go: Developer C gets around to tasking some locally to test the app running against the cloud server and all the hardware. Newbie 1 plugs in hardware. PC says "Power Surge Detected on USB Port" 5 hours to go: Powered USB hub located, system fully rebooted, hardware has "moved" on its COM port assignments, no problem, it's a configuration change (auto-detection doesn't work because sending "are you there?" querie
You know, in real life things rarely go smooth. After reading all, I'm pretty impressed with your achiements. If developer C has any value, there's a pub night waiting for you.
Wrong is evil and must be defeated. - Jeff Ello
-
Over the last few months: Developer A has written the back-end Django models, unit tests, and third party e-commerce integration, with unit tests. Two weeks to go: Developer B has written the back-end Django REST endpoints and unit tests to interface with Developer A's code. One week to go: Developer A and B work together to fix problems found in the business logic for managing the models and third party e-commerce and update the unit tests for both models and endpoints. Four days to go: Developer C (as in CTO) implements Javascript client-side models and Backbone AJAX functions to call endpoints but no unit tests. Three days to go: Developer B finally gets to integrate the AJAX calls into a complicated e-commerce workflow and discovers problems with C's work, which get fixed. Developer B also fixes minor assumptions made when he created the workflows that are now incorrect now that he sees the actual test data coming from the back-end and e-commerce test endpoints. Two days to go: With the UI now calling the back-end, additional problems are discovered on the back a) not covered by the unit tests and b) because the e-commerce test endpoints require specific test data sets that were not communicated. Easy to fix. At this point, the UI works, and Developer B uploads some custom hardware screens to the hardware at the actual (remote) demo location... BUT: a) Developer A and B are running local VM-hosted instances of the server. b) Developer B is the only one with the rest of the hardware needed for the UI to actually test against real hardware, rather than mock data, and is actually missing one major component, the MICR (check routing/acct #) reader. c) Developer B Slacks Developer C that everything is working locally, but because the server is not yet hosted somewhere on the cloud, Developer C needs to get that set up. One day to go: Developer C Slacks Developer B that the server is now hosted on the cloud. Developer B can't log in because the account registration email links to the old server. Easy to fix. 6 hours to go: Developer C gets around to tasking some locally to test the app running against the cloud server and all the hardware. Newbie 1 plugs in hardware. PC says "Power Surge Detected on USB Port" 5 hours to go: Powered USB hub located, system fully rebooted, hardware has "moved" on its COM port assignments, no problem, it's a configuration change (auto-detection doesn't work because sending "are you there?" querie
Developer B, without a doubt. Marc, I do believe you have taken Christian Graus' place as the CP-guy-under-the-bus.
Software Zen:
delete this; -
I believe that in this psychodrama, you are "A." But, perhaps this article might help you understand C.'s behavior and "state:" [^]. commiseration is, Bill
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
BillWoodruff wrote:
I believe that in this psychodrama, you are "A."
Nope. B. I would never tell someone "it's your code, it's your bug." And I have temper, hence the elephant comment. ;) Amusing article on C! Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
Over the last few months: Developer A has written the back-end Django models, unit tests, and third party e-commerce integration, with unit tests. Two weeks to go: Developer B has written the back-end Django REST endpoints and unit tests to interface with Developer A's code. One week to go: Developer A and B work together to fix problems found in the business logic for managing the models and third party e-commerce and update the unit tests for both models and endpoints. Four days to go: Developer C (as in CTO) implements Javascript client-side models and Backbone AJAX functions to call endpoints but no unit tests. Three days to go: Developer B finally gets to integrate the AJAX calls into a complicated e-commerce workflow and discovers problems with C's work, which get fixed. Developer B also fixes minor assumptions made when he created the workflows that are now incorrect now that he sees the actual test data coming from the back-end and e-commerce test endpoints. Two days to go: With the UI now calling the back-end, additional problems are discovered on the back a) not covered by the unit tests and b) because the e-commerce test endpoints require specific test data sets that were not communicated. Easy to fix. At this point, the UI works, and Developer B uploads some custom hardware screens to the hardware at the actual (remote) demo location... BUT: a) Developer A and B are running local VM-hosted instances of the server. b) Developer B is the only one with the rest of the hardware needed for the UI to actually test against real hardware, rather than mock data, and is actually missing one major component, the MICR (check routing/acct #) reader. c) Developer B Slacks Developer C that everything is working locally, but because the server is not yet hosted somewhere on the cloud, Developer C needs to get that set up. One day to go: Developer C Slacks Developer B that the server is now hosted on the cloud. Developer B can't log in because the account registration email links to the old server. Easy to fix. 6 hours to go: Developer C gets around to tasking some locally to test the app running against the cloud server and all the hardware. Newbie 1 plugs in hardware. PC says "Power Surge Detected on USB Port" 5 hours to go: Powered USB hub located, system fully rebooted, hardware has "moved" on its COM port assignments, no problem, it's a configuration change (auto-detection doesn't work because sending "are you there?" querie
B
#SupportHeForShe Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
-
BillWoodruff wrote:
I believe that in this psychodrama, you are "A."
Nope. B. I would never tell someone "it's your code, it's your bug." And I have temper, hence the elephant comment. ;) Amusing article on C! Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Interesting, Marc; I couldn't imagine you telling a "newbie:" "... elephant off, and that if he doesn't have something useful to contribute, to please 'shut up.' " When I read this: "Newbie 2 bitches to Developer B: 'Developer C just said that he did not write any of that js, apparently this is your js ... if its a problem with js, its your js' " That says to me that it is C who uses the phrase, as reported to B by Newbie 2. There's virtually no comments by A, and I assumed you did back-end, and, further assumed, that if anyone would get thrown under the bus by C, it would be you ... based on your previous blow-by-blows.
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
-
Tim Carmichael wrote:
So, what does the version control log show of whom checked in what?
Let's all just concentrate on getting the job finished first, and then apportion blame when we have time to be really, really nasty about it at great length.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
Over the last few months: Developer A has written the back-end Django models, unit tests, and third party e-commerce integration, with unit tests. Two weeks to go: Developer B has written the back-end Django REST endpoints and unit tests to interface with Developer A's code. One week to go: Developer A and B work together to fix problems found in the business logic for managing the models and third party e-commerce and update the unit tests for both models and endpoints. Four days to go: Developer C (as in CTO) implements Javascript client-side models and Backbone AJAX functions to call endpoints but no unit tests. Three days to go: Developer B finally gets to integrate the AJAX calls into a complicated e-commerce workflow and discovers problems with C's work, which get fixed. Developer B also fixes minor assumptions made when he created the workflows that are now incorrect now that he sees the actual test data coming from the back-end and e-commerce test endpoints. Two days to go: With the UI now calling the back-end, additional problems are discovered on the back a) not covered by the unit tests and b) because the e-commerce test endpoints require specific test data sets that were not communicated. Easy to fix. At this point, the UI works, and Developer B uploads some custom hardware screens to the hardware at the actual (remote) demo location... BUT: a) Developer A and B are running local VM-hosted instances of the server. b) Developer B is the only one with the rest of the hardware needed for the UI to actually test against real hardware, rather than mock data, and is actually missing one major component, the MICR (check routing/acct #) reader. c) Developer B Slacks Developer C that everything is working locally, but because the server is not yet hosted somewhere on the cloud, Developer C needs to get that set up. One day to go: Developer C Slacks Developer B that the server is now hosted on the cloud. Developer B can't log in because the account registration email links to the old server. Easy to fix. 6 hours to go: Developer C gets around to tasking some locally to test the app running against the cloud server and all the hardware. Newbie 1 plugs in hardware. PC says "Power Surge Detected on USB Port" 5 hours to go: Powered USB hub located, system fully rebooted, hardware has "moved" on its COM port assignments, no problem, it's a configuration change (auto-detection doesn't work because sending "are you there?" querie
