Making Nests: An Office Day in Aberdeen

There are some days where nothing particularly remarkable happens.

No major achievements.

No disasters.

No life-changing revelations.

Just a day.

And perhaps that's enough.

The Journey In

Today was an office day.

I caught the bus just after seven and headed into Aberdeen.

The journey takes me through the countryside, and unlike driving, I don't have to concentrate on the road. I can simply sit and watch the world go by.

Fields.

Trees.

Villages waking up.

People waiting at bus stops.

It gives me time to prepare for the day ahead.

Not by checking emails or scrolling through my phone.

Just by looking out of the window and letting my thoughts settle.

Looking Up

When I arrived in the city, I walked from Union Street to Marischal College.

I wasn't in a rush.

One thing I've noticed is that if you slow down and look up, Aberdeen reveals itself differently.

Most people walk with their eyes fixed on the pavement or their phones.

But there is so much architecture above eye level.

Stone carvings.

Windows.

Details that have stood there for over a hundred years.

The city has a character that is easy to miss when you're moving too fast.

The First Nest

Before heading to a desk, I stopped in the canteen.

Coffee.

A table.

A view of people moving through the building.

Some I knew.

Some I didn't.

I still said hello.

I think there's value in that.

A simple acknowledgement that we're all sharing the same space for a while.

Then I made my first nest of the day.

Two computers.

Headphones.

Notebook.

Pens.

A drink.

Everything in its place. Nothing special. Just enough familiarity to make an unfamiliar space feel like my own.

My work kit spread around me in a way that felt familiar.

I've realised I do this everywhere.

At home.

In the office.

In a café.

On a train.

I create a small space that feels comfortable and familiar before getting started.

Doing My Bit

The day itself was largely made up of Teams calls.

Conversations.

Questions.

Updates.

Problem solving.

The sort of work that rarely makes exciting stories but quietly keeps things moving.

I contributed where I could.

Shared opinions.

Answered questions.

Helped move things forward.

Nothing spectacular.

Just doing my bit.

At some point my Windows laptop battery reminded me that three years isn't quite as young as it used to be, so I packed everything up and moved.

The Second Nest

I found an empty cubicle tucked away on its own.

Quiet.

Out of the way.

Perfect.

So I built another nest.

Laptop.

Headphones.

Notebook.

Water bottle.

Back to work.

More calls.

More discussions.

More opportunities to contribute.

The interesting thing was that it all worked perfectly well.

I wasn't at my usual desk.

I didn't have my normal setup.

Yet somehow the work still happened.

The conversations still happened.

The day still worked.

Perhaps we are more adaptable than we give ourselves credit for.

The Pace We Choose

One thing I've been thinking about recently is how much pressure we create for ourselves.

Everything feels urgent.

Everything feels important.

Every notification demands attention.

But when I look back on today, none of the valuable moments came from rushing.

The valuable moments came from slowing down.

Looking out of the bus window.

Looking up at buildings.

Saying hello to people.

Taking time to set myself up properly.

Listening carefully.

Helping where I could.

The world seems determined to make us move faster.

Sometimes the best response is simply to choose your own pace.

Beer, Friends and Going Home

It's early evening now.

I'm sitting with a pint waiting for a friend to arrive.

Soon there will be conversation, a couple more beers, and then the bus home.

As I sit here writing this, I find myself asking a simple question.

Did I help today?

I think I did.

Did I make things slightly better?

I think so.

Did I encourage people?

Probably.

Did I bring some enthusiasm?

I hope so.

And honestly, that feels like enough.

Not every day needs to change the world.

Sometimes a good day is simply showing up, doing your bit, being kind to people, and enjoying the journey.

Today was one of those days.

And I like days like that.

Days in the office also remind me how different the experience is from remote working. I've written before about some of the unexpected lessons from working from home.

The idea of simply showing up, helping people, and doing useful work connects closely to my earlier reflections on meaningful work.

Looking back, this post isn't really about buses, offices, or Teams calls.

It's about finding a pace that works, helping where you can, and recognising that not every day needs to be extraordinary to be worthwhile.

If you enjoy reflections on work, technology, creativity, and the systems that shape our lives, you can explore more of my writing here.

The Great Flap: Unrealistic Deadlines in Software Development

Unrealistic deadlines in software development are one of the most common causes of stress, burnout, and failed software projects.

There comes a point in every project when the calm façade begins to crack.

People start talking a bit faster, typing a bit louder, and suddenly there’s an air of impending doom.

That’s right — the Great Flap has begun.

You can almost feel it in the corridors (or Teams calls).

The sense that if this particular bit of software isn’t live by Friday afternoon, civilisation as we know it will collapse. Cats and dogs living together. Total anarchy.

The myth of deadlines in software development

It usually starts with someone saying, “We’ve got a tight deadline, but I’m sure we can make it if we all pull together.”

Ah yes. That old chestnut.

