Anyway, this post is about the single most important part of any IT (any?) project - the BUFFER. A big enough buffer should always be taken for whatever procedure you're planning - we usually take a 30% buffer.
I'm not talking only about an installation process, but also about things like giving an answer to your manager as to when you'll have a new product checked or a patch installed for the first time on a development environment. I'd prefer to get a raised eyebrow and maybe surprise my manager later to working under unneccesary pressure and making up execuses. Same goes for actual installation processes, I'd prefer announcing a long downtime and getting complaints from everyone to trying to decide in a rush if I should rollback now or hope I'm lucky enough to shrink an hour's work into fifteen minutes.
Well, that was my little - written in blood - piece of advice before I drown myself in beer, whiskey and god knows what else...
2 comments:
I just cannot see such post without disposing a complementary advice: 30% buffer for any internal resources (you, your team, hardware, software, anything) and 50%-100% buffer for any external resources (other people, other teams, etc.). The second one I call "buffer over buffer" (to take into consideration the buffer the external resource didn't take). This also allows you to manipulate the buffers at "run-time".
If one thinks this is too much to take as spare, I must say this is not an exaggeration, only experience.
obvoiusly, I've learned everything I know about buffering from you Mosh...
Post a Comment