u/ninetofivedev

So in the most recent rendition, I ran into someone who feels that the only way to make good money in this industry is to subject yourself to companies that have required on-call.

Now if your company has stable platforms, and you rarely if ever need to actually login after hours to deal with an issue, this isn't for you.

However, if you're one of the many software engineers, where a required part of the job is that every week, multiple week nights, you're responsible for the cadence of some delivery or the system just goes down so much that you know damn sure you're going to be dealing with some shit after hours. This post is for you.

---

So let's get down to the nitty gritty. What are you doing when you agree to working around the clock to support systems outages and failures?

1. You're supporting a dev culture where outages are considered acceptable and someone will be around to clean up the mess.
2. You're devaluing your time. You're signaling to the company that they can squeeze more out of you.
3. You're setting yourself and the company up for failure. This way of operating isn't sustainable.

I don't know why people put up with this. I don't even know how it became a normal way of operating for a significant, sizable set of companies.

Don't do it. Instead push for operationalizing the company.

So up front, I'm going to say that the purpose of this post is to tackle topics of "conventional wisdom". You know, the things we all just accept as advice every software engineering org needs to follow.

In todays rendition, we're talking about the old sage advice "You should never do a full rewrite".

Now most people are aware that there is always nuance and only a sith deals in absolutes. But for whatever reason, this expression gets thrown around as a thought-terminating cliche all the time to stop any discourse.

Now do I think you should go to your organization and propose you rewrite their entire flagship suite in Vue/Go just because? No.

But we can at least discuss rewriting software without immediately being told to pump the brakes?

Let's share an anecdote:

My organization, a DevOps / Platform engineering organization, recently was forced to adopt a piece of internal tooling.

This tooling was actually not that complicated. It is essentially a software orchestration platform that distributes 3rd party tools to various environments. The engineer who originally built it is long gone. It's been a bandaid project for contractors in recent years, where they shove in whatever they can to fix it. It operates in the last remaining on-prem infrastructure our company has. A server sitting in a closet in Zanzibar.

The infrastructure goes down all the time. The service has hard coded secrets in the frontend. The UX is absolutely terrible. User's have to jump through 18 hoops to switch environments, when it should be completely seamless.

Our team of engineers could rewrite all the functionality in a week. Give us another couple of weeks to figure out the operational complexity. This new product could be ready in a month to replace the existing product.

My manager, however, was adamant that we don't rewrite software "because you should never rewrite software".

---

So anyway, we rewrote it. Our users love the new product. Our team feels a sense of ownership over it. We understand how to make changes to it. It never crashes. It has all the observability you could want. We don't have to work around poor design decisions everytime we need to make a change.

So in 5 years, when we're all gone, and this gets inherited by a new team. You guys should probably rewrite it.

So recently I made a post about switching to 6 weeks sprints and I want to address a few points brought up.

1. Just use Kanban instead

This is actually something I think most of us are onboard with. The problem is selling to management this continuous stream of work with no clear dates for start and end.. For whatever reason gives them heartburn.

2. Misconception that sprints align with release schedules.

They don't. We release multiple times per day, sometimes we go days without a release. Point is, we release when we want to.

3. Misconception that sprints align with stakeholder feedback.

They don't. We're constantly getting feedback from stakeholders. We're also constantly prioritizing work. Just because we planned 6 weeks worth of work doesn't mean work doesn't get pulled in and it also doesn't mean deliverables that take considerably less time don't get delivered in shorter spans.

4. Sounds like you're doing agile wrong. There is something wrong with your organization.

I know. We all are. Tell us something we don't know.

5. OP, you're an idiot.

I know I am. And I know this is all stupid. But I really appreciate the constructive criticism.

---

TLDR:

I made this post to address something that has become the norm in our industry. And that's this completely "standard" way that every company under the sun has decided to manage projects. And that every single variable, down to how long the cycles run, is completely fixed.

I would venture to guess that over 85% of all companies run on a very specific methodology of "Agile", all pulling from the same Scrum boiler plate with all batteries included.

The point is to challenge these assertions. Consider longer sprints. Consider skipping ceremonies. Consider doing away with standup. Consider dropping Jira.

More-so, the key thing dropped from Agile: Individuals and interactions over processes and tools.

This, to me, is the most important thing that makes an engineering department successful. And yet, everyone is running the other way.

Every time I broach this topic, I hear the same thing. "Our well oiled machine actually does 1 week sprints... Actually, we don't do sprints at all, we're just continuously delivering and always refining the backlog!"

Good for you. Now let's talk to the other 90 people in the room.

I'll be the first to say that I don't think there is a one-size fits all approach for every team. So take this all with a grain of salt.

However, I think most teams put more effort into trying to make work seem deliverable within a 2 week timeframe, and waste more hours on grooming and refining ceremonies than they would if they had slightly longer iterations.

Between grooming, retro, planning, review... That's often at least 1-2 days of context switching.

Also I've found nobody is estimating tickets honestly. Sure, the simple stuff is easy. But anything that is slightly complex, you end up needing to break it down further and further and before you know it, you've spent more time on breaking down tickets than doing the actual work.

And don't even get me started on demos. Who decided that teams should demo what they've completed "over the last 2 weeks?"... half the time, that demo is like "so, we prepared a bunch of work for next sprints work.

I say all this just to combat the whole "shorter sprints is better"... I used to buy into that because logically it makes sense. But in practice, I've found longer sprints to actually lead to more productive teams.