How Software Development Really Works

I’m so tired of pretending that development is some beautiful symphony of innovation and teamwork. It’s not. It’s a chaotic, caffeine-fueled panic room full of half-baked requirements and incomplete JIRA tickets based on a roadmap that isn’t based in reality.

Software development is broken. Not slightly off. Not in need of “optimization.” It’s fundamentally, irreparably broken, and the only consistent fix companies seem to apply is layering on more broken processes in the hopes that they can make it better.

I know! Let’s have a meeting about that! Ffs.

You don’t really need a degree in computer science to thrive in software development. What you need is a stomach for bullshit.

A wardrobe full of sarcastic graphic tees to remind you not to take any of it seriously does help, and don’t worry, we’ve got plenty of those around here.

A few truths about software development

Building software is more about people than it is about code

When you first start building software, you’re very focused on the functionality that you’re trying to get running. The tech stack is important. The deployment solution is important. In the beginning, it’s about computers and what they can do.

As you move through your career, you realize more and more that the hard parts of building software isn’t really how you build it, but what you’re supposed to build. It’s this complicated set of decisions that come together to allow you actually write any code at all.

It is supposed to start with some business need and trickle through the company until each unit has some buy-in, and there is some consensus about what the right thing actually is. In moderately successful companies they somehow manage to achieve that. Unfortunately, most software-focused companies aren’t successful and the reason isn’t the code itself. It’s the people who can’t get it together.

Leadership isn’t leading

You’d think the people making the decisions would have some kind of vision of what they are trying to accomplish. They put on a good show, but no, leadership in most software companies are just whoever didn’t quit, get fired, or lucked into being early as the company expanded.

They’re not strategists, they’re just survivors. They’re in charge because they got there first.

They “steer the ship” by watching metrics they barely understand and reading LinkedIn posts about “10X Engineers” written by guys who think burning out is a badge of honor. Then they decide you need a pivot, or a reorg, or a war room session to fix the “low morale problem.”

Spoiler: the low morale problem is always caused by leadership itself.

I wish that someone would explain to me why we should work so hard if we’re just going in circles for people who haven’t got a clue.

Communication is a disaster

Let’s talk about communication. Or more specifically, the total lack of it.

Sales wants features they heard about on a golf course. Marketing wants a button to be “more emotional.” Product doesn’t know what to prioritize because the roadmap was written by a hallucinating AI and approved by a VP who just left for another job. Engineers are supposed to somehow divine what to build while everyone around them speaks in contradictory riddles like some corporate escape room puzzle.

The bigger that the company gets, the worse it is.

Every team adds a layer of abstraction. You don’t “talk to security,” you “file a request.” You don’t “ask design,” you “create a ticket in Trello.”

By the time you get approval to do anything, it’s already obsolete. Or canceled. Or both.

What teams really need is to be included in the big picture so that they can make autonomous decisions about what they think is best for them and the products that they are building. But that takes trust and we know how rare that is.

Nobody really knows what we’re building until we’ve built it

This is the greatest scam of them all. Architecture is always poorly thought out and the product spec is always half-baked. There are rarely prototypes you can use for reference. No one, anywhere in the chain, actually knows what the hell we’re building until the thing is in users’ hands and we start getting support messages like “this doesn’t work” and “did anyone actually ask people what they want?”

Because that’s how software works. You guess, you build, you cry, and you iterate. Rinse and repeat the whole sad loop while pretending it’s part of some sacred agile ritual.

That’s fine, but leadership demands “predictability” and “delivery timelines” like they’re ordering sandwiches. Instead we are building systems cobbled together from bad decisions made by the committee. Bad input, bad output.

The effect of this is that you build as fast as you can and in the end nobody is really happy with the outcome. The code is rushed and missing features, and leadership blames the development team for moving too slowly. It’s rarely solely the developer’s fault, but they are far down the pecking order, so they get to be the whipping boys (and girls). It’s not fair, but that’s life.

Agile is a cult that lost the plot

Ah yes, Agile. The magic word that gets whispered like a prayer in every boardroom. “We’re Agile now,” they say, before launching a three-month initiative to build a Roadmap that they’ll never actually release to users. Scrum masters are hired, daily standups metastasize, and post-it notes are weaponized. What was once a methodology to reduce friction has become a bureaucratic parody of itself. It seems like that’s all that humanity knows how to do: create bureaucracies.

And yet, we cling to Agile. Not because it works, but because nothing else has emerged to replace it. Agile sucks, but it’s the suck we know. So we march forward with our sprint retros and our velocity charts, pretending like we’re shipping value but the sad truth is that we’re shipping management appeasement.

You know what would be actually agile? Canceling half the meetings. Want to make a real cultural shift? Start printing “No More Meetings” on graphic tees and give those out to the poor souls who have to build all of the nonsense that sales comes up with.

Burnout is the only constant

If you make it long enough in this industry without snapping, you’re either dead inside or have found a way to emotionally detach. Most of us are just quietly unraveling, wearing our “burnt out t shirt” like armor, trying to remember what it felt like to build things for fun.

Deadlines blur into weekends, milestones are just meaningless collections of tickets that fit into two month intervals, and roadmaps don’t reflect reality.

That little edge you used to have? Gone.

Now you just nod, type, and try to survive the weekly sprint planning with your sanity semi-intact.

But hey, at least you can wear a sarcastic graphic tee while you slowly lose your will to live. That’s the real perk of working in tech. Not the stock options. Not the “unlimited PTO” that no one uses. It’s the ability to sit in a broken system, stare into the void, and say, “This is fine,” while pushing to prod on a Friday.

Final thought

Software development isn’t broken because of bad code. It’s broken because the companies writing it are a spaghetti mess of incompetence, ego, and process theater. We don’t need more tools. We need less bullshit.