The Great Flap: A Developer’s Guide to Manufactured Urgency

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 the Deadline

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.

Software: The Slow Art

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”.

Enter the Spreadsheet

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.

The Pushing Season

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.

The Quiet Professionals

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 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.

After the Shipwreck: The Engineers Take the Oars

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 in the Rafts

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 in the Wreckage

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.

---

Building Quietly, Building Right

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.

---

A Brighter Horizon

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.

Surviving the Sinking Ship

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

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.

---

The Telltale Signs of a Doomed Project

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.

---

Coping Strategies for the Doomed

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 Rollercoaster

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!”

---

Final Thought: Protect Thyself

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.

Switching Off for Real: My Holiday Routine (Even When I’m at Home)

When I take time off work, I take it seriously. Whether I'm heading away or having a holiday at home, I disconnect completely—and unapologetically. Working in IT, the lines between “on” and “off” can easily blur, especially when you have access to everything from your phone or laptop. But over time, I’ve learned that proper rest requires firm boundaries. So I’ve built a routine that helps me truly switch off, and here’s how I do it.

1. My Out of Office Is Clear and Firm

I don’t send vague “I’ll get back to you when I return” messages. My out-of-office email reply makes it clear:
I am out of the office and cannot be reached.

I also provide the correct route for urgent support—usually pointing people to the help desk or main IT contact number. I do this for two reasons:

• I’m not being paid to monitor or respond to work while on holiday.

• There are capable teams in place to handle things without me.

Being clear sets expectations and removes the pressure to keep one foot in work mode.

2. I Turn Off Teams Notifications on My Phone

I don’t want work chats pinging me while I’m off, especially from apps that live on my personal phone. So I switch off Teams notifications entirely. If it’s urgent, people can go through the proper channels (which, spoiler: they rarely need to).

3. I Power Down My Work Laptop—and Hide It

When my holiday starts, I shut down my work laptop completely and physically put it away. Not just out of sight—but out of reach.
This sends a signal to myself: I am not working. I am not available. I’m off.

4. I Avoid My Home Office

During workdays, my home office is where I sit and focus. But during time off, I avoid that space completely. I’ve learned that just being in that chair or at that desk can trick my brain into “work mode.” So I reclaim the boundary by physically distancing myself.

If I do need to use a computer—maybe to watch something, browse, or sort personal files—I’ll grab my MacBook and head to another room. That machine has no connection to work, and using it elsewhere helps reinforce the feeling of being off-duty.

5. I Disconnect Because It’s Healthy—And It’s My Choice

I believe it's good practice to disconnect completely. Not half-on, not checking emails in the evening, not just “keeping an eye” on things. Fully off.

Because I’m not being paid to think about work while I’m on holiday. And frankly, thinking about it doesn’t help anyone—least of all me.

Being always-available is not a badge of honour; it’s a path to burnout. Stepping away lets me return clearer, calmer, and ready to contribute again. But more than that, taking time for myself is a boundary I’ve chosen—and I stand by it.

---

Final Thoughts

Whether you’re going abroad or taking a quiet break at home, you deserve time that is yours. The emails can wait. The messages can go to someone else. And the world won’t stop spinning if you don’t check in.

My routine may sound strict, but it gives me the space to recharge. And every time I stick to it, I’m reminded: rest isn’t something I need to earn—it’s something I’m entitled to.

Speed to Fix: The High Cost of Bug-Fix Bureaucracy

In software development, how quickly a bug is fixed can have as much impact as whether it gets fixed at all.

I’ve seen this firsthand: two starkly different approaches to bug fixing played out in parallel.

One was bloated, slow, and expensive. The other was fast, collaborative, and remarkably effective. Here's what I learned.

The Bureaucratic Bug Loop

Let’s start with the typical enterprise-style approach. It looks something like this:

1. A client-side tester finds a bug.
2. The bug is logged.
3. It gets reviewed in a triage meeting—attended by the supplier’s test team, scrum master, and often several developers and stakeholders.
4. There’s a discussion: Is it a bug or a change? Often, the answer depends on how much documentation exists—or how much the supplier team understands the client's expectations.
5. If accepted as a bug, it gets assigned to a developer, who may not fully understand the feature or business context.
6. A partial fix is made, passed to the supplier's testers.
7. The tester doesn't fully grasp the requirement, so the bug reoccurs.
8. It cycles back to the developer, gets reworked, and is returned again to testing.
9. Eventually, the supplier team decides it’s fixed and pushes it back to the client.
10. The client tests it and often fails it again.

