19169

page-template,page-template-blog-large-image,page-template-blog-large-image-php,page,page-id-19169,stockholm-core-2.4.4,select-child-theme-ver-1.1.3,select-theme-ver-9.12,ajax_fade,page_not_loaded,,qode_menu_,wpb-js-composer js-comp-ver-7.9,vc_responsive

Blog

January 24, 2025 In Uncategorized

Building Technical Leadership: The Role of Principal Engineer at Facet Digital

At Facet Digital, we believe that outstanding software engineering goes beyond writing great code. It’s about building technical leadership and nurturing technical leaders who can drive innovation while upholding the high standards our clients expect. Today, we share our perspective on one of our most crucial leadership roles: the Principal Engineer.

Evolution of Technical Leadership

When we founded Facet Digital, technical leadership resided solely with the founding partners, Scott and Jeremy. As we’ve grown, we’ve carefully designed our leadership structure in order to scale our ability to consistently deliver superior results. Our Principal Engineer role represents a critical piece of this. It’s a position we’ve intentionally developed to maintain our rigorous standards while expanding our impact and building technical leadership across the organization.

Beyond the Staff Engineer

A Principal Engineer at Facet builds upon the foundation of our Staff Engineer role. For context, here’s how we define these positions in our internal handbook:

"A Staff Engineer is a senior technical contributor who works on complex projects, often leading efforts in their area of expertise without the direct management of teams. They are highly skilled engineers who influence technical decisions and mentor other engineers. The role is more hands-on and focused on specific technical challenges compared to the Principal Engineer, who often has broader responsibilities."

The Principal Engineer role takes this further:

"A Principal Engineer is a senior individual contributor with broad technical influence across the company. They work on the most critical projects, drive innovation, and set engineering standards. While similar to a Staff Engineer, a Principal Engineer typically has a wider scope, often impacting multiple teams or the entire engineering organization, and they may take on some strategic responsibilities without having direct reports."

Impact Across Projects

One of the unique aspects of our Principal Engineers is their ability to influence quality and innovation across multiple projects. As a client, even if your project team doesn’t include a dedicated Principal Engineer, you benefit from their oversight and guidance through:

Technical standards and best practices they help establish
Architectural reviews and guidance
Cross-project knowledge sharing
Quality assurance and mentorship

Building technical leadership at Facet Digital also means equipping Principal Engineers with the tools and opportunities to shape the future of engineering within our organization.

Career Growth at Facet

For engineers joining Facet, the Principal Engineer role represents a clear path for career advancement. It’s a position that offers:

Technical leadership without moving into management
Broad influence across multiple projects and teams
Exposure to wide variety of technologies, domains, and industries
Opportunity to shape technical strategy
Balance of hands-on development and strategic work

Looking Forward

As Facet continues to grow, we’re selectively expanding our Principal Engineer tier. Our recent internal promotion of one of our Staff Engineers into this role reflects both our commitment to growing talent from within and our high standards for technical leadership.

We’re always interested in connecting with engineers who aspire to this level of technical leadership or who have already demonstrated these capabilities in their careers. At Facet, you’ll find a culture that values technical excellence, thoughtful leadership, and continuous growth.

👋 If you’re interested in learning more about technical leadership opportunities at Facet Digital, or if you’re looking for a consulting partner that takes technical excellence seriously, we’d love to connect.

September 23, 2023 In AWS, Cloud, Networking

AWS’s IPv4 Cost: Is Pure IPv6 Your Solution?

Earlier this year, AWS announced that all public IPv4 addresses, regardless of their usage status, will now come with a monthly charge of just under $4. While this might seem like a nudge towards the future – pushing more and more services to transition to IPv6 – it’s essential to pause and consider the broader ramifications before making a knee-jerk leap to abandon IPv4 all together.

The IPv6 Allure

There’s no denying the appeal of IPv6. With its virtually limitless address space and some inherent security features, it represents the future of internet connectivity. Given AWS’s new pricing model for IPv4, businesses might feel the urge to transition entirely to IPv6, eliminating dual-stack setups to cut costs. After all, why pay for something when a “free” alternative exists?

The Hidden Pitfalls

Before making any hasty decisions, it’s crucial to remember that the global internet ecosystem’s shift to IPv6 is still very much a work in progress.

ISP Limitations: Many ISPs, especially smaller ones or those in certain regions, still don’t support IPv6. This means that if your service is IPv6-only, users on these networks would be unable to access it.
Hardware Concerns: A sizeable chunk of home networking equipment, particularly older models, either don’t support IPv6 or need specific configurations to handle it. Even if a user’s home wifi equipment does support IPv6, it’s entirely possible they haven’t enabled or properly configured it. By going IPv6-only, there’s a risk of alienating these users.
OS & Device Support: While most modern devices and operating systems support IPv6, older versions or specific models might face compatibility issues.
Third-Party Service Dependencies: Another crucial factor to consider is your dependencies on third-party services. If these services haven’t made the IPv6 leap yet, your systems will still need to communicate using IPv4. This would necessitate the use of NAT Gateways for IPv4 outbound traffic. Ironically, this would still bring about the very cost you might be trying to avoid by moving away from IPv4.

A Possible Solution (With a Catch)

For those eager to make the IPv6 transition while ensuring maximum accessibility, some proxy/translation services like Tayga, Jool, or TOTD can be considered. These services act as bridges, allowing IPv4 clients to connect seamlessly to your IPv6 services. But here’s the catch: if you set this up on AWS using EC2, you’d be reintroducing IPv4 addresses into your setup, which you’ll be charged for. So, while this solution bridges the compatibility gap, it might not help you escape those newly introduced costs completely.

Of course, you need to be wary: introducing another layer in your infrastructure can add complexity, potential points of failure, and even unforeseen costs. Moreover, these translation methods might not be suitable for all applications due to latency or compatibility issues.

Conclusion

While AWS’s new pricing might push us to expedite our IPv6 journeys, it’s essential to approach this transition thoughtfully. Before making any significant changes, evaluate the demographics of your user base, their ISPs, and the devices they use. Embracing the future is vital, but ensuring accessibility and seamless user experience is paramount.

👋 Remember, Facet Digital here to help guide you through this transition. Contact us for a free 30-minute consultation, and let’s pave the way forward together.

September 9, 2023 In Process, Productivity, Uncategorized

Slow is Smooth; Smooth is Fast

“Slow is smooth; smooth is fast.”

This adage is a cornerstone in military training and precision sports. It encapsulates the principle that meticulous and deliberate actions, learned through repetition and deliberate practice, lead to swifter and more successful outcomes in the end. It champions the notion that fostering patience and delving deeper into understanding a task can expedite the journey to achieving it, steering clear of the pitfalls that haste often brings in its wake.

In software development, this wisdom reverberates with equal significance. The frenzied pace of progress can sometimes eclipse the fundamental principles of smooth, fluid, and predictable execution. Yet, adhering to quality and precision from the very outset often propels us towards our goals faster than a hurried approach would. This ideology nudges us to value excellence over sheer speed, recognizing that a seemingly slower route often manifests as faster and more reliable results over time.

To integrate this philosophy into software development, teams should invest in:

A Clear, Shared Vision – Nothing slows you down more than going fast in the wrong direction.

Establish a clear and unified vision before the onset of the project. This involves understanding the “why” and the “what” of the end goals, distinguishing essential features from those that can be deferred, and achieving team alignment prior to diving into execution.
Automation and Rapid Feedback Cycles – The earlier you catch it, the cheaper it is to fix.

Embed a culture of automation and feedback from the first day of development. Use tools that facilitate swift feedback loops, enabling bugs to be identified early in the “assembly line”. Use monitoring, alerting, logging, A/B testing, canary deploys, and feature flags to find issue in production before your customers do. Conduct QA acceptance testing to stop defects from ever making it to production. Use robust test code coverage to catch bugs in CI/CD stages, before they make it to the QA team, or even to other developers. Provide developers a robust, prod-like developer bench-testing environment so that they can ensure their code functions properly before it even gets to CI. Use modern IDE tools that can catch bugs and issues in real time as you type before you ever try to run it. With tooling, test coverage, deployment automation, non-prod environments, and other tooling, you can prevent a slew of costly setbacks down the road and ensure smoother progress toward the end goal.
Code Quality Practices – Make it easier to do the right thing that it is to take shortcuts.

