Software Development is very subjective

I still remember walking into a new gig a few years back, cloning the repo, and feeling an almost physical itch to hit rm -rf * and start from scratch. Nested callbacks, four different date libraries, tests commented out “just for now” — the usual archaeological site. I caught myself thinking, “Give me two weeks and I’ll fix all of this.” (Spoiler: I didn’t.)

That impulse is normal, but it’s also a trap. What looks like heresy on first glance often turns out to be the scar tissue of battles you haven’t fought yet. Over time you pick up those scars yourself and — almost without noticing — they solidify into your personal set of “best practices.”

The catch: best practices aren’t capital-T Truth, they’re context. They’re the end result of budget limits, release deadlines, team preferences, and one or two prod incidents that still cost someone sleep. I could be wrong, but I haven’t seen a one-size-fits-all process survive a change of company logo.

That doesn’t mean literally everything is subjective. Most teams I know converge on a few non-negotiables:

• Fast rollback in case tonight’s deploy goes sideways
• Automated tests that run in minutes, not hours
• A sane on-call setup that doesn’t fry people after two rotations
• CI/CD pipeline that’s boring in the best possible way

Opinionated Practices

Pick any conference hallway and you’ll overhear the age-old debates:

1. Test-Driven Development — the holy grail that’s surprisingly easy to practice until that one hairy integration test.
2. Acceptance Test-Driven Development — same spirit, but anchored in business language so Product doesn’t look at you funny.
3. Behavior-Driven Development — because writing Given-When-Then feels nicer than plain asserts (until you mis-indent a step).
4. Story- or Example-Driven flavors — remix until your linter cries.

I’ve met developers who swear anything short of TDD is malpractice, and others who treat tests as a luxury item. Who’s right? Depends on team size, release cadence, risk tolerance, and how many times production caught fire last quarter. I spent months evangelizing TDD at one job, only to later cap the coverage because our CI bills were eating the pizza budget. Lesson learned: every “always” eventually meets an “unless.” Though it didn't fully fix things, it was a step in understanding the balance needed.

Opinionated Frameworks

JavaScript land is Disneyland with fewer safety rails. React, Vue, Svelte, Solid — all arguing about the fastest, least painful way to move pixels. Server-side rendering never actually left (Rails, Phoenix, and more recently Next.js kept the lights on), it just went through an awkward teenage phase while single-page apps stole the spotlight. Now the pendulum is settling somewhere in the middle with partial SSR, islands architecture, streaming — pick your buzzword.

Two people can look at the same requirements and one reaches for Remix while the other reaches for Astro, each convinced the choice is obvious. Truth is, if both deliver sub-second Time to First Byte and a clean rollback plan, nobody outside the engineering channel will care.

TailwindCSS is another lightning rod. Critics call it glorified inline styles; fans (I’m one) love that a copy change doesn’t send them spelunking through five CSS files. It’s messy HTML, sure, but the trade-off is velocity when I’m hacking on this blog at midnight. (If you prefer BEM or CSS-in-JS, cool — as long as you ship.)

Opinionated Products

Strong opinions don’t stop at code. Take Vercel: Git push, preview URL, prod deploy — minimal knobs, maximal delight. Same story with GitHub’s “merge queue” or Linear’s hyper-focused issue tracker. These tools bake in a worldview, and enough teams share that worldview that it scales far beyond the original creators.

Microsoft Excel tries to guess what you’re doing and mostly nails it until it decides your SKU column is a date. That’s convention over configuration: 90 % joy, 10 % cursing. Maven vs. Ant in the Java universe told the same story — hide complexity behind sane defaults and offer escape hatches for the edge cases. Most people will take productivity over purity every single time.

Conventions create an opinionated product. Opinions create user delight. User delight creates successful businesses.

Opinionated Processes

Agile, Scrum, Kanban, Scrumban, 🍌ban — pick your flavor. The funny part is that even teams who claim to have ditched agile still converge on a shared backbone: continuous integration, blameless post-mortems, feature flags, small batch sizes. The labels change; the underlying physics of shipping software don’t.

I’ve heard the following four opinions on estimation in the same week:

1. Story points only, hours are evil.
2. Hours only, story points are cargo cult.
3. No estimates, just slice work until each piece fits in a day.
4. Skip agile, waterfall is predictable, deal with it.

Pick whichever makes your stakeholders less panicky and your devs less burnt out. We ended up ditching story points in one team because the debates were longer than the sprint. The sibling team two floors down swears by them. Both ship weekly, both have happy customers. Correlation between methodology and outcome? Fuzzier than consultants admit.

Rule of thumb I keep coming back to: start with a template process, then bend it until it squeals. Anything that slows you down or demotivates the team goes on the chopping block. The manifesto won’t be offended.

Opinionated Conclusion

No silver bullets. Implement any practice verbatim and you’ll probably slow down before you speed up. Tailor it, and you stand a chance.

One observation from a recent re-org: we kept the same JIRA board, same sprint length, same tech stack — productivity still jumped because the new manager killed endless status meetings and shielded engineers from random exec drive-bys. Culture > methodology, at least nine times out of ten.

So yes, opinions matter. But context — budget, people, on-call rota, legacy code screaming in the corner — matters more. Use whatever tools and rituals get you from commit to customer without trampling your values. If that happens to be two-week sprints with Tailwind and a no-estimate policy, great. If it’s monthly releases with BEM and Gantt charts, also fine. Just ship, learn, repeat.

Enjoyed the read? Join a growing community of more than 2,500 (🤯) future CTOs.

Email address

Subscribe

Free, no spam, unsubscribe at any time.

Other Newsletter Issues:

• ⛓ Implementing Atomic Habits in IT
• 🏆 Promotion-based development
• 📈 The Toxic Grind

Other Popular Articles:

• Lessons learned from becoming CTO of a small startup
• How to build remote teams properly