4 ms·

> Recognising this ”reality”, and building your software development processes around it, is _engineering_. A pillar of good engineering is understanding that

by IMTDb 5y ago

> Recognising this ”reality”, and building your software development processes around it, is _engineering_. A pillar of good engineering is understanding that the when and the how much matter often as much as the what and are fundamental inputs driving the how. Due dates are a key answer to one of the component, they also have the benefit of being crystal clear and unambiguous, something engineers should strive for. Software development is like gas: it will take precisely the space you give it (and probably leak a bit). Due dates are the simplest and most efficient way of constraining that space. The issue arise when they are unrealistic, or arbitrarily set, without being negotiated. But you absolutely need them. "A goal without a date is just a dream." - Milton H. Erickson

doctor_eval 5y ago
You can’t pin down the when, how much, what and how all at the same time. Like the old adage says, “better, faster, cheaper” - choose two. Most teams have a fixed set of resources, and therefore a fixed cost. So, if you set a deadline then you’re setting quality as the variable. Low quality software generally fails to achieve the business goals either because it results in poor customer satisfaction or low reliability, leading to high OPEX. Like most things in life, there is a trade off to be made, and setting some magical “due date” is just a lazy way to manage a team. In my experience it’s a blunt instrument used by people who don’t know how to build good software. > "A goal without a date is just a dream." - Milton H. Erickson Milton Hyland Erickson was an American psychiatrist and psychologist specializing in medical hypnosis and family therapy. [0]. Clearly a guy who knew all about dreams, but nothing about software engineering. [0] https://en.wikipedia.org/wiki/Milton_H._Erickson https://en.wikipedia.org/wiki/Milton_H._Erickson
- IMTDb 5y ago
  > You can’t pin down the when, how much, what and how all at the same time Precisely. And my point is that you should set the when and how much as soon as possible. Then negotiate the what. Then, based on all these information, decide on the how. Usually tho, people love to start on the what, immediately think about the how, and give pointer on the how much. Inevitably, the when question comes, and can significantly alter the other points. Everyone hates to have their "perfect plan" questioned by an external deadline, and management is resented for it. As engineers, the how is where we have the most control and knowledge, so this should serve as an adjustment variable, not the other way around. The Milton quote applies really well to software engineering, we have all known tons of projects that linger in the "80% done" state for extended periods of time, it's a staple of engineering. A significant portion of project management is psychology. Some of the best PM I have had had almost 0 technical background.
  - doctor_eval 5y ago
    I guess we really just differ in that I don't think the "when" is necessarily the most important thing. It's just as much a part of the negotiation as the what, how etc; it's just one dimension of many. It's often, but not always, the key driver. But you don't seem to be the kind of lazy manager that this article talks about. If you're OK to say that the date is the most important thing, and we understand that this might mean we have to sacrifice features or quality or whatever, then that's perfectly reasonable. It's an explicit trade off that you can communicate clearly to your team. But all too often, we're told that we need to have N features in T time, and when it's delivered half assed and full of bugs, well that's our fault. And I think that's the essence of lazy management, because it's really just trying achieve success through the force of will, which IME doesn't work very often.

by IMTDb 5y ago

doctor_eval 5y ago

You can’t pin down the when, how much, what and how all at the same time. Like the old adage says, “better, faster, cheaper” - choose two. Most teams have a fixed set of resources, and therefore a fixed cost. So, if you set a deadline then you’re setting quality as the variable. Low quality software generally fails to achieve the business goals either because it results in poor customer satisfaction or low reliability, leading to high OPEX. Like most things in life, there is a trade off to be made, and setting some magical “due date” is just a lazy way to manage a team. In my experience it’s a blunt instrument used by people who don’t know how to build good software. > "A goal without a date is just a dream." - Milton H. Erickson Milton Hyland Erickson was an American psychiatrist and psychologist specializing in medical hypnosis and family therapy. [0]. Clearly a guy who knew all about dreams, but nothing about software engineering. [0] https://en.wikipedia.org/wiki/Milton_H._Erickson https://en.wikipedia.org/wiki/Milton_H._Erickson

IMTDb 5y ago
> You can’t pin down the when, how much, what and how all at the same time Precisely. And my point is that you should set the when and how much as soon as possible. Then negotiate the what. Then, based on all these information, decide on the how. Usually tho, people love to start on the what, immediately think about the how, and give pointer on the how much. Inevitably, the when question comes, and can significantly alter the other points. Everyone hates to have their "perfect plan" questioned by an external deadline, and management is resented for it. As engineers, the how is where we have the most control and knowledge, so this should serve as an adjustment variable, not the other way around. The Milton quote applies really well to software engineering, we have all known tons of projects that linger in the "80% done" state for extended periods of time, it's a staple of engineering. A significant portion of project management is psychology. Some of the best PM I have had had almost 0 technical background.
- doctor_eval 5y ago
  I guess we really just differ in that I don't think the "when" is necessarily the most important thing. It's just as much a part of the negotiation as the what, how etc; it's just one dimension of many. It's often, but not always, the key driver. But you don't seem to be the kind of lazy manager that this article talks about. If you're OK to say that the date is the most important thing, and we understand that this might mean we have to sacrifice features or quality or whatever, then that's perfectly reasonable. It's an explicit trade off that you can communicate clearly to your team. But all too often, we're told that we need to have N features in T time, and when it's delivered half assed and full of bugs, well that's our fault. And I think that's the essence of lazy management, because it's really just trying achieve success through the force of will, which IME doesn't work very often.