Most Teams Don't Know How to Create Software 🚧

Hey, developrrrs! 👋 In today’s issue, we’re tackling the elephant in the room: most teams are doing software engineering backwards. We’re diving into why coding should be the last step, not the first, and why your ‘move fast and break things’ mentality is actually making you move slower.

🤿 Deep Dive

Most teams don’t know how to create software. Sure, they can write code – that’s the easy part. But creating software? That’s a different beast entirely.

Here’s a spicy take: Most of the engineering work should happen before you write a single line of code. Yet we’re out here treating coding like it’s the main event when it’s really just the implementation detail. According to the State of Developer Experience 2024 report, 62% of developers experience scope creep with expanding requirements – a clear sign we’re jumping into code before we understand what we’re building.

🏁 The “Just Start Coding” Trap

I’ve been in countless planning meetings where someone says, “Let’s just start building and figure out the details later.” That’s like saying, “Let’s start driving and figure out the destination later.” Spoiler alert: That road leads to Refactor City, population: your team.

I once watched a team dive straight into coding a new service. Six weeks later, they realized they hadn’t considered how it would handle multi-region deployment. Another four weeks of refactoring later, they discovered their data model wouldn’t support a key business requirement. Sound familiar?

The real engineering happens in the planning, the architecture discussions, the requirement gathering, and yes – those design docs everyone loves to hate. When engineers spend weeks on design docs before touching code, they’re not being bureaucratic – they’re being efficient.

The solution? Front-load your engineering efforts:

• Write detailed design docs

• Create architecture diagrams

• Get feedback from other engineers and stakeholders

• Validate your assumptions

• Actually talk to your users (revolutionary, I know)

🐺 The Lone Wolf Feedback Loop

Remember that brilliant solution you came up with in the shower? The one that turned out to be completely wrong once another developer looked at it? Yeah, me too. Building software in isolation is like writing a novel without an editor – technically possible but rarely successful.

Here’s a horror story to drive this home: I once saw a team spend three months building a feature based on what they thought users wanted. Plot twist: They never actually asked the users. The feature launched to crickets. But hey, at least the code was clean, right?

Years ago, I started doing something “radical”: Design reviews before writing code and showing incomplete work to users. Get three or four smart people in a room (or Zoom), present your approach, and watch them poke holes in it. Show mockups and prototypes to stakeholders. Yes, it’s uncomfortable. Yes, it means sometimes admitting you don’t have all the answers upfront. But it’s a lot less painful than rewriting everything after code review or building the wrong thing perfectly.

🗓️ The Planning Paradox

“But planning takes too long!” I hear you cry. Let me blow your mind: Good planning actually saves time. Every hour spent in design prevents days of rework later. Every assumption challenged in a review prevents weeks of refactoring.

One team I worked with spent two full weeks just on design docs and architecture reviews. Management was getting antsy. “Where’s the code?” they asked. But when implementation started, it was like watching a well-oiled machine. No major pivots, no architectural overhauls, just steady progress.

The “Planning Theater” Trap 🎦

But here’s my favorite comedy show: A team gathers for “sprint planning,” which consists entirely of going around the room asking, “So, what are you working on next sprint?” Someone mutters something about a new API, and another mentions a vague bug fix, and voilà – a ticket appears with a title so cryptic it might as well be written in hieroglyphics. No details, no discussions, no feedback. This isn’t sprint planning. This is a glorified to-do list masquerading as Agile development. It’s like planning a wedding by just saying, “Yeah, we’ll have some food and maybe some music,” and calling it done.

Real planning should involve:

• Clear problem statements

• Defined acceptance criteria

• Technical discussion

• Risk assessment

• Resource evaluation

• Dependencies identification

Without these elements, we’re not planning – we’re just scheduling chaos.

💡 The Bottom Line

Creating software isn’t about writing code – it’s about solving problems. The code is just the final expression of that solution. If you’re not doing the majority of your engineering before you write a single line of code, you’re doing it wrong.

Want to start creating software instead of just writing code? Here’s your checklist:

• Spend significant time on design, planning, and validation

• Get feedback before writing code, not after

• Challenge every assumption in design reviews

• Show incomplete work early and often

• Make planning a real process, not just theater

Remember: The best code is the code you never had to write because you solved the problem another way.

Stay deliberate! 🎯

Powered by coffee ☕️ and the shocking realization that coding is the easy part

📊 Stat

56% Increase in Developer Experience Inquiries Signals Growing Industry Focus

Gartner’s 2024 Software Engineering Technology Roadmap reports a 56% increase in expert inquiries on developer experience (DevEx) from 2022 to 2023. This surge reflects a heightened recognition of DevEx as a competitive advantage. Organizations are actively seeking ways to streamline workflows, enhance developer productivity, and reduce friction in software delivery. As a result, investment in DevEx-related tools and practices is rapidly expanding.

💡 Key Insight: The sharp rise in DevEx inquiries highlights that companies now see developer experience as a strategic priority, not just an operational concern.

📌 Essential Reads

🚀 Elevate Developer Experience with Generative AI Capabilities on AWS. This article explores how integrating generative AI tools like Amazon Bedrock can streamline development processes on AWS. It discusses the benefits of AI-driven code reviews, agentic code generation, and code summarization in enhancing productivity and code quality. The piece also emphasizes the importance of demonstrating tangible benefits to gain team acceptance of these tools.

📊 New Atlassian Research Highlights Developer-Leader Disconnect. Atlassian’s recent study reveals that 97% of developers lose significant time due to inefficiencies, with many considering leaving their jobs over poor developer experience. Notably, only 44% of developers believe leaders are aware of these issues, indicating a substantial disconnect. The research underscores the need for better alignment between developers and leadership to improve productivity and retention.

🛠️ Microsoft Introduces Local Emulator for Azure Service Bus. Microsoft has unveiled a local Azure Service Bus emulator, transforming the way developers create and test applications. This tool eliminates cloud dependencies and costs, offering a streamlined development cycle and precise debugging in an isolated environment. Compatible with the latest SDKs, it empowers developers to innovate efficiently while ensuring reliable application communication.

🛠️ Tools

• k9s is a terminal-based UI to interact with Kubernetes clusters, simplifying cluster management with an intuitive and fast interface.

• Gitpod is a cloud-based development environment that enables instant, pre-configured workspaces for any project.

• CommitLint is a tool that ensures commit messages follow your specified conventions, improving codebase consistency and collaboration.