4 ms·

Either you make peace with deadlines, or get your ass out of the kitchen. Seriously. I work in proposals and deadlines are not negotiable - well, unless the so

Either you make peace with deadlines, or get your ass out of the kitchen. Seriously. I work in proposals and deadlines are not negotiable - well, unless the solicitor changes the deadline, but it’s up to them. Whining about the pressure that comes with deadlines is pathetic to me, because I make my living whipping people into shape to deliver on time. I have all the accountability and none of the authority in my role - sound familiar to software engineers? The difference is that my deadline work is people management and software is working with a machine that does what you tell it to do. People don’t do what you tell them to do, at least not consistently. They try, but unless it’s a priority, it’s hit or miss. The reality is you have deadlines because your customers have deadlines and problems they need solved. If your sales team and executive leadership consistently puts you in positions where it’s difficult to succeed at what you are capable of doing, start your exit plan. Just because shit managers push their terrible deals downward doesn’t mean the system is at fault. Deadlines are healthy to keep progress and be able to move on to another new challenge. Besides, we humans are on a deadline to get all our living done. It’s as ingrained as yelling at clouds or tilting at windmills. Get busy livin’ or get busy dyin’

Tainnor 4y ago
I have never yet seen a software team, team lead, engineering manager, etc. that knew how to estimate accurately how much time a large software project will take. I have repeatedly seen people saying things like "the rewrite will only take a year", "we'll have this done in two months", etc. which turned out to be wrong by orders of magnitude. I really think that, unless we're doing very repetitive stuff, the best we can do is give rough estimates on small deliverables, i.e. stories in a sprint. If what you write is true - deadlines are important - and what I write is true - it's almost impossible to estimate how long it takes to develop complex software - then there's a mismatch that needs to be addressed somehow. I thought that this was what Scrum was designed to solve (by continuously updating estimates), but you seem to think that we need harder deadlines. If so, I'm not convinced that this is actually feasible in most cases.
maeln 4y ago
> The reality is you have deadlines because your customers have deadlines and problems they need solved. And this is actually part of the issue (and in part what the article mention). Most project, including the one of the clients don't need deadlines. I never saw a project where the deadline was not arbitrary or govern by another project deadline who was also arbitrary. I also worked in many different context, some with hard deadline, some with 0 deadline. Almost all the time, the project with hard deadline stem from the fact that the management didn't trust their engineer. They taught that without this "pressure" we would just sit on our asses and not do anything. While I certainly encounter co-worker who would gladly not do a thing and be paid, almost every engineer I worked with was happy to work and took some pride in his job. The no deadline / soft deadline project usually faired much better with a much more happy team and client. First off there was a mutual trust between management and the team "on the ground". They trusted us to do our job and we trusted them to steer the project direction and give priority. This made the job just that much more satisfying. Secondly, there was almost never a period of rush / crunch. It could happen that we had to rush a feature, but it was infrequent, short lived, and never to the extent of putting an all nighter. This means that the team had a very consistent and predictable productivity, we didn't have any burnout and people where not likely to leave in the middle of the project, so we were never short staffed out of nowhere.

Tainnor 4y ago

I have never yet seen a software team, team lead, engineering manager, etc. that knew how to estimate accurately how much time a large software project will take. I have repeatedly seen people saying things like "the rewrite will only take a year", "we'll have this done in two months", etc. which turned out to be wrong by orders of magnitude. I really think that, unless we're doing very repetitive stuff, the best we can do is give rough estimates on small deliverables, i.e. stories in a sprint. If what you write is true - deadlines are important - and what I write is true - it's almost impossible to estimate how long it takes to develop complex software - then there's a mismatch that needs to be addressed somehow. I thought that this was what Scrum was designed to solve (by continuously updating estimates), but you seem to think that we need harder deadlines. If so, I'm not convinced that this is actually feasible in most cases.

maeln 4y ago

> The reality is you have deadlines because your customers have deadlines and problems they need solved. And this is actually part of the issue (and in part what the article mention). Most project, including the one of the clients don't need deadlines. I never saw a project where the deadline was not arbitrary or govern by another project deadline who was also arbitrary. I also worked in many different context, some with hard deadline, some with 0 deadline. Almost all the time, the project with hard deadline stem from the fact that the management didn't trust their engineer. They taught that without this "pressure" we would just sit on our asses and not do anything. While I certainly encounter co-worker who would gladly not do a thing and be paid, almost every engineer I worked with was happy to work and took some pride in his job. The no deadline / soft deadline project usually faired much better with a much more happy team and client. First off there was a mutual trust between management and the team "on the ground". They trusted us to do our job and we trusted them to steer the project direction and give priority. This made the job just that much more satisfying. Secondly, there was almost never a period of rush / crunch. It could happen that we had to rush a feature, but it was infrequent, short lived, and never to the extent of putting an all nighter. This means that the team had a very consistent and predictable productivity, we didn't have any burnout and people where not likely to leave in the middle of the project, so we were never short staffed out of nowhere.