Back to triage, more discussion, more meetings.And if it’s deemed a “change” instead of a bug? Add in project managers, business analysts, architects, and further rounds of planning, discussion, and documentation before a fix can even be scheduled.

This might be called “Agile.” But it’s a heavy, slow-moving, budget-draining machine.

The Collaborative Approach

Now contrast that with another way I’ve seen bugs resolved:

1. The client identifies a bug and logs it.
2. They speak directly to the developer, someone who understands the software inside out.
3. A fix is agreed upon and implemented quickly.
4. The client tests it and confirms it’s resolved.

That’s it. No committees. No triage queues. No endless email threads or JIRA reassignments. Just shared understanding, clear communication, and speed.

Speed

• Bureaucratic: Slow—can take weeks or more to resolve a single issue.

• Collaborative: Fast—can be fixed within hours when the right people talk directly.

Cost

• Bureaucratic: High—requires meetings, coordination, and time from multiple roles.

• Collaborative: Low—minimal overhead, fewer people involved.

Accuracy

• Bureaucratic: Lower—miscommunication and lack of context often lead to rework.

• Collaborative: Higher—client and developer clarify expectations directly.

Client Satisfaction

• Bureaucratic: Often, low delays and repeated bugs cause frustration.

• Collaborative: High, quick resolutions build trust and meet expectations.

Risk

• Bureaucratic: High delays and unclear ownership increase the risk of failure.

• Collaborative: Lower issues are caught and resolved early.

Control

• Bureaucratic: Diffused—decisions bounce between teams.

• Collaborative: Focused—clear, fast decision-making with those who understand the problem.

Why Does This Happen?

In large projects, teams are often bloated, fragmented, and overly process-driven. When suppliers don’t have domain expertise—or when developers are shielded from clients—bugs become political hot potatoes. The result? Delays, rising costs, and software that doesn’t meet real-world needs.

Sometimes, requirements weren’t fully captured in writing but were clearly understood by the client. When a tester or architect insists it's not a "bug" because it wasn't documented, progress stalls. The client ends up with software that technically meets the spec, but fails to meet expectations.

The Bottom Line

Agility isn’t about ceremonies and sprint planning—it’s about responsiveness.

On many large projects, a common trap is the relentless debate over whether an issue is a "bug" or a "change." Suppliers often lean on this distinction to shield themselves from additional work, but in doing so, they risk much more. When a supplier is contracted to deliver a working software solution, repeatedly rejecting implicit requirements can lead to delays, confusion, and ultimately a poor end product. These projects often expose a gap in domain knowledge on the supplier’s side, while the client holds the business expertise that truly matters. By failing to recognise this and instead hiding behind process, the supplier may appear uncooperative, erode trust, and harm their own reputation. In trying to protect themselves, they lose credibility when they could have simply collaborated more closely and delivered a better outcome for everyone involved.

When clients and developers work closely, solutions emerge faster, software aligns better with business goals, and costs stay down. When layers of roles dilute communication, bugs linger, frustration grows, and money leaks away.

If you're managing a project, ask yourself: How many people need to be involved before something gets fixed? If the answer is more than two, you may already be losing the speed-to-fix battle.

Is Multi-Factor Authentication (MFA) a Barrier to Access?

Multi-Factor Authentication (MFA) has become a standard security measure across many online services. From banking and e-commerce to social media and even public services, MFA is touted as the best way to protect user accounts from unauthorized access. 

But while it undoubtedly enhances security, does it also create unnecessary barriers for users? Is it always necessary, or are some services forcing it upon users purely for their own convenience, without considering the impact on accessibility and user experience?

When MFA Makes Sense

There are clear scenarios where MFA is beneficial, if not essential. Any service involving financial transactions, personal data, or sensitive information should implement some form of MFA. Online banking, payment processing, and cloud storage services are prime examples. In these cases, an extra layer of authentication—whether a text message, an authenticator app, or biometrics—protects users from fraud, identity theft, and account takeovers.

For these services, the inconvenience of MFA is outweighed by the need for security. A compromised banking account can lead to financial ruin, while an exposed cloud storage service could mean loss of private or business-critical data.

When MFA Becomes a Burden

However, there are many instances where MFA feels excessive or even user-hostile. Imagine signing up for a public forum, a government website to download a form, or a simple app where security isn't a primary concern. Yet, users are often forced to verify their email, receive a one-time passcode (OTP) on their phone, or even authenticate every time they log in. For some users, this creates friction that can turn them away from the service altogether.