Because nothing motivates quite like the unspoken threat of collective disappointment.

The deadline, of course, was never realistic. It was set optimistically in a meeting some weeks ago by people who do not, and never will, understand what “refactoring a data model” actually means.

But now here we are, marching valiantly towards an impossible finish line, as if sheer willpower and a few motivational emails will somehow defy the laws of time and logic.

Why software development takes time (and can’t be rushed)

Here’s the thing. Software isn’t an emergency service. You can’t just switch on the sirens, shout “let’s go, team!” and expect miracles.

It’s an art form — slow, deliberate, and occasionally maddening.
It requires thought, patience, and the ability to spend three hours wondering why something doesn’t work, only to realise you missed a semicolon.

You don’t become an expert overnight. You don’t take a thousand vague requirements, a handful of “blue sky thinking” ideas, and end up with the digital equivalent of the Holy Grail.

But try explaining that to someone who thinks “agile” means “done by next week”.

How project spreadsheets create false deadlines

No Great Flap is complete without the sacred text: the project spreadsheet.

Usually named something like:
ProjectPlan_FINAL_NEW_latest2(1)_USETHISVERSION.xlsx

Inside, you’ll find a riot of colour — red cells, amber cells, inexplicable greens — and formulas that worked perfectly on some long-forgotten project but now throw up #VALUE! errors.

There’ll be a tab called Risks with two items on it (“Christmas holidays” and “staff sickness”), and another called Lessons Learned which, naturally, is empty.

Why teams push for unrealistic deadlines

Then comes the pushing.
“Just one more sprint.”
“Just one last push.”
“We’re nearly there!”

We are not nearly there.

We are, in fact, somewhere between despair and déjà vu — that familiar territory where everyone’s pretending this time will be different.

Some developers push back. Others smile politely and get on with doing things properly, at their own quiet pace. Because we’ve all learned that panic doesn’t make software appear any faster. It just produces tired developers and broken code.

Why experienced developers ignore unrealistic deadlines

So, what do you do? You nod. You smile. You attend the daily stand-up, listen to the pep talks, and then quietly go back to your desk (or kitchen table) to do things the right way.

You focus on quality, on craft, on not being the person who signed off a bug-ridden disaster because someone shouted “urgent” enough times.

And when the inevitable happens — when the deadline slips, the panic subsides, and everyone suddenly decides it’s fine after all — you just sip your tea, raise an eyebrow, and carry on.

Because unrealistic deadlines don’t speed up software development — they just make bad outcomes more likely.

Because you’ve seen it all before.

You’ll see it all again.

And deep down, you know that calm competence beats frantic enthusiasm every single time.

If deadlines in your project feel more like pressure than a plan, you’re not alone.

I spend a lot of time helping teams cut through unrealistic expectations and get back to something that actually works.

If things feel rushed or out of control, take a look at my TechFix service.

After the Shipwreck: Rebuilding Failed Software Projects the Right Way

Failed software projects are more common than most organisations admit — and software project failure often leads to the same patterns of rebuilding and recovery.

So, the ship sank. No surprise, really. The champagne launch, the motivational speeches, the “game-changing” software modules—all gone, now resting comfortably on the seabed alongside Titanic’s reputation and countless other “innovations.”

But here we are, floating in our life rafts. The water has calmed, the sun is out, and—believe it or not—we’re still alive. Damp, tired, and a little sunburned, yes, but alive. And here’s the best part: we still have our paddles, our wits, and our older, sturdier systems that didn’t go down with the SS Overpromise.

Regrouping after a failed software project

When the storm passed, something unexpected happened: silence. Gone are the shouting salespeople with their laminated buzzwords. Gone are the consultants who insisted that a “strategic synergy alignment roadmap” would keep the vessel afloat. They’ve drifted away on their branded floaties, perhaps already selling tickets for the launch of their next doomed cruise liner.

And in their absence, the people who actually know how the engine room works—us—are finally steering. It’s not glamorous. There are no drone flyovers, no ribbon-cutting ceremonies, no LinkedIn announcements about “disruption.” But we know the waters, we know what our passengers (customers) actually need, and we know how to build a boat that won’t spring a leak the minute someone leans on it.

We’ve salvaged what we can from the wreck: some planks of half-useful code, a lifebuoy of data, and a crate of “best practice” manuals that are mostly good for keeping a campfire going. The rest we leave to the fish.

Lessons learned from failed IT projects

The voyage wasn’t a total waste—it was expensive, chaotic, and occasionally terrifying, yes, but also educational. From the soggy wreckage, the following truths bobbed to the surface:

• Listening to the engine room matters. When the warning lights flash red, it’s not “negativity,” it’s experience. Ignoring those signals is how you end up baling water with a PowerPoint deck.

• Bigger isn’t always better. Sometimes a raft, built by steady hands, will get you further than a flashy yacht designed by a marketing department.

• Survival builds resilience. Having endured the car crash of the SS Overpromise, we now know what not to do next time. That’s valuable—even if it was the most expensive lesson in history.

• Innovation ≠ Reinvention. The wheel works. You don’t need to spend millions on a new “conceptual rolling solution” when you already have a perfectly round one.

Rebuilding software systems the right way

From here on, things will look different. We’ll stitch together the old sails with pieces of the new. We’ll take time to test our knots, to listen to the hum of the engines, to check that the hull actually holds water. We may not be invited to black-tie award dinners for “Best Use of Blue Sky Thinking 2025.” We may not trend on tech blogs for our “visionary ecosystem.” But what we will have is working systems. Solid, practical, reliable. And our customers—who don’t care about buzzwords—will quietly thank us for it. The truth is, glamour doesn’t keep ships afloat. Real work does. Careful planning does. Experience does.

In reality, this is what recovering from a failed software project often looks like.

How teams move forward after project failure

The sun is out now. We can see the horizon, and it’s ours to sail toward. Not on a gilded cruise liner designed for headlines, but on a sturdy vessel of our own making. Built by the engineers. Guided by people who know the sea.

The storm may have sunk the SS Overpromise, but it didn’t sink us. We’re still here, still rowing, and this time—we’re steering.

Disclaimer:

This story is entirely fictional and imaginary. Any resemblance to real ships, software projects, organisations, or individuals—living or sunken—is purely coincidental.

If deadlines in your project feel more like pressure than a plan, you’re not alone.

I spend a lot of time helping teams cut through unrealistic expectations and get back to something that actually works.

If things feel rushed or out of control, take a look at my TechFix service.

Surviving Failing Software Projects: Signs, Survival, and Sanity

There are failing projects… and then there are “brace for impact, grab your life jacket — the captain thinks the iceberg is optional” projects.

Failing software projects often follow the same pattern — warning signs appear early, but are ignored until it’s too late.

You know the type.
Costs spiral. Deadlines multiply like rabbits. “Must-have features” get quietly pushed into a mythical “phase two” that never arrives. And yet, from the top deck, the message is always the same:

“Everything’s fine, full steam ahead!”

Meanwhile, you’re below deck, scooping out water with a teaspoon, wondering if your LinkedIn profile needs a refresh.

Warning Signs of a Failing Software Project

In reality, these are the warning signs most people see in failing software or IT projects.

How do you know the ship is sinking? Easy. Just look for these universal warning signs:

• PowerPoints get shinier as the project gets shakier.

• Leadership swaps out “working product” with phrases like “strategic alignment” and “future potential.”

• The project plan is now 400 slides long, and still no one knows what you’re actually building.

• Team morale is measured in how much sarcasm can be packed into the daily stand-up.

If you’ve ever thought, “Am I the only one who sees the flames pouring out of the engine room?” — congratulations, you’re on a doomed project.

How to Survive a Failing Project Day-to-Day

So what do you do when you’re strapped to the deck of a slow-motion car crash?

1. Document Everything
   Not just emails. Etch it into stone tablets if you have to. You’ll want receipts when someone inevitably asks, “Why didn’t anyone warn us?”

2. Perfect Your Poker Face
   Practice nodding sagely in meetings while internally screaming. Bonus points for jotting nonsense in your notebook — no one will question “synergy roadmap,” but it makes a great doodle.

3. Redefine Your Goals
   Forget delivering the impossible. Instead, focus on achievable wins:

   • Did you stop yourself from flipping a table? ✅

   • Did you keep the junior developer from quitting today? ✅

   • Did you find a new meme for the team chat that perfectly sums up the chaos? ✅

4. Humour = Lifeboat
   If you can’t fix it, mock it. A well-timed joke in the trenches is worth more than a motivational speech from the captain.

The Emotional Impact of Failing Projects

The hardest part isn’t the failure itself. It’s knowing it’s coming, waving your arms wildly, and watching the “powers that be” blissfully ignore every red flag.

It’s like being on the Hindenburg and whispering, “Is anyone else smelling smoke?”
while management beams and says, “Nonsense! This blimp is the future!”

How to Protect Yourself in a Failing Project

When projects implode, leadership will be “shocked,” consultants will cash their cheques, and someone will quietly bury the lessons learned. But you? You’ll still have your sanity if you protect it.

Remember:

• You didn’t steer the ship.

• You didn’t order “full speed ahead.”

• And when it does go down in flames, at least you’ll have front-row seats to one of corporate life’s greatest comedies.

Because at the end of the day… sometimes the only motivation left is knowing you weren’t the one pressing the big red button.

And sometimes, the hardest part isn’t fixing the project — it’s dealing with the reality that it isn’t going to plan.

If you’re starting to see the warning signs of a failing project, it can be hard to know whether to push on or step back.

I help people make sense of messy situations and work out the most practical way forward.

If something feels like it’s heading in the wrong direction, take a look at my TechFix service.