Comment by mikekchar | Hacker News Reader

Comment by mikekchar | Hacker News Reader

There are 2 normal ways to do things: work until you achieve the functionality you want and release it when that happens or work until an arbitrary date and release whatever you have at that point. Surprisingly, as a developer I always prefer the latter. As a coworker of mine if fond of saying, the time you know the most about the project is when you are finished. The time when you know the least is when you are starting.

By choosing to release "whatever we can do" at a certain time it encourages you to make difficult prioritisation decisions as the "deadline" approaches. Are we really OK with releasing with just this functionality? Maybe we should axe X and replace it with Y since we don't look like we are going to get both. Maybe Z is an even better compromise that we didn't realise was an option at the beginning of the project.

If you try to hit functionality, it allows the organisation to avoid rethinking its planning decisions. We aren't releasing until the ideas we had 6 months ago are all implemented exactly as we envisioned it back then. By the way, why is it taking so long?

Of course trying to hit both at the same time is just a recipe for disaster.

I agree, but I think there's a still better way. If the "deadline" is too early, you risk unnecessary failure. If the "deadline" is too late, you end up developing to an arbitrary feature list again.

I'm a big fan of going hard for a minimum viable product. The notion is that you find the absolute minimum that will let you close the primary feedback loop: seeing what people do in the real world. Maybe it's only one set of users, like early adopters in a particular market segment. Maybe we leave out a lot of "real product" things, like help and docs, making up for it with handholding. But we ruthlessly cut scope until we have something in users' hands.

At that point, I think it's possible to shift from an internal focus (e.g., an arbitrary date or a made-up list of features) to an external focus, where we look at who's using it, who we're delivering value for, how we can sell it, and what the next most valuable improvements are. W release weekly or more often, driven by hypotheses and data. For me, that's when the real magic happens. Then we can focus less on internal politics, and more on what we're learning from the real world. And there's always something to learn.

Exactly this, and what a lot of less senior developers don’t understand is that the fixed timeline is actually a defensive mechanism for the development team. If the date is fixed the functionality has to be variable and the best people to assess what fits or not is the development team who thus can be in control of their own planning.

No, for many managers the fact that the deadline is fixed means they can death march you for all the functionality they decide needs to be complete at that date.

The idea that adding additional process to manage your managers is laughable at best.

Manager can't hold your fingers and force you to type code. Agile's short sprints mean that managers learn in 4 weeks instead 16 that death marches don't work. Managers can be managed as much or little as reports are.

I know currently of several companies being managed into the dirt by people who dont learn no matter the scheduling mechanism or level of machiavellian maneuvering by their employees.

So no, you cant manage your boss, you can inform them, maneuver them, help them, cajole them; but at the end of the day you cant get them to change their behavior if they truly don't want to(and they can just fire you for being too annoying.)

In the current environment one can get away with a lot of push-back because managers with any fraction of a clue know if they piss you off too much you'll be giving them your notice, new job in hand, in a few weeks, if not days. That won't last—which is why if we're going to organize for better leverage against abuse in bad times, now'd be the time to do it, but I guess enough people've been convinced unions will impoverish them that we're not gonna, maybe next boom, see y'all then—but for now it's pretty nice.

> There are 2 normal ways to do things: work until you achieve the functionality you want and release it when that happens or work until an arbitrary date and release whatever you have at that point.

Wise words. Herb Sutter wrote a long blog post on exactly this, with regard to how C++ language versions release on a schedule, whether or not your favourite feature is ready yet.

https://herbsutter.com/2019/07/13/draft-faq-why-does-the-c-s...

The problem with little upfront planning is the team might spend too much time on certain features in the beginning and get crunches at the end to deliver an MVP experience at the agreed upon deadline. By signaling early that a deadline may be missed, there is an opportunity to make course corrections in the spec or shift folks from other projects to deliver a higher quality experience at the agreed upon deadline.

Clear-as-possible descriptions of uncertainty are the only real hedges against this, because they create the opportunity for directed experiments.

If the organization is mature enough to rethink the project scope when approaching deadlines, couldn’t it also take the first approach and rethink the delivery as features are getting worked on ?

There is effectively organizations that look at ongoing R&D subjects and say “this is almost shippable, we’d just need X. Let’s just priorize X and ship it”

Depends. Some can, but my industry cannot. I write seasonal software. A release in May won't be used until the next March, so there is no point in any release that isn't in January/February. (A march release will be skipped because they are scared of bugs, February releases gives customers time to upgrade and test before then critical time when they need it)

Thus for me it makes the deadline or it doesn't. Early isn't a benefit, late is a problem.

But you don't quit in April, you are working on the next February release. So you don't have a deadline, you have a checkpoint.

Sort of. I go on the next project, but we let some contractors go at the end of the project. Ultimately I'm putting a computer on machines that were common in 1890: there isn't much innovation to add that previous engineers couldn't think of. We can get larger than past generations, a little more accurate and reliable: but in the end the designs from 1890 weren't that much worse that today's.

Reply on news.ycombinator.com