markdown guide

I'm sure there will be varying responses here. It depends on a number of factors: industry, application, corporate culture, etc. My current company really emphasizes work-life balance, so overtime is generally frowned upon. When I worked in finance, there were mandatory overtime hours to meet customer deadlines. The gaming industry is another example; you work around the clock to ensure that you meet the release dates. And if you're Elon Musk, you're going to work more than you sleep and eat combined.


So do you define release dates and then be understanding when you don't hit them? Do you not really define them at all? Does it vary?


At my current position, release dates are somewhat loose, mainly because things change a lot (read: Agile). But we have daily standups, so we understand the urgency and adjust as necessary. Again, overtime is not expected.


Today I gave an unrealistic deadline for a project I'm working on and I said to the PM, about the second part of that project something like: "the release date you asked me about is science fiction"

Nothing to see here :-D


Usually we just follow what Agile principles suggest. We reduce scope in order to meet deadlines. But if it's some sort of revamp of a certain feature or product, we'll review it in order to have mvp working as desired instead of pushing something half baked to users.


This is done less formally than I'm making it out, but here's the rough process we use:

We first characterized the project and get some rough milestones that we can reason about. We make a WAG for each milestone (a month, 6 months, whatever)

We we then go to the real drop dead deadline, the "We will be sued if it isn't done by now deadline". We work backwards from there and see how much slack we have if we start now. We figure out a start date, and a red/green zone for a couple milestones out. We meet periodically, and have a couple meetings right before and during our milestone targets.

If it looks like we are going to miss a milestone, we check the overall timeline and see if it looks like we might miss the deadline. If the deadline looks imperiled, we either chop scope, add devs, authorize overtime or investigate what it would take to push back the deadline.


We use them, but it's not all that granular, and it's more to give a general reference of the degree of complexity a given feature will entail. Amongst the team, we don't refer back to estimates or stress out about being off a bit, and that's because everyone does estimates together, as a team. So if one person is waaaay off the consensus, there's a discussion around that, and it usually reveals some piece of knowledge that makes the estimate more accurate.

Estimates are done during client meetings, which gets to the real purpose. It's to communicate scope to the client and to make sure expectations more or less match reality.


I'll start by clarifying, I work for an outsourcing company.
On my current project, we have release cycles. There's a requirements phase, a development phase and a stabilization phase.
We have a code freeze at the end of the dev phase, before stabilization, after which no new functionality should be worked on. Requirements, gathering, for the next cycle, should happen at the same time as stabilization, though it's normally continuous. Dev is self explanatory and stabilization is for bug fixing.

After stabilization we release the completed functionality to the client. They're supposed to do additional testing, normally don't, and a few other thing to prep for deploy to prod and that can sometimes take our whole cycle.

Classic DEV Post from Jun 5 '19

Dear Developers, What's Your Work/Home Setup Like?

Hey everyone, I want this to be a very casual conversation. I'm looking to set up my personal workspa...

Ben Halpern profile image
A Canadian software developer who thinks he’s funny. He/Him.