3 ms·

Yeah, many of these are bullshit or only valid in very specific circumstances. On deadlines: sometimes there is none. Of course it still needs to be done, but

by mcv 4y ago

Yeah, many of these are bullshit or only valid in very specific circumstances. On deadlines: sometimes there is none. Of course it still needs to be done, but it needs to be done correctly, so you set your own timeline based on sustainability. Things can be high priority and still not have an actual deadline. But sometimes it really needs to be done in a week or a month because it's tied to a big promotional campaign or it needs to be presented to important stakeholders or whatever, and you need to drop everything to whip something up that does the job and tech debt be damned. But if the actual deadline is "yesterday", then it's already too late and doesn't have to be done anymore; that's not a deadline, that's fake urgency. (I realise the article is about design, not programming, so maybe tech debt is not a concern there, but I'd expect there are other quality aspects that matter.) These are completely different situations and need to be treated completely differently. Only an idiot would assume there's only one answer to the deadline question.

strogonoff 4y ago
With any work ask about external factors, not deadlines. No company operates in vacuum and there’s almost always an external factor. It may be well-defined and clearly dated (a scheduled event or launch in which your work plays part). There could be an external factor not explicitly connected to your work, even though it should be (you could help make that connection). No external factor whatsoever concerning your work is also informative: it could mean there’s not enough mutual trust, or your customer is investing into pure R&D, or it’s very low-priority, there’s a disagreement within the company, etc. It’s not the same as asking about deadlines, but the question should definitely be asked (and situation monitored for changes)—proposing a schedule/“deadlines” without awareness about external factors sounds like a bad idea. Some customers may be inclined to manage more and set specific deadlines rather than get into the external factors discussion. This spares you from some higher-level planning but doesn’t fundamentally change the ultimate responsibility of managing expectations (aiming to under-promise) regarding work scope and timeframe: fixed scope means variable timeframe, fixed timeframe only means you adjust the scope part of the equation. If expectations are unrealistic and there’s no flexibility in either direction, run.
denton-scratch 4y ago
> maybe tech debt is not a concern there Design can definitely generate technical debt. If the designer specifies that some widget has to look and behave just so, then some developer has to code a widget that meets that requirement. IME a lot of design work is purely aesthetic, and a matter of taste. That is, it's not functional; you could have used a native browser widget instead, but designer says no. And in the last shop I worked in, the designer had the whip hand, partly because the boss couldn't code, and partly because designers cost more than grunt front-end developers. So you end up with a pile of unnecessary front-end code that becomes a breeding ground for bugs and regressions. Not quite the definition of tech debt; but unnecessary code quickly turns into tech debt.

by mcv 4y ago

strogonoff 4y ago

With any work ask about external factors, not deadlines. No company operates in vacuum and there’s almost always an external factor. It may be well-defined and clearly dated (a scheduled event or launch in which your work plays part). There could be an external factor not explicitly connected to your work, even though it should be (you could help make that connection). No external factor whatsoever concerning your work is also informative: it could mean there’s not enough mutual trust, or your customer is investing into pure R&D, or it’s very low-priority, there’s a disagreement within the company, etc. It’s not the same as asking about deadlines, but the question should definitely be asked (and situation monitored for changes)—proposing a schedule/“deadlines” without awareness about external factors sounds like a bad idea. Some customers may be inclined to manage more and set specific deadlines rather than get into the external factors discussion. This spares you from some higher-level planning but doesn’t fundamentally change the ultimate responsibility of managing expectations (aiming to under-promise) regarding work scope and timeframe: fixed scope means variable timeframe, fixed timeframe only means you adjust the scope part of the equation. If expectations are unrealistic and there’s no flexibility in either direction, run.

denton-scratch 4y ago

> maybe tech debt is not a concern there Design can definitely generate technical debt. If the designer specifies that some widget has to look and behave just so, then some developer has to code a widget that meets that requirement. IME a lot of design work is purely aesthetic, and a matter of taste. That is, it's not functional; you could have used a native browser widget instead, but designer says no. And in the last shop I worked in, the designer had the whip hand, partly because the boss couldn't code, and partly because designers cost more than grunt front-end developers. So you end up with a pile of unnecessary front-end code that becomes a breeding ground for bugs and regressions. Not quite the definition of tech debt; but unnecessary code quickly turns into tech debt.