4 ms·
Thinking that you're building software "for the love of the game" instead of, "to make money" is a common mistake engineers make. Don't make that mistake. You
by TameAntelope 5y ago
Thinking that you're building software "for the love of the game" instead of, "to make money" is a common mistake engineers make. Don't make that mistake.
You're responding to an example of a very not arbitrary deadline, such as what happens in markets on a fairly regular basis, upon which there is very often money to be made.
- doctor_eval 5y agoThat’s not remotely what I said. Of course getting a product done is important. Of course specific dates are sometimes important. But that doesn’t mean that due dates aren’t a lazy and inefficient management tool. In fact, I’d say it’s especially true if you have a non movable deadline. That’s when you need the absolute greatest flexibility and communication. But due dates didn’t get me where I am today - which is a pretty happy place - despite how much I tried. What worked was honest and clear communication with my teams, explicit goal setting, a clear strategy, frequent review, and trust in my team to work hard and do a great job. Every single time I’ve been forced by so-called managers to spend my time setting arbitrary dates rather than focusing on my goals and managing my teams, the project has failed spectacularly. You wouldn’t believe some of the crap I’ve seen, and I’m pretty sure I’m not alone. Software development is the reification of the halting problem. It’s quite literally impossible to know how long it will take to build a set of non trivial features without actually building them - yet here we are talking about how we should do that anyway.
- TameAntelope 5y agoDue dates are not a lazy an inefficient management tool, lazy and inefficient due dates are. Due dates are tools, they are not moralizations. Your bad experience with a tool does not mean the tool is broken, just that you used it incorrectly. You honestly seem to have a beef with the term "due dates", which is completely irrational. They can be good, they can be bad, but they are not inherently lazy or inefficient, they're a reflection of the undeniable reality that your work must produce value, and sometimes that value is time sensitive. You can strawman the concept all day, your definition of "due dates" does not reflect the reality of what they are.
- doctor_eval 5y agoYou are welcome to reflect on your own experience, but you can’t tell me mine. I’ve watched projects burn to the ground because of crappy, deadline driven management that refused to accept the realities of software development. Maybe you’ve worked for managers for whom due dates were implemented in an intelligent and respectful way, but sadly that’s not been my experience over the past 30 years.
- TameAntelope 5y agoI didn’t tell you your experience, I interpreted your experience. You don’t have a monopoly on truth just because you experienced something. You could have 100 years of experience, it would still not make your observations statistically significant, even if they were objective, which they aren’t. You said it yourself; you had crappy managers. It stands to reason anything they would have done would be bad. Due dates weren’t your problem, bad management was.
- doctor_eval 5y agoThis is a thread on an article entitled “Due dates are a lazy way to gain commitment”. We obviously don’t agree here, and that’s fine. Let’s leave it at that.
- TameAntelope 5y agoThis is a thread on a comment where I explain how the article is not accurate, it’s not just that we disagree, it’s that you’re not acting in concert with reality. I do not intend to leave anything “at that”, simply because you don’t like how the conversation is going. Someone else is free to reply.