8 ms·

"hey, this framework seems hellish, we might face some problems" The problem if you think about it is that you will tell him just that every time you see him.

"hey, this framework seems hellish, we might face some problems" The problem if you think about it is that you will tell him just that every time you see him. In other words, how do you show that you know how to make a good framework other than by beating deadlines? Beat deadlines, again and again, and then you will be granted the right the make a framework yourself. One that. among other things, actually beat deadlines.

pdpi 7y ago
I think you missed my point. "Beating the deadline" means that you deliver something that meets or exceeds expectations within the deadline. You achieve this by pulling two levers: By adjusting expectations and by getting things done. Crucially, each lever only goes so far — you (usually) can't adjust expectations to the point where you're expected to do zero work, and you can't deliver on impossibly demanding expectations solely by working extra hard. While you're absolutely right that the "keep shipping" lever is very important, the article provides an example of where you need to pull the other lever early.
- granos 7y ago
  I'm currently living this. About a year ago I inherited a large codebase that has been allowed to accumulate tech debt for the past 5 years. This was all done in the name of adding new features and keeping the business competitive. But it's time to pay down the debt. I've had MANY frank conversations with both product and engineering leadership about the current state of the world. The VP of engineering is onboard and understands the pain of what we're going through. Product is a bit harder to convince, but just as important -- probably more important. They understand that my team is having to spend 20%+ of our time just bringing the code into this decade, because I set that expectation early and reinforce it often. I argued AGAINST a from-scratch rewrite because I knew it would never be ok to stop shipping. But I have been able to convince them that slowing down now will let us move faster later.

pdpi 7y ago

I think you missed my point. "Beating the deadline" means that you deliver something that meets or exceeds expectations within the deadline. You achieve this by pulling two levers: By adjusting expectations and by getting things done. Crucially, each lever only goes so far — you (usually) can't adjust expectations to the point where you're expected to do zero work, and you can't deliver on impossibly demanding expectations solely by working extra hard. While you're absolutely right that the "keep shipping" lever is very important, the article provides an example of where you need to pull the other lever early.

granos 7y ago
I'm currently living this. About a year ago I inherited a large codebase that has been allowed to accumulate tech debt for the past 5 years. This was all done in the name of adding new features and keeping the business competitive. But it's time to pay down the debt. I've had MANY frank conversations with both product and engineering leadership about the current state of the world. The VP of engineering is onboard and understands the pain of what we're going through. Product is a bit harder to convince, but just as important -- probably more important. They understand that my team is having to spend 20%+ of our time just bringing the code into this decade, because I set that expectation early and reinforce it often. I argued AGAINST a from-scratch rewrite because I knew it would never be ok to stop shipping. But I have been able to convince them that slowing down now will let us move faster later.