Hacker News Reader

Comment by deepGem | Hacker News Reader

So the key takeaway here is that the Plan, build(iterate), ship cycle works very well. Most successful teams stick to this. What is not clear to me is how an abrupt new feature with an urgent deadline fits into all this ? "We'll fit this into the next release cycle" is not an option, let's say.

So how do you fit in this new requirement ? You are already in the middle of a feature built on day 3 or 4. Devs are working on their forks and have uncommitted code. Now you have a new feature that has to be given priority, assuming there are no dependencies on the existing cycle. Do you just keep a copy of your old work, and start working on this new stuff ? Feels like a mess. Any better approaches ?

View on HN

In my experience, there is no good solution to this problem- when feature X comes along and it is decided that the ongoing work on A,B,C need to be paused because X is that important, there really is no way to quickly context switch back to A,B,C after X is finished.

The best thing you can do, in my experience, is make sure that the devs are fully bought in on why X is so much more important than A,B,C. Ideally, you want to present it to them as 'X enables us to get this contract/solve an uptime issue/whatever' and then let them decide, as a group, that maybe we continue on B while the two working on A and C instead focus on X.

> What is not clear to me is how an abrupt new feature with an urgent deadline fits into all this ? "We'll fit this into the next release cycle" is not an option, let's say.

Maybe the larger, successful tech companies avoid doing this. I believe that most of them define work at a quarterly level. So a team is unlikely to have the sudden changes in direction.

They are also unlikely to be resource-constrained, so when the odd high-priority feature emerges from the ether, they can put together a new team to tackle it.

Smaller companies need the discipline to know not to suddenly change everyone's priority, and instead, work emergent features into the current backlog at a pace appropriate for the size and scope of their teams.

> abrupt new feature with an urgent deadline

As someone who has spent most of their 7 year career at big companies that follow "plan build ship" cycles, I don't understand this post.

What abrupt new feature with urgent deadlines? Why can't this hypothetical feature wait?

Sure, for Coronavirus teams spun up and other work stopped, but that's a pretty big outlier. Most features are planned a quarter or so ahead.

> Do you just keep a copy of your old work, and start working on this new stuff

Sure why not? I don't understand how any "abrupt new feature with urgent deadlines" wouldn't require stopping what you're currently doing.

Besides, it's not like I sit on massive code changes for weeks. I submit code incrementally.

What might an "urgent new feature" consist of? Well...

The Swiss Franc is no longer pegged to the Euro, so our trading software needs to track a separate currency, and also we need to stop trading EUR/CHF forex pairs as if they were still pegged; we lost $2 million before I turned the system off this morning. The new version of IOS doesn't support the old SNMP MIB, and our customer has already installed it. The vid.me domain has been bought by a porn spammer and now we have hardcore porn ads on all our news articles. YouTube revved their AJAX and our video metadata scraper stopped working. We're being hit by an 0.1Mbps DoS because this one page takes a whole CPU second to render. The new satellite downlink site came online six months earlier than expected, so our comms software needs that multisite feature next week instead of in six months, or we're paying a shitload of rent for nothing. Modi demonetized large bills last night, so we need to stop accepting them at our ATMs. Apple told us yesterday they won't approve our update to the iOS app unless we add in-application purchases (and disable every other payment method). We signed a contract to provide security for a new film, but they're filming onsite at an Air Force Base, so we need a field in the database for which security guards are cleared to go on the base, and filming starts on Monday. Turkey just ran all their ISPs through CGNAT, which means we need to fix our NAT traversal strategy so it works through two layers of NAT, or we lose half our Turkish users. Russia is fining us $100,000 a day until we move all the data about Russian users onto our Russian server. Our popular webcam software just doesn't work with this popular new webcam. We've identified a new signal in the market that we think will give us 0.7¢ per trade, but someone else will probably exploit it within the next two weeks, and then it won't be profitable anymore. It looks like Berkshire Hathaway is going to break US$671088.64 per share this month, and we need to be able to handle that. Apple just announced that in iOS 11 the default video codec is HEVC, so unless we tell our users how to reconfigure the Camera app (and they reshoot their videos) we need to be able to handle HEVC uploads before people upgrade their phones to iOS 11. NCMEC just gave us the new version of their damn fuzzy hashing algorithm; they'll start giving us hashes in that format next month, and if we don't support it by then, we're kiddy porn purveyors. Oh, Argentina canceled daylight savings time with 11 days of warning, so all those calendar entries our users scheduled two weeks from now, they now have the wrong UTC time and need to be fixed, plus we need to roll a timezone update. We finally signed the deal with Nicki Minaj to make her a character in the game we were about to ship, but we can't slip the ship date past Black Friday or our sales will take a huge hit.

(Names and details have been changed to protect the guilty. Some events haven't happened yet.)

I have no idea what project you work on, but that sounds like 30 different teams each experiencing:

1. Rare actual urgent issues

2. Shit leadership adding last minute requirements (that no scrum or waterfall or agile whatever would help with)

3. A bunch of config changes (I worked on payments systems in the past. We had some contractors who would basically mess with config files all day as countries changed laws, etc).

4. Stuff that only quant firms care about

Regardless, you didn't address the second part of my comment: What does the fact that we'd have to stop other work have to do with anything? That'd be the case for any workflow structure.

I've worked on different projects. Yeah, I agree about stopping other work.

Make sure the features you're working on can get committed to the main branch in small, incremental units. Dark deploys/feature flags help avoid big long-lived branches that go stale and have to be kept in sync with main. So in your scenario, the devs finish off the current tasks they're working on, merge them, and move to the new work. You'll still have the pain of some feature being in an incomplete state for a while, but it's not affecting your users (who can't see it yet) and there's no half-abandoned branch slowly rotting.

hm - I'm at a startup with plan/release/build. The truth is...there are almost no abrupt new features. If something is truly a new feature - it's gonna move into planning. We've had 1 instance in my 8 months on the team with an abrupt-ish full-on feature (that I know of at least). I worked on it - there was a lot of communication with me about the scope/timeline/expectations. The feature fit into an offering we have at a beta stage - so it helped us expand something we were working on broadly anyways and was in service of winning a particularly good logo/customer. Again - this is super rare for us, but broadly - we simply communicate priority and have alignment about working on the most important things first. Generally, someone is picking up the feature that's coming off some piece of work or is working on something low stakes. Other abrupt stuff comes up - generally if it's limiting a customer's ability to utilize our product - we prioritize it.

I think you want to have a culture where abrupt new features are incredibly rare.

Version control will let you set the work aside and resume it later. You might have to burn a few cycles merging your old code up to date, but it won't be lost.

I haven't really seen a better option. Urgent work is disruptive to schedule by definition.

Well, hopefully that is not the norm, but it's not like you are limited to a single branch (fork) at a time.

Reply on news.ycombinator.com