Allocate time to implement static analysis tools such as linters, complexity analyzers, open-source dependency scanners, security scanners, and style/convention enforcers early in the process. Establish practices like draft pull request, PR templates, required peer code reviews, and ADRs (Architecture Decision Records). Although stopping to lay these foundations might extend initial timelines slightly, they reap dividends in the long run by fostering a culture of quality and efficiency, ultimately saving time and resources.

💡 It’s important to recognize that certain elements of project development flourish when approached as calculated investments in smoothness and consistency of execution, rather than hastily attached solutions in response to urgent crises or market forces pulling you in all directions. An early focus on ‘smoothness’ can preclude the necessity for rushed, reactionary steps later, thereby optimizing both time and resources.

👋Need help achieving excellence in execution? Contact Facet Digital today to find out how we can help you refine the fundamentals and start firing on all cylinders again.

DALL·E 2023 08 31 12.40.32 van gogh style painting of the wall of a train station showing 3 analog clocks on the wall above an empty bench one at 9 15 one at 11 15 and one at

August 31, 2023 In Agile, Meetings, Process, Productivity

Optimizing Standup Times for Distributed Engineering Teams

In the modern age of software development, where remote work has become more of a rule than an exception, managing co-located and distributed software engineering teams comes with its unique set of challenges. One of the most debated topics is: When’s the ideal time for a daily standup?

Software engineers are an eclectic breed. They’re often deep thinkers, introverted, and sometimes have schedules that deviate from the typical 9-5 mold. Their peak productivity might be at midnight or at dawn, and distractions, especially meetings, can be a bane to their workflow.

So, what’s the best time for a standup?

Prospective Time Slots (in US Pacific Time) and Rationale:

9:00 AM:
- Pros: It’s the start of the conventional workday on the West Coast. Engineers have fresh minds and can set the tone for the day.
- Cons: For East Coast teams, this is lunchtime, and for the West Coast engineers who are night owls, this might be too early – especially if they want to get some exercise in before work.
11:00 AM:
- Pros: Still morning on the West Coast, with enough time to get warmed up and into action, and early afternoon on the East Coast. It’s a good midpoint, with enough time after lunch for the East Coasters to get their brains back in action and take a focus break during the traditional mid-afternoon lull.
- Cons: It may interrupt the flow of work, especially for those who have started their day early.
1:00 PM:
- Pros: Post-lunch on the West Coast and late afternoon on the East Coast. A good time to regroup after a break for the Westies.
- Cons: For those on the East Coast, the day is almost over, and for those who had a productive day, it may feel like quitting early while they’re trying to squeeze out a bit more code before the end of the day.

Considering the diverse nature of our engineers, their varied peak productivity times, and the need to accommodate multiple time zones, it’s imperative to strike a balance.

Our Stance at Facet Digital:

At Facet, after considerable deliberation and trial, we’ve settled on 11:00 AM (Pacific Time) as the ideal time for our projects to hold daily standup meetings. Here’s why:

It’s a good middle ground, ensuring no one’s day starts or ends with a meeting.
For our West Coast team, it allows a solid workblock in the morning and then another after the standup.
For our East Coast team, it’s early afternoon, allowing them to provide updates while still having a chunk of their day left.

In conclusion, while there’s no ‘one-size-fits-all’, it’s essential to understand the unique characteristics and preferences of software engineers. A standup should empower, not hinder. Hence, select a time that minimizes interruptions, respects individual work rhythms, and fosters collaboration across time zones.

DALL·E 2023 08 28 10.38.34 matt groening style cartoon drawing of the side view a cheetah sitting at a desk writing software with a giant thick iron chain holding him back digi

August 28, 2023 In Code, Estimation, Process, Productivity, Tech Debt, Uncategorized

Top 10 Software Developer Productivity Killers

If you’ve recently found yourself trapped in a catacomb of chaotic code or entangled in a web of woefully unclear requirements, fret not! Bob’s journey through the perilous pitfalls of developer productivity is the adventure you’ve missed. Over the past two weeks, we’ve run a daily series of blog posts about the most prevalent software developer productivity killers we, at Facet Digital, often see in the engineering teams we are hired to assess. Some of these have do to with the technical team and their decisions, and some of them have to do with the business support around them.

Here’s a quick recap:

01	Useless Meetings	Breaking up the Maker’s focus time
02	Open-Plan Offices	Noise and visual distraction disrupt concentration
03	Technical Debt	Short cuts now make innovation take longer later
04	Dead Code	Hours wasted maintaining or searching through garbage
05	Too Many Status Reports	Talking more about work than doing the work
06	Unclear Requirements	Spending too much time guessing at the wrong intent
07	Poor Branching Strategy	Working in too large of chunks and not getting feedback quickly
08	Unrealistic / Arbitrary Deadlines	Demoralizing and stifling creativity
09	Micromanagement	Not letting the brains you hired use their brains to the fullest
10	Poor Documentation	Making the next dev guess and explore without a map

Familiar foes? If these productivity antagonists have been causing chaos in your dev-life, contact us for some superhero assistance.

🙋‍♀️ Encountered another productivity villain we missed? Share in the comments which dastardly devils resonate with you and any others lurking in the shadows!

August 25, 2023 In Uncategorized

Tech Docs: The Unsung Hero

Software Developer Productivity Killer #10: Lack of Good Docs

Picture this: Bob, having navigated through unclear requirements, suffocating micromanagement, and the pressure of unrealistic deadlines, comes face-to-face with… a wall. Not just any wall, but a vast, blank barrier that lacks information, direction, and clarity. This, my friends, is the wall of poor documentation.

👮‍♀️ Why Documentation is Non-Negotiable

Documentation isn’t just a sidekick; it’s the hero of software development. It’s the translator between developer lingo and the rest of the world, and between past developers and their successors.

Onboarding Obstacles: New developers spend countless hours, not in producing quality code, but in decrypting existing systems, trying to understand processes, and setting up their environment. Good documentation is like a lighthouse, guiding them safely to shore.
Maintenance Mayhem: Without proper documentation, diving back into a codebase becomes a guessing game. Fear of changing code creeps in, and the result is stagnation, hesitation, and decreased productivity.
The Wrong Kind of Adventure: Developers love problem-solving, but being forced to explore a project blindfolded because of lack of documentation? That’s not the kind of adventure they signed up for.

📄 Essential Characteristics of Good Documentation

Dated and Versioned: Knowing when information was documented and which version it pertains to can be invaluable. It is imperative to be able to see and track changes to a document over time – who, what, and why.
Searchable and Navigable: Use platforms like Confluence or Slab to ensure your documentation can be quickly located, through both searching and intuitive navigation.
Templated Consistency: Uniformity in documents, like design doc templates or post-mortem templates, speeds up comprehension.
Location, Location, Location: Docs should reside close to their point of use. READMEs inside repositories, FAQs in the help section, architecture diagrams in wikis, and so on.
Stay Fresh: Outdated or irrelevant documentation can be worse than no documentation. Regularly review and prune as necessary.

🛥️ The Onboarding Advantage

A pro tip? Have your newest hires follow and enhance the onboarding documentation. This ensures a fresh set of eyes refines the process consistently.

And for a truly revolutionary approach? Consider integrating a bespoke private LLM AI system. Train it on your documentation and watch as developers simply query the system to get accurate, traceable answers straight from your archive. It’s an innovation Facet Digital is passionately pioneering.

📣 To all the leaders and developers out there, documentation is the unsung hero of productivity. Let’s give it the spotlight it deserves. And if you’re looking to revolutionize your documentation strategy, figure out how to weave it into your dev process seamlessly, or integrate cutting-edge AI solutions, please reach out. We’re here to guide your team towards unparalleled productivity.

✋ Just joining us? Take a journey from the start with our series on developer productivity killers, beginning with the very first post.

DALL·E 2023 08 24 10.47.12 colored pencil drawing of a software developer wearing a hoodie with the hood down sitting at a desk with a computer looking at code with amanager w

August 24, 2023 In Code, Process, Productivity, Uncategorized

The Micromanagement Menace

Software Developer Productivity Killer #9: Being Micromanaged

Oh, Bob. We’ve seen him weather the storm of unclear requirements, battle the beasts of artificial deadlines, and navigate the treacherous paths of poor branching strategies. But, as he sits at his desk, diligently tapping away at his code, he feels a shadow looming over him. It’s not a faulty server or a nasty bug; it’s something far more foreboding: the ever-watchful eyes of a micromanager.

🔬 Micromanagement: A Creator’s Kryptonite

Software development isn’t just a profession; it’s an art. Coders, like artists, need space to think, to test, to experiment, to create. Imagine for a moment, a world where Shakespeare was questioned at every sonnet line or where Da Vinci was advised on every brushstroke. Absurd, right? Then why do it to developers?

The Trust Deficit: Micromanaging sends a clear message: “I don’t trust you.” If a developer feels distrusted, their motivation tanks faster than a lead balloon. They are professionals, having trained and practiced their craft. They deserve autonomy and trust.
Turned-off Thinking Tanks: By giving developers overly specific instructions, you inadvertently switch off their innovative minds. The end result? Instead of a creatively crafted solution, you get a mundane, to-the-point output, devoid of innovation or flair. And if a single piece of your ultra-specific instructions fails? The domino effect kicks in, leading to bugs, skipped functionalities, and costly reworks.
The Creativity Killer: Micromanagement suffocates the very essence of software development – creativity. Let’s not forget, you hired Bob for his ingenious coding skills, not to be a mere executor of over-detailed directions.

🤔 Are You a Micromanager? Signs You Might Be

You often think, “It’ll be faster if I just do it myself.”
You want to review and approve every minor decision or change.
You spend more time overseeing your developers than strategizing or planning.
You demand constant updates and have an insatiable thirst for progress reports.
You provide overly detailed instructions, often explaining how to do something instead of what needs to be done.

If you’re nodding along to more than a couple of these, it might be time to take a step back. Remember, you hired experts. Trust them to be just that. Remember, Bob thrives when he’s trusted and valued. As a leader, it’s crucial to provide direction, not domination. Embrace the brilliance of your team, and watch them turn your visions into virtual victories.

So, you still don’t get the results you desire without micromanaging? Perhaps it’s not about supervising more closely but improving the dynamics. Either you need to refine your team’s skills or you need to better define your directions and grant them more autonomy.

Need assistance on either front? Whether it’s bringing adept developers to bear or establishing effective communication strategies within your team, Facet Digital can guide the way. Reach out, and let’s keep those developer engines running without any unnecessary hiccups.

August 23, 2023 In Code, Estimation, Process, Productivity, Tech Debt

The Dangers of Unrealistic Deadlines

Software Developer Productivity Killer #8: Arbitrary Deadlines

Ahoy, fellow digital voyagers! As the winds of our virtual journey continue to twist and turn, they bring forth tales of the perilous “unrealistic deadlines.” Just as the sirens of lore ensnared unwitting sailors with their deceptive songs, these ill-conceived timeframes can draw development teams into treacherous waters. Our ever-relatable friend Bob has been through this storm a few times and, suffice it to say, it wasn’t pretty.

😈 Bob’s Date with the Deadline Demon

It was a typical Monday when Bob was slapped with a seemingly simple mandate: “Get this done by Friday, Bob. It shouldn’t be that tough, right?” Attempting to reason and provide a more realistic deadline fell on deaf ears, overshadowed by the constant hum of “we really need it by then.” Bob found himself working late nights, compromising on code quality, and hastily rushing through reviews. All this effort, only to later find out that the deadline had no concrete reason behind it.

🕑 The Deadline Debacle

The Motivation Meltdown: Picture urging a crew to row faster, but there’s no looming storm or sight of a treasure-filled island. It’s like coaxing someone to row harder when there’s no land in sight.
Haste Makes… Technical Debt: Speeding through tasks to meet a deadline often results in cutting corners. Soon, your immaculate ship (or codebase) is leaking all over.
Burnout’s Blazing Trail: Constant urgency isn’t sustainable. It’s a surefire route to burnout, stifling creativity, and waning enthusiasm for future projects.
The Quality Question: Rushing invariably means skimping on important steps. Code reviews get hurried, testing is superficial, and the final output? A shaky product that’s far from shipshape.
Borrowing from Tomorrow: Overworking to meet today’s deadline is akin to taking a loan on future productivity. Just as sacrificing sleep one night necessitates extra rest later, pushing too hard today inevitably slows you down in the subsequent days. What you gain in the short-term, you often pay back with interest in decreased efficiency and stamina.

🗺️ Charting a Better Course

Estimation Exploration: Developers should play a key role in setting the timeline. Incorporate methods like T-shirt sizing, Fibonacci series, or planning poker to allow developers to weigh in on the effort required.
Estimates ≠ Deadlines: This distinction is crucial. Developers often dread giving estimates, primarily because they’re aware that those numbers might be taken as hard deadlines. Remember, estimates are educated guesses—sometimes you might overestimate, other times underestimate. They don’t account for all the unforeseeable challenges that could arise.
The Journey, Not Just the Destination: Concentrate on consistently delivering value rather than sprinting to a hastily determined finish line. A well-considered journey ensures both quality and team morale remain high.
Mutual Respect and Trust: Recognize that developers are experts in their domain. When they suggest adjusting the timeline, it’s based on experience and knowledge. It’s not just about buying time; it’s about delivering excellence.

💡 Conclusion

Deadlines, when used judiciously and not oppressively, can be effective. When they are pulled from the ether without basis, however, they wreak havoc. Bob has learned to voice his concerns, advocate for logical timelines, and champion for developer-centered estimations.

As our digital odyssey with Bob unfolds—from branching strategies to inadequate requirements —a consistent theme emerges: A content and well-managed team is the fastest route to successful project completion.

Could You Use a Guiding Hand in Navigating the Waters of Deadlines and Estimations? Are you inadvertently hampering your developers with unrealistic expectations? Our firm can guide you in establishing an effective, developer-centric estimation process. Such an approach not only uplifts morale but also boosts overall productivity. Get in touch with us to ensure your journey in the realm of software development is smooth and efficient. Set sail for success with us as your trusted compass!

DALL·E 2023 08 22 08.55.01 3D render of an explorer entering a dark thick forest made or twisty passages all alike as an homage to the computer games Adventure and Zork

August 22, 2023 In Code, Process, Productivity

Twisty Branches All Alike

Software Developer Productivity Killer #7: Poor Branching Strategy

Ahoy once more, digital navigators! As our digital expedition continues, we stumble upon the thorny forests of source code management. Amidst the sprawling thicket lies a menacing snare: the poor branching strategy. Oh, how we shudder at the reminiscence of entire days (or, heavens forbid, weeks) lost to merges! The terrain might seem deceptively simple, but as Bob would soon find out, it’s fraught with pitfalls.

😕 Bob’s Branching Blunder

Just as Bob started his morning coffee ritual, he encountered a code review that resembled an epic tome more than a neat summary. Long-lived branches? Multiple changes per branch? Bob’s hopeful morning soon transformed into a caffeine-fueled merge marathon. The ghostly whispers of “merge week” from the dark age of CSV/Subversion haunted his every move.

🌳 The Branching Brouhaha

Epic Merges: Not the cool kind of epic, but the “Where did my day go?” kind. Lengthy branches become burdensome, confusing, and oh-so-error-prone. Nobody is building new code when they are stuck in merge conflict purgatory.
Feature Flags Flop: Poor branching can throw a wrench in your feature flagging game, making it a Herculean task to incrementally release portions of functionality to subsets of your users.
Collision Course: Picture a horde of developers, their code changes clashing like opposing armies. Result? Conflicts galore and a stream of regressions. Somebody is going to end up in the doghouse.
Whimsical Reviews: Branches crammed with countless changes are like thick novels. They’re arduous to review, test, and release. Something will be missed in the noise. Not to mention, they are a nightmare if you need a rollback.

🔦 Lighting the Path with Strategic Branching

Feature First: Feature branches keep things neat and tidy. Each new capability gets its pristine branch, free from muddling modifications. And keep it one feature per branch, please!
Release the Kraken: Release branches serve as staging areas, ensuring that the main branch remains in a perpetually deployable state.
GitHub Flow & Glow: Simplify the process, making it robust yet flexible. Ideal for continuous delivery and integration.
Trunk-Based Triumph: Our golden boy! Implement Trunk-Based Development: Small, frequent merges to the main branch mean fewer conflicts and quicker deployments. CI/CD? More like See-It-Done!
GitFlow, but with Gusto: While intricate, it provides a clear structure for large scale projects, each branch with a defined purpose. Especially for those projects that need to maintain multiple major versions concurrently.

💡 Conclusion

For Bob, adopting a robust branching strategy was like discovering a map in a maze. The days of daunting merge marathons are long gone, replaced by streamlined processes and efficient workflows.

Ready to Navigate the Branching Wilderness? Feeling lost in the dense forest of code branches? Facet Digital is equipped with a compass, map, and the expertise to guide you through. From assessing the thickest tangles to plotting a clear path forward, we’re here to help. Why risk the quagmire when you can journey with the best? Contact us and let’s strategize your branching success story together.

✋ Hungry for more of Bob’s coding conundrums? He’s already braved challenges like the ‘open-plan disturbances’, navigating the ‘technical debt’, sidestepped the ‘dead code’, and rebuffed the ever-multiplying ‘status reports’. And remember that foggy realm of unclear requirements? Yep, he navigated that too. Stay tuned, for the code chronicles are far from over. Each chapter brimming with tales of tech, turmoil, and triumph!

August 21, 2023 In Code, Design, Process, Productivity

The Foggy Realm of Unclear Requirements

Software Developer Productivity Killer #6: Unclear Requirements

Ahoy, tech aficionados! We’ve gallantly crossed the choppy waters of ‘status reports‘ and faced the daunting shadows of ‘dead code‘. As we continue our odyssey through the software development realm, our path suddenly goes dim—enter the fog of unclear requirements. And who doesn’t love a game of software mystery? Spoiler: not our trusty developer, Bob.

🤷‍♂️ The Chronicles of Bob & The Enigmatic Jira Ticket

One day, not unlike others, Bob logs in to find a Jira ticket. “Make it user-friendly,” it demands. Bob, momentarily pondering, wonders if turning it into a virtual teddy bear would suffice. That’s the rub with vague instructions: they leave too much room for wild, sometimes cuddly, guesses.

😕 Downfalls of the Ambiguity Abyss

Brief Wonders: The ever-mystifying 5-word Jira tickets. Yes, brevity can be king, but not when it deposes clarity. It’s akin to gifting someone a book with half its pages torn out. Intriguing, sure, but not particularly helpful.
Too Many Cooks: No need to hand Bob a magnifying glass and tweezers when he’s whipping up a digital feast. Give him the theme and trust his culinary genius. Over-specifying can leave him bogged down in trivialities.
The Missing Link: Overly broad tickets that are essentially black boxes. Like asking Bob to “create a digital companion”. A companion like…a chatbot? A diary? A pixelated parrot?
Hide and Seek with the End-User: As Bob often muses, “If I could just peer into an end-user’s daily dance, I’d craft tools in perfect rhythm!” Shielding developers from end-users is akin to commissioning a portrait blindfolded.

🧭 Steering Clear of the Fog

Big Picture, Big Wins: Developers thrive on the full narrative, not mere snippets. Comprehensive understanding fuels both motivation and innovation.
Bridge the Gap: Advocate for regular interactions between developers and end-users. Direct feedback not only invigorates but sharpens the toolset.
Empower, Don’t Overwhelm: Product Owners should offer a map without dictating each step. Guide, provide context, and then trust in the journey.
Frequent Iterations: Eschew vast tomes of documentation for a sprightlier approach. Swift feedback cycles, agile development, and recurring discussions clear away obscurity. Mind the Agile Manifesto.

Conclusion

Decoding the maze of unclear requirements isn’t for the faint of heart. It’s a ballet of precision and freedom. Bob’s tales remind us that clear directives require more than succinct tickets; they demand context, open channels, and a unified goal.

✋ Missed out on Bob’s earlier tales? From fending off the ‘open-plan disturbances’, navigating the ‘technical debt’, confronting the abyss of ‘dead code’, to wrestling with ‘status report duplicity’, it’s been an epic tale. Stay with us as Bob further charts the highs and lows of software creation, reminding us that well-marked trails ensure no traveler is lost!