3 ms·

I think you need a way to have deadlines, without that you can easily fall into over engineering or completing other unrelated tasks.

by baby 4y ago

valenterry 4y ago
I think for junior developers that might be true. Does the name connect? :)
- baby 4y ago
  no I'm not junior
- mind-blight 4y ago
  I've worked with (and been a) staff engineers who have fallen into the same trap. Over engineering is something that we need to constantly be cognizant of because it's often dependant on scope. E.g. are microservices over engineering? If you have 1 user now, and only expect 100 total users over the next 2 years, probably. If you're running AWS, definitely not. Everything in between becomes a grey area that requires thoughtful architecture to decide on the right approach, and even very experienced people will make the wrong calls
  - valenterry 4y ago
    Well, sure. I wasn't saying it never happens to non-junior engineers.
    - mind-blight 4y ago
      Respectfully, that seems to be what your parent comment says :). > I think for junior developers that might be true. That strongly implies, if not outright says, "this only inflicts junior engineers".
      - valenterry 4y ago
        I meant "if this can be generalized onto anyone at all, then at most junior developers". Was probably not the best way to express that, haha.
jraph 4y ago
Sure! I currently work at a place where there are deadlines and no sprints. It works very well for me, and for the company too apparently. There are customers who expect their stuff to be shipped and the product has a month by month roadmap. Now, over-engineering is a risk but I think I'm lazy enough to avoid it most of the time. I probably have the opposite issue sometimes. We do get things done without running for a deadline most of the time though, so it works okay without deadlines for the some non negligible part. We'd be dead if we didn't release. There isn't any investor's money to compensate.
Archelaos 4y ago
The problem is that deadlines are often too tight because the person responsible is usually not the one who suffers the most. If this is the case, the result is low code quality and bad feelings because the developers are either overworked or feel guilty. Instead, it is best to create a priority list of tasks and review it regularly.
lewisl9029 4y ago
I agree deadlines are a necessary evil to ensure we hold ourselves accountable to both customers and internal non-eng stakeholders who need to know when things will ship in order to make plans around them and collaborate with us effectively. One approach to develop a healthy culture around deadlines I've been thinking about lately: Plan the deadline around the minimal lovable product, while spec'ing out the minimal shippable product, and ensure there's enough of a delta between the two so we can have a large degree of freedom w.r.t. scope. Without this freedom to vary scope, _when_ (not if) our estimates invariably fail, our only options would be to extend the deadline (defeating the purpose of setting deadlines in the first place if we resort to this often enough), or to burn ourselves out with overtime work in an attempt to meet those deadlines (obviously results in an unhealthy/unsustainable environment, and not even guaranteed to succeed).
peoplefromibiza 4y ago
I believe this also depends on who you ask For me deadlines are simply "someone wants this and this delivered @" I work on it a couple of days and then I tell that someone if it's reasonable and if it's not reasonable, what they are gonna get instead. Most of the times deadlines are way off the mark and it also happens that they take 1/3 of the planned time, in that case instead of over engineering, I simply rest or study something new. Over engineering is a curse only if one can't stop doing it and needs an external stimuli to mark the feature as "done". Otherwise I believe most programmers know when their work is finished and can be shipped.
- deleted 4y ago
  [deleted]
hinkley 4y ago
What early Agile knew and Scrum has obliterated is that basic advice you got from your high school or college teachers who pointed out if something is important you can't leave it until the last moment. The counterargument about deadlines is always some sad sack story about shipping for the holidays or having tax software done in time for the start of the tax season. Those stories are all true, but they have fuck all to do with deadlines. Continuous Delivery means that if you need something by Friday, the conversation is about the relative risk/reward of shipping the build we're going to do on Tuesday, or the one we did last Tuesday, or one from three weeks ago. Not whether the important features will be done by CoB on Friday. Because the critical bits of the important features were finished over a month ago and now we're just making everything pretty. What happens is that "the work expands to fill the time" is not just a law that applies to developers, it also applies to management in spades. "Sure, we need this feature, but why don't you hold off on doing that while we do this other thing that feels important but only because I told someone it would happen and I'm too much of a coward to tell anyone that I was wrong about something, and I outrank you so you and your social life are going to pay for my mistakes, not me and mine."

I think you need a way to have deadlines, without that you can easily fall into over engineering or completing other unrelated tasks.

by baby 4y ago

I think you need a way to have deadlines, without that you can easily fall into over engineering or completing other unrelated tasks.

valenterry 4y ago

I think for junior developers that might be true. Does the name connect? :)

baby 4y ago
no I'm not junior
mind-blight 4y ago
I've worked with (and been a) staff engineers who have fallen into the same trap. Over engineering is something that we need to constantly be cognizant of because it's often dependant on scope. E.g. are microservices over engineering? If you have 1 user now, and only expect 100 total users over the next 2 years, probably. If you're running AWS, definitely not. Everything in between becomes a grey area that requires thoughtful architecture to decide on the right approach, and even very experienced people will make the wrong calls
- valenterry 4y ago
  Well, sure. I wasn't saying it never happens to non-junior engineers.
  - mind-blight 4y ago
    Respectfully, that seems to be what your parent comment says :). > I think for junior developers that might be true. That strongly implies, if not outright says, "this only inflicts junior engineers".
    - valenterry 4y ago
      I meant "if this can be generalized onto anyone at all, then at most junior developers". Was probably not the best way to express that, haha.

jraph 4y ago

Sure! I currently work at a place where there are deadlines and no sprints. It works very well for me, and for the company too apparently. There are customers who expect their stuff to be shipped and the product has a month by month roadmap. Now, over-engineering is a risk but I think I'm lazy enough to avoid it most of the time. I probably have the opposite issue sometimes. We do get things done without running for a deadline most of the time though, so it works okay without deadlines for the some non negligible part. We'd be dead if we didn't release. There isn't any investor's money to compensate.

Archelaos 4y ago

The problem is that deadlines are often too tight because the person responsible is usually not the one who suffers the most. If this is the case, the result is low code quality and bad feelings because the developers are either overworked or feel guilty. Instead, it is best to create a priority list of tasks and review it regularly.

lewisl9029 4y ago

I agree deadlines are a necessary evil to ensure we hold ourselves accountable to both customers and internal non-eng stakeholders who need to know when things will ship in order to make plans around them and collaborate with us effectively. One approach to develop a healthy culture around deadlines I've been thinking about lately: Plan the deadline around the minimal lovable product, while spec'ing out the minimal shippable product, and ensure there's enough of a delta between the two so we can have a large degree of freedom w.r.t. scope. Without this freedom to vary scope, _when_ (not if) our estimates invariably fail, our only options would be to extend the deadline (defeating the purpose of setting deadlines in the first place if we resort to this often enough), or to burn ourselves out with overtime work in an attempt to meet those deadlines (obviously results in an unhealthy/unsustainable environment, and not even guaranteed to succeed).

peoplefromibiza 4y ago

I believe this also depends on who you ask For me deadlines are simply "someone wants this and this delivered @" I work on it a couple of days and then I tell that someone if it's reasonable and if it's not reasonable, what they are gonna get instead. Most of the times deadlines are way off the mark and it also happens that they take 1/3 of the planned time, in that case instead of over engineering, I simply rest or study something new. Over engineering is a curse only if one can't stop doing it and needs an external stimuli to mark the feature as "done". Otherwise I believe most programmers know when their work is finished and can be shipped.

deleted 4y ago
[deleted]

hinkley 4y ago

What early Agile knew and Scrum has obliterated is that basic advice you got from your high school or college teachers who pointed out if something is important you can't leave it until the last moment. The counterargument about deadlines is always some sad sack story about shipping for the holidays or having tax software done in time for the start of the tax season. Those stories are all true, but they have fuck all to do with deadlines. Continuous Delivery means that if you need something by Friday, the conversation is about the relative risk/reward of shipping the build we're going to do on Tuesday, or the one we did last Tuesday, or one from three weeks ago. Not whether the important features will be done by CoB on Friday. Because the critical bits of the important features were finished over a month ago and now we're just making everything pretty. What happens is that "the work expands to fill the time" is not just a law that applies to developers, it also applies to management in spades. "Sure, we need this feature, but why don't you hold off on doing that while we do this other thing that feels important but only because I told someone it would happen and I'm too much of a coward to tell anyone that I was wrong about something, and I outrank you so you and your social life are going to pay for my mistakes, not me and mine."