Older adults and less tech-savvy users can struggle with MFA. They might not have a smartphone, may not know how to retrieve an OTP, or simply forget their authentication method. This frustration can push them towards alternative, often more expensive, in-person or phone-based support channels, defeating the purpose of a digital service.

Different Types of MFA & Their Challenges

MFA can take various forms, each with its own pros and cons:

• SMS-based OTPs – Convenient but vulnerable to SIM swapping and interception.

• Authenticator apps (Google Authenticator, Authy, Microsoft Authenticator) – More secure but require setup and reliance on a single device.

• Biometric authentication (Face ID, fingerprint scanners) – Secure and user-friendly but limited to modern devices.

• Hardware security keys (YubiKey, Titan Security Key) – Extremely secure but costly and impractical for average users.

For a tech-savvy individual, these options may not seem like a problem. But for someone who rarely uses technology, requiring MFA can feel like an impossible barrier.

Who Really Benefits?

While service providers claim that MFA is for the user's benefit, in many cases, it’s more about reducing their own liability and costs associated with fraud and account recovery. A locked-out user means fewer support calls for a compromised account, but it can also mean losing customers who simply give up on the service.

Companies should consider whether MFA is truly necessary for their service or if they are implementing it just to shift the burden onto users. If security is critical, they should at least offer user-friendly alternatives and ensure that their support systems are equipped to assist those who struggle with authentication.

The Balance Between Security and Accessibility

Security and convenience are often at odds. While MFA undeniably enhances protection, it should be implemented with the user in mind. If a service deals with money, sensitive personal information, or confidential business data, MFA is a must. However, for a simple public registration system with no real security risks, forcing users to go through extra steps every time they log in can feel unnecessary and exclusionary.

Instead of taking a one-size-fits-all approach, companies should:

• Allow users to opt into MFA where appropriate.

• Offer alternative verification methods tailored to different user needs.

• Provide clear, accessible guidance on using MFA effectively.

• Avoid making security measures so frustrating that they drive users away.

At the end of the day, security should not come at the expense of accessibility. Users are not the enemy—poorly implemented security measures are. If a service forces unnecessary barriers on users, it’s not protecting them—it’s just making their lives harder.

Software Quality: What You See and What You Don’t

When clients review a software implementation—whether a website, a mobile application, or a complex enterprise system—they focus on what they can see. The user interface is their window into the software: the graphics, colours, buttons, and alignment of elements. They also experience usability issues firsthand—if a button does not work, navigation is unclear, or the system does not fit their business needs. In short, they can easily judge what is immediately visible.

The client will raise concerns if the software looks unfinished—if screen elements are misaligned, fonts are inconsistent, or colours clash. These visual issues are easy to notice and relatively simple to fix. However, what about the parts of the software that remain hidden beneath the surface?

The Hidden Depths of Software Quality

Beneath the surface of a sleek user interface lies the true foundation of any software: its underlying code. Clients do not see this, and yet, it is where some of the most serious problems can lurk.

Software that appears polished on the outside can still be a mess underneath—filled with rushed fixes, careless hacks, and neglected structural integrity. What they don’t see can be far more damaging than what they do:

• Messy, Unstructured Code – If the code is chaotic and lacks a clear structure, making changes or fixing bugs becomes a nightmare.

• Lack of Documentation – If the original developers fail to document their work, future teams will struggle to understand how the system functions.

• Poor Error Handling – A program might appear fine until an unexpected action causes it to crash because no one accounted for error scenarios.

• Hidden Loops and Inefficiencies – Poorly optimized code may lead to slow performance, excessive resource usage, or system crashes as the workload increases.

• Security Gaps – A lack of attention to security best practices could leave the software vulnerable to data breaches, even if it looks perfect on the surface.

What Poor Visible Quality Says About The Hidden Code

There is a simple but unsettling truth: if the software looks bad on the surface, the chances are high that the underlying code is even worse. A team that ignores visual consistency might also ignore proper security measures, performance optimization, and long-term maintainability. A broken button can be fixed in minutes, but a broken foundation can haunt a business for years.

Imagine a house with peeling paint and broken steps. These are surface issues, but they make you wonder: if this is how they handle the outside, what horrors lie in the wiring, plumbing, and foundation? The same logic applies to software. If a website’s buttons are misaligned and the fonts are a chaotic mix, what are the odds that the backend is filled with rushed fixes, untested functions, and hidden vulnerabilities?

How This Hurts Clients

Clients who only judge software by its visible appearance might not realize the problems they are inheriting. The real damage happens over time:

1. Rising Maintenance Costs

When software is built with shortcuts and sloppy code, future updates become expensive. A simple feature change can take weeks because developers have to untangle the existing mess first.

2. Unexpected Failures

A system that looks fine today might suddenly start failing under real-world conditions. A small data spike, a minor software update, or an overlooked error scenario could bring the entire system crashing down.

3. Security Risks

Poorly structured software often contains security vulnerabilities. A minor oversight in data handling can lead to serious breaches, putting customer information and business integrity at risk.

4. Scalability Nightmares

A company may grow, but a poorly designed system will not grow with it. What works for 100 users might break completely when stretched to 10,000 users. The business then faces expensive rewrites and lost opportunities.

5. Damage to Reputation

A slow, buggy, or unreliable platform can lead to frustrated customers, negative reviews, and lost revenue. In many industries, trust and reliability are everything—once lost, they are hard to recover.

Ensuring Quality from the Inside Out

While clients may not see the code, it is the responsibility of development teams to uphold quality standards at every level. The key to avoiding the dangers of hidden software rot lies in discipline and best practices:

• Code reviews ensure standards are maintained and prevent bad practices from taking root.

• Comprehensive testing helps catch issues before they reach production.

• Clear documentation allows future developers to understand and maintain the software.

• Security-first development prevents costly vulnerabilities and breaches.

• Performance optimization ensures scalability and efficiency over time.

Final Thoughts

When evaluating software, it is easy to focus on what can be seen, but true quality goes much deeper. If the surface appears neglected, there is a strong chance that the underlying software is full of quick fixes, rushed patches, and hidden problems waiting to surface.

A reliable and long-lasting software product is one where both the user experience and the underlying structure are given equal care. Clients should demand quality beyond the visible, and developers should take pride in crafting software that is solid from the inside out. Because if left unchecked, the unseen problems will one day come to light—with costly consequences.

The Hidden Cost of Rushed Development

In software development, as in gardening, laying the proper groundwork is key to long-term success. A well-prepared foundation ensures stability, scalability, and maintainability. 

However, when shortcuts are taken in the name of speed, it leads to technical debt, inconsistencies, and a maintenance nightmare down the line.

Many inexperienced or rushed suppliers often cut corners, making small decisions that seem harmless at the moment but snowball into major issues. Let’s explore some poor software setup practices and contrast them with proactive, experienced development approaches.

Sloppy and Smart Development

1. Styling Without a Centralized CSS

Lazy Supplier Approach:

• Embed styles directly within pages rather than using a central CSS file.

• Creates multiple button classes with slightly different styles because they forgot the existing ones.

• Hardcodes colours, fonts, and margins directly into HTML elements instead of using reusable styles.

Proactive Supplier Approach:

• Uses a structured CSS framework where styles are centrally managed.

• Defines global classes for buttons, headers, and other UI elements to maintain consistency.

• Implements variables in CSS (or a preprocessor like SCSS) for colours, spacing, and typography, ensuring a single source of truth.

Why It Matters: A centralized approach ensures that a change to a button style reflects across the entire site, eliminating inconsistencies and reducing the time spent hunting for rogue styles.

2. Poor Management of Data Validation and Regex

Lazy Supplier Approach:

• Defines regex validation rules individually in each form field.

• Hardcode validation rules directly into multiple places in the code.

• Fails to document regex patterns, leading to inconsistencies and hard-to-debug validation issues.

Proactive Supplier Approach:

• Stores regex validation rules as global constants or reusable functions.

• A single validation method is applied across all relevant fields to ensure uniformity.

• Documents and maintains a validation standard to prevent inconsistent rules across different parts of the application.

Why It Matters: Defining validation rules in a central location makes updates easy and ensures consistency across all forms in the system.

3. Magic Numbers and Hardcoded Values

Lazy Supplier Approach:

• Hardcode prices, tax rates, or other business-critical numbers directly in multiple locations.

• Uses fixed numeric values in calculations without clear documentation.

• Requires developers to search the entire codebase when a value needs updating.

Proactive Supplier Approach:

• Stores all key numbers in global constants or configuration files.

• Implements environment variables for values that may differ between testing, staging, and production environments.

• Uses a configuration management system to control price updates from a single location.

Why It Matters: If a tax rate or price structure changes, updating a single value should be all that’s required rather than combing through an entire application to find and update hardcoded values.

4. Inconsistent HTML Structure and Headings

Lazy Supplier Approach:

• Uses <div> elements for all text without defining proper <h1>, <h2>, or <h3> tags.

• Resize text manually on each page instead of using CSS styles.

• Creates accessibility issues by not structuring content correctly.

Proactive Supplier Approach:

• Uses semantic HTML, ensuring proper hierarchy with <h1>, <h2>, and <h3> tags.

• Defines text styles in CSS so heading sizes and spacing are uniform across the site.

• Follows accessibility guidelines, improving SEO and user experience.

Why It Matters: Proper heading structure improves readability, accessibility, and SEO, while ensuring a consistent look and feel across the site.

The Slippery Slope of Quick Fixes

A lazy or rushed supplier might justify their choices by saying, “I don’t have time to structure this properly—I just need to make it work.” While this approach may show quick progress in the short term, it creates major problems as the project scales.

When corners are cut:

• Bugs multiply because different elements that should behave the same begin behaving differently.

• Making changes requires updating multiple instances instead of a single location.

• The project becomes difficult to maintain as inconsistencies grow.

• Expansion and feature additions take longer due to poor groundwork.

Conclusion: Laying the Right Foundation Saves Time and Effort

A proactive, experienced supplier understands that good groundwork leads to efficiency, easier maintenance, and a scalable product. Taking the time to plan, structure, and centralize the core elements of an application is an extra step. Still, it ultimately saves time, reduces errors, and ensures a more polished and professional final product.

In software development, as in gardening, taking shortcuts at the beginning will only lead to more work later. Lay the foundation properly, and you’ll build something that grows and thrives rather than something that constantly needs fixing.

When Is a Bug Really a Bug?

In software development, few topics create as much debate as defining a "bug." From a client's perspective, a bug is anything that doesn't work as expected. 

From a supplier's perspective, however, a bug is often dismissed as a missing requirement, conveniently reframed as a change request to avoid responsibility. This discrepancy leads to frustration, delays, and a growing sense of mistrust between the two parties. 

So, where do we draw the line?

The Client vs. Supplier Perspective

Clients rely on software to function intuitively and predictably. When something disrupts their workflow or doesn't meet reasonable expectations, they rightly label it as a bug. Conversely, suppliers frequently hide behind vague requirements, using loopholes to avoid fixing issues unless explicitly documented.

For example, consider an online form designed to collect UK phone numbers. Is that a bug if a user can enter letters instead of numbers? The client would argue yes—it prevents valid data entry and should have been accounted for. The supplier, in contrast, might claim that since validation rules were not explicitly stated, they are not responsible. This kind of evasiveness only serves to frustrate clients and degrade trust in the development process.

The Implicit vs. Explicit Requirement Debate

Software inherently includes implicit requirements. Much like a cookbook doesn’t instruct the reader to fetch a pan before cooking, some aspects of functionality should be assumed. However, suppliers often exploit ambiguity to deflect responsibility, insisting that anything not meticulously spelt out is outside the scope.

Taking this a step further, consider high-level system-wide requirements, such as accessibility compliance. If a client states that a website must adhere to Web Content Accessibility Guidelines (WCAG), does this mean they need to specify every single place it applies? No reasonable supplier should need such micromanagement. Yet, when accessibility issues arise, suppliers often attempt to classify them as change requests rather than take accountability for meeting industry standards.

The Risk of Cloudy Boundaries

When suppliers dodge responsibility by blurring the distinction between a bug and a change request, projects slow down, costs rise, and clients are left with a system that doesn't meet their needs. This kind of behaviour not only undermines collaboration but also erodes confidence in the supplier’s ability to deliver a quality product. Clients expect professionalism, not excuses.

A Practical Approach to Resolution

So, how do we navigate these challenges and hold suppliers accountable? Here are some guiding principles:

1. Clients Shouldn't Have to Spell Out the Obvious: Suppliers should apply industry best practices and anticipate common-sense expectations.

2. Refusing to Fix Clear Issues Is Bad Faith: If a reasonable user would expect certain functionality to work in a certain way, the supplier should address it without excessive debate.

3. Minor Fixes Should Be Resolved, Not Argued Over: Simple fixes, like adding basic validation, should not become lengthy discussions about scope.

4. Transparency and Accountability Matter: Suppliers should not weaponize requirements documentation to avoid doing the right thing.

Conclusion

The line between a bug and a change request isn’t always clear, but clients shouldn’t have to fight tooth and nail to get a functional product. Suppliers who play games with definitions to dodge responsibility only harm their own credibility. Instead of hiding behind technicalities, suppliers should prioritize collaboration, efficiency, and above all, delivering software that works as expected.

The Purpose and Pitfalls of Bug Triage in Agile

Bug triage is crucial in ensuring quality and delivering value in any software delivery project, especially those adopting Agile methodologies. The purpose of bug triage is simple yet critical: to assess, prioritize, and plan the resolution of defects in a way that aligns with the project’s goals and timelines. However, when poorly executed, bug triage can drift away from its intended purpose and hinder progress, ultimately threatening the project's success.

This post explores the purpose of bug triage, common pitfalls that arise, and how teams can steer this essential process back to the principles of Agile.

The Purpose of Bug Triage

In Agile, bug triage is more than just a meeting to discuss defects. Its purpose is to:

1. Evaluate Defects: Determine the validity and severity of reported bugs.

2. Prioritize Issues: Assign urgency based on the impact on functionality, user experience, and business objectives.

3. Facilitate Collaboration: Foster open communication between developers, testers, and stakeholders to address issues efficiently.

4. Enable Quick Feedback Loops: Stay true to Agile principles by resolving defects swiftly and incorporating fixes into the delivery cycle.

At its best, bug triage aligns the team on priorities, empowers quick decision-making, and maintains a clear path toward delivering high-quality software.

When Bug Triage Goes Wrong

Despite its noble intentions, bug triage can quickly derail, leading to frustration, inefficiency, and a departure from Agile principles. Here are some of the common signs and issues:

1. Excessive Pushback on Bugs

Stakeholders may question the validity of defects, claiming that they:

• Bugs are not part of the original requirements.

• Are not reproducible, even when intermittently observed.

• Should be closed despite unresolved issues, often to reduce visibility or perceived system instability.

Such behaviours create an environment where legitimate defects go unaddressed, leaving the system vulnerable.

2. Implicit Requirements Ignored

Software often carries implicit expectations—functionality that users naturally assume will work without needing explicit documentation. Dismissing these as “not requirements” undermines the user experience and trust in the system.

3. Pressure to Reclassify Bugs

There is often pressure to:

• Downgrade the severity of critical defects.

• Convert bugs into change requests, shifting the burden of resolution away from the immediate sprint or release.

These tactics erode the team’s credibility and disrupt Agile’s focus on delivering working software incrementally.

4. Lengthy Discussions on Simple Fixes

Some bugs, which could be resolved in minutes, instead go through protracted debates to gain acceptance. This delay fixes and clogs the pipeline, frustrating developers and testers alike.

5. Visibility and Credibility Issues

Attempts to reduce the visibility of unresolved bugs—by closing them prematurely or misclassifying their impact—mask deeper systemic issues. This can result in a false sense of readiness, jeopardizing the project’s go-live success.

Steering Bug Triage Back to Agile Principles

To restore the purpose of bug triage and ensure it supports Agile delivery, consider the following strategies:

1. Focus on Collaboration, Not Conflict

Bug triage should be a forum for collaboration rather than contention. Establish a culture of openness where all stakeholders recognize the shared goal of delivering quality software. Encourage constructive dialogue over blame or defensiveness.

2. Define Clear Criteria for Bugs

Set clear guidelines for:

• What constitutes a valid bug.

• How severity and priority are assigned.

• How to handle intermittent issues and implicit requirements.

Having agreed-upon standards reduces subjectivity and expedites decisions.

3. Empower the Team to Act

Agile thrives on the ability to make quick adjustments. For straightforward bugs, allow developers and testers the autonomy to resolve and validate fixes without prolonged debate. Reserve triage discussions for complex or high-impact issues.

4. Respect the User’s Perspective

Implicit requirements reflect the end-user’s expectations. Dismissing these can erode trust and usability. Ensure that user experience is a core consideration during triage.

5. Track Decisions Transparently

Documenting the rationale for closing, downgrading, or converting bugs ensures accountability and visibility. This practice builds trust among team members and stakeholders.

6. Align with Agile Values

Remember the Agile manifesto: “Individuals and interactions over processes and tools” and “Responding to change over following a plan.” Let these principles guide your approach to bug triage, focusing on value delivery and adaptability.

Conclusion

Bug triage is a vital component of Agile delivery, but it requires diligence and alignment with core principles to be effective. By fostering collaboration, establishing clear criteria, and focusing on delivering value, teams can transform triage meetings from a source of frustration into a cornerstone of success.

If your team is struggling with bug triage, reflect on the issues outlined here. Small adjustments can make a significant difference, steering the process back to its intended purpose and ensuring your project remains on track.