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. Now where's my prize? :rolleyes:
-
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
Marc Clifton wrote:
Which one am I
Developer C, surely? :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
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'd rather be the developer who went and got beer.
This space for rent
-
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
Reader T notes that, as per the narrative, Developer C implemented Javascript client-side models. So, what does the version control log show of whom checked in what?
-
Reader T notes that, as per the narrative, Developer C implemented Javascript client-side models. So, what does the version control log show of whom checked in what?
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...
-
Marc Clifton wrote:
Which one am I
Developer C, surely? :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
:thumbsup: It seems that way. ;)
-
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
Both? All? None? To be honest, I have conversations like this with myself all the time. That is why I have my office in a safe location, away from the general public. Just saying... :doh: :-D
-
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
TRICK QUESTION! You're obviously the newbie. :)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
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
In your normal job, you're Newbie 1. When you step into the phone booth and put the cape on you become Newbie 2. :-D
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave Kreskowiak -
B. Now where's my prize? :rolleyes:
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
-
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
Source version history tell the truth. Or else you're going to have "He did it, No She did it" old days drama.
-
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
