Confirmed users
513
edits
Auto-tools/Projects/PublicES: Difference between revisions
Jump to navigation
Jump to search
→Update (January 9th, 2014)
Klahnakoski (talk | contribs) |
Klahnakoski (talk | contribs) |
||
| Line 152: | Line 152: | ||
[https://github.com/klahnakoski/Bugzilla-ETL/blob/88b8d0249cdb4aca1884bd30bed9d11977fc98a9/tests/resources/python/look_for_leaks.py Code to Look for Leaks] | [https://github.com/klahnakoski/Bugzilla-ETL/blob/88b8d0249cdb4aca1884bd30bed9d11977fc98a9/tests/resources/python/look_for_leaks.py Code to Look for Leaks] | ||
= Postmortem (February 5th 2014) = | |||
My biggest mistakes were in time estimation. Generally, I underestimated the communication and coordination overhead that is significant: | |||
* '''Security reviews take time''' - The security team was fast and responsive, but it still took time to schedule meetings, and fix the design. | |||
* '''Not much get done during holidays''' - The holidays are for family and good food, not for production deployment. Assume nothing will get done for two weeks. | |||
* '''Production deployment takes time''' - The IT group responded quickly, but it took time to setup the app, the machines and the configurations. This can be a couple of weeks at least, much of it communication delay and context switching overhead. | |||
* '''Debugging production code is hard''' - If something goes wrong in production, it can be hard to debug. | |||
** Inspecting code for possible bugs that match the problem's signature, | |||
** making a test to validate, | |||
** adding more logging in case you fixed a bug not seen in production, | |||
** running the battery of tests, and | |||
** scheduling IT to push the next version | |||
: all takes time; a couple of days at least. Compare this to development: where you can squash a bug in an hour. | |||