> No one should be allowed to avoid the issue by the old formula, “I can’t give a promise because it depends upon so many uncertain factors.”
STRONGLY disagree.
I've worked on projects where:
- Getting a stable build might take four hours (minimum) to several weeks (depending on churn);
- Processes for adding components were undocumented magic, and very nearly undebuggable;
- Components might take days or weeks to propagate, once you were finally able to make changes to them.
Debugging is a similar story. Some bugs are nasty, horrible, complex things that take a lot of time. I've seen showstopper-class kernel level bugs take months to find. The nature of interactions at the hardware / software interface is unbelievably complicated.
So what does a "senior" engineer do?
- Communicate the nature of the problems in a non-whiny way.
- Give responsible estimates. "Three days or a month" is honest, if you say why.
- DON'T promise results that you can't actually deliver.
- Be prepared to have features cut, and to have conversations about things that you consider less than optimal ("sucky") for the customer.
Naturally, your senior engineer is also trying to improve the sucky situation the whole team finds itself in (with better tools, build processes, whatever), but some situations are intractable.