DEV Community: Joab Owala

Be the reason the network doesn’t crash.

Joab Owala — Tue, 03 Jun 2025 19:52:19 +0000

Joab Owala

Jun 3 '25

We Crashed the Network And It Was Glorious

#techevents #networking #scalability #devops

Comments 2

3 min read

We Crashed the Network And It Was Glorious

Joab Owala — Tue, 03 Jun 2025 19:23:06 +0000

At the recently concluded Africa Tech Summit, everything was buzzing the energy, the innovation and quite frustratingly the network outages. If you arrived early, the connection worked seamlessly and as always you don't notice until the unthinkable. By mid-morning, things went downhill fast. Why does this happen so often at tech events? and of-cause not just tech events.

The answer, in many cases, is a form of accidental DoS (Denial of Service) not the malicious kind but a simple case of too many devices trying to connect to limited infrastructure.

The Bottleneck: Overloaded “Busters”

In my country, we call base stations "busters". These are the network nodes (usually wireless access points or cellular base stations) responsible for routing data to and from devices.

Each base station has a limit to how many devices (or nodes) it can handle efficiently. Once that number is exceeded, it starts dropping connections, delaying packets and making your browser feel like it's loading over a 2G network.

Why not just increase the capacity?

Scaling Isn't That Simple

Here’s where scaling comes in and why it's not just a plug-and-play solution:

1. Vertical Scaling (Scaling Up)

Upgrading the base station with more powerful hardware, more memory, better antennas and higher bandwidth. But there’s a physical and regulatory limit to how much you can upgrade. Plus, vertical scaling still doesn't address distribution or redundancy.

2. Horizontal Scaling (Scaling Out)

Adding more base stations to distribute the load sounds ideal. But here’s the catch: base stations need to coordinate handovers as people move around. Devices automatically shift from one to another based on signal strength a process called handover.

When coverage areas overlap poorly or handover logic isn’t well-tuned, it leads to instability. Devices “ping-pong piki piki ponki” between stations or cling to weak connections.

3. Load Balancing

Load balancing works great in data centers. At tech events? You’ve got a chaotic mix of smartphones, laptops, wearables, all running different OSes, aggressively scanning for connections.

Real-time balancing at this scale is complex and expensive especially for a short-term event.

Could It Be About Optimizing Software?

Here’s another angle worth considering:

Could better software design reduce the strain on infrastructure?

What if apps were built to batch requests, defer syncs, or default to offline-first? One app polling every second seems harmless until a thousand people run it at once.

It’s not just the network hardware sometimes, it’s how we write the code.

What Actually Helped Us

Thankfully, we were ready: most of our event resources were offline-first.

No internet? No problem. Our demos, presentations and apps didn’t rely on live network calls. That saved us.

What Could Be Done Better?

Some practical solutions for tech events:

Deploy mobile base stations

Telecoms can bring in trucks equipped with temporary base stations to provide extra coverage. A good example being during the Safari Rally Kenya.
Predict device density

Use historical data or real-time tracking to estimate device load per area and allocate resources dynamically.
Segment the network

Create separate networks for attendees, staff, and demos to reduce congestion.

Final Thoughts

DoS at tech events isn't always about hackers, sometimes it’s just too many people trying to do too many things over too little infrastructure.

Understanding the limits of scaling and the nature of wireless networking can help us prepare smarter.

If you’re organizing or attending a tech event, remember:

offline-first is your best friend and having a few extra “busters” wouldn’t hurt either... or so you think.

Think not why the network failed, think how you can design to thrive when it does.

Resilience isn’t just about having more resources, it’s about being ready when they’re gone.

Demo or Die trying

Joab Owala — Tue, 27 May 2025 12:37:13 +0000

Joab Owala

May 22 '25

Demo or Die Trying: A Guide to Screen-share Survival

Comments

4 min read

Demo or Die Trying: A Guide to Screen-share Survival

Joab Owala — Thu, 22 May 2025 05:37:37 +0000

So you’ve agreed to do a demo. Buckle up: it’s basically a stand-up comedy where the code plays clown. Demos matter because, yes, someone actually cares what you built (and they expect it to work). This is your chance to show off your genius, justify that two week sprint, or at least avoid getting fired for the day.

“If it compiles on the first try, a nyawawa (demon) is probably involved.” Odhiambo. F

Why Demos Matter (Even if You’d Rather Be Coding)

Show Your Masterpiece: A demo lets you share what you’ve built. Managers and coworkers finally see your code in action instead of trusting your rambling status updates and confluence edits. I know you already know that.
Get Real Feedback: Ever wonder if anyone actually cares about that one obscure feature you spent a week on? A demo answers that (and gets you useful questions instead of blank stares).
Avoid the “But Why?” Questions: It’s better they see it now than ask “So… can it do X?” in front of everyone later. That’s how meetings turn into horror shows.
Demonstrate Progress: Think of it like a report card or timecard. You get to prove you weren’t just binge-watching cat videos all sprint.

Plan and Structure Your Demo (Or Prepare to Wing It and Swoon)
A good demo has a flow. Randomly clicking around in your IDE is not it. Think of your demo like cooking a meal for guests:

Appetizer (Intro/Context): Set the stage quickly. What problem are you solving, or what new feature are you unveiling? Keep it punchy.
Main Course (Live Code/Features): Highlight the meaty part. Show one or two key features or code paths step by step. Keep it simple, don’t deep dive into every branch of the code.
Plating (Transitions): Have an outline or script. Know which files, branches, or windows you’ll open. Silence notifications, hide embarrassing tabs, and pretend your browser bookmarks are private.
Dessert (Summary/Next Steps): End with a flourish. Recap what you showed and tease what’s next. Aim to leave them craving the next course, or at least satisfied with tonight’s meal.

Remember each part shouldn’t run as long as your backlog aims for clarity, not a brain-melting feature dump.

Know Your Audience: Tech Geeks vs. Mere Mortals

Tech Geeks: Your tribe wants details. Feel free to geek out with diagrams or code snippets (just don’t read every semicolon aloud).
Casual Crowd: Ditch the acronyms. Explain the why over the how. If they don’t know Docker, don’t dissect Kubernetes; just say it’s a way to run stuff reliably.
Everyone: Use analogies and humor. If eyes glaze over, ask a question or toss a joke. (Treat your audience like goldfish: too much detail and they’ll swim away, but feed them the right tidbits and they might stay.)
Stay Flexible: If your audience shifts (managers walk in, or half the room dozes off), be ready to pivot on the fly. Maybe say, “I’ll simplify that!” and adjust on the go.

Demo Horror Stories (Fictionalized Folklore)

The NullPointer Nightmare: Bob starts with untested code. Crash! A giant red NullPointerException appears. “It’s a feature!” he claims, sweat and all. Lesson: always test, and sanitize your error handling.
Wi-Fi Apocalypse: Sarah’s demo needs internet. Mid-pitch, the office Wi-Fi takes a vacation. Cue eternal loading. She ended up narrating a slide deck for 20 minutes, calling it a “conceptual preview.”
Forgotten Passwords: Mike shares his screen… and forgets to hide his password manager. Now passwords fly everywhere. Note to self: lock up secrets before screen-sharing!
Microphone Mutiny: Denil answers questions beautifully… until he realizes nobody heard him because his mic was muted. The audience gave a standing ovation to his mime act.
Auto-Update Armageddon: Lee kept talking while an auto-update progress bar slowly marched across his screen. Eventually it rebooted. (Tip: turn off updates before you demo, unless you love forced naps.)

These tales are dramatic exaggerations, of course, but every dev has at least one horror story like them. Moral: expect the unexpected and always have a Plan B.

Common Mistakes to Avoid

Winging It: No one believes a flawless, impromptu demo. Even rock stars rehearse. Write a script or at least bullet-point your steps.
Data Dump: Bombarding everyone with 47 menu items and endless settings is boring. It’s the demo equivalent of reciting your grocery list.
Ignoring Time: A two-hour demo is murder (especially if you’re solo). Practice with a timer. If your audience starts doodling, you’ve officially lost them.
Neglecting Setup: "Unknown host", permission pop-ups, or missing libraries can kill you. Prep your environment thoroughly. Maybe even reboot and try again.
Forgetting the Audience: A monologue of code and jargon only impresses you. Make eye (or webcam) contact, invite questions, and connect the dots verbally.

Pro Tips for Demo Domination

Practice Religiously: Run through the demo alone and with someone else. You want to squash hiccups now, not on stage.
Keep Visual Aids Handy: A diagram or slide helps ground the explanation. It’s your safety net if the live bit stalls.
Silence All the Things: Mute Slack, email and random notifications especially the WhatsApp Web notifications. The worst is a cringe meme or boss’s personal message popping up mid-demo.
Backup Plan: Have a pre-recorded demo video or slide deck ready if live fails. It’s like having a stunt double for your code.
Keep Your Cool: If something breaks, laugh it off and move on. Even fictional coder Zen Masters recommends: “If my demo crashes onstage, at least I’ll go out in a blaze of glory.”

Keep it short, snappy, and a little snarky. You’re the star, but try not to steal the show from your code. Wrap up confidently: “That’s the gist, questions?” and mean it. You’ve survived the bugs and the spotlight. Now go forth and have no fear, “Even if you're not ready for the day it can't always be night” . In the world of demos, you’ll either dazzle them or give them one heck of a story for the next stand-up meeting. Either way, it’s memorable.

Written with ❤️ by a human (or so I claim). AI detectors say it's 99.99% machine-made..those snitches. Don’t believe them. I’m just a very caffeinated developer with suspiciously good grammar.