The software industry has a problem with titles. Walk into most technology companies today, and you’ll find teams of “software engineers” who aren’t practising software engineering. They’re coding, certainly. They’re building features and fixing bugs. But are they engineering?
After a decade of working with diverse clients, from ambitious startups to enterprise organizations, I’ve observed a troubling pattern: the widespread misuse of the “engineer” title in software development. This isn’t just semantic pedantry; it’s a fundamental misunderstanding that’s costing businesses millions in technical debt, failed projects, and missed opportunities.
What Makes an Engineer?
In traditional engineering disciplines, the title “engineer” carries weight. It implies rigorous training, adherence to established practices, professional accountability, and often legal liability for outcomes. Civil engineers don’t just build bridges, they engineer them with careful planning, tested materials, and proven methodologies. If a bridge fails, there’s a clear accountability framework.
Software development, however, operates in a different reality. As Dylan Beattie noted on and early episode of The Modern .NET Show:
One of the challenges around ethics and professional accountability and software engineering is we don’t have the sort of liability chain… in every single computer you’ve got a CPU that might have a Meltdown or Spectre lurking in it… running an operating system where you accept the terms and conditions which say, ‘I promise I will not use this to run life support systems, nuclear reactors, air traffic control, anything that matters.’ And then you are expected to drop your code on top of that and say, ‘yes, I will stake my reputation that this is not gonna crash.’
This lack of accountability has led to a dilution of what we consider “engineering” in software.
The Engineer vs. Developer Distinction
True software engineers demonstrate:
- Systematic approach: They plan before coding, design before implementing
- Quality focus: They write automated tests, create documentation, and follow coding standards
- Professional practices: They use proper version control, conduct code reviews, and refactor proactively
- Continuous learning: They stay current with best practices and emerging technologies
- Problem-solving methodology: They analyze requirements, consider trade-offs, and design scalable solutions
Developers (and there’s nothing wrong with being “just” a developer) might:
- Jump straight into coding without planning
- Write code that works but isn’t maintainable
- Skip documentation and testing
- Ignore established patterns and practices
- Focus on immediate feature delivery over long-term quality
The key differentiator isn’t knowledge, it’s approach and mindset. Emma Burstow captured this perfectly on The Modern .NET Show:
I think that the thing that makes a software engineer is a degree of curiosity. If you’re missing that, you’re not going anywhere. You can come without knowledge, but you’d best come with curiosity.
Red Flags: When Your "Engineers" Aren’t Engineering
If your development team exhibits these behaviors without good reason or explicit approval, they’re not practicing software engineering:
Technical Practices
- No automated testing: Relying solely on manual testing or “hope”
- Absent version control: Not pushing changes to remote repositories, or worse not using Git altogether
- Missing documentation: Code that requires archaeological expeditions to understand
- Code smell tolerance: Intentionally writing or ignoring bad code without remediation plans
- Pattern avoidance: Consistently reinventing solutions instead of applying proven design patterns
Process Issues
- No upfront design: Jumping into implementation without understanding requirements
- Inadequate planning: Starting features without considering dependencies or risks
- Solution shoehorning: Forcing existing solutions into new problems regardless of fit
- Quality shortcuts: Consistently choosing speed over sustainability without strategic justification
The Business Impact
This distinction isn’t academic; it has real business consequences:
Poor Engineering Practices Lead To:
- 40-60% more time spent on bug fixes and maintenance
- 3-5x longer feature development cycles
- Exponential increases in technical debt
- Higher developer turnover due to frustration
- Increased security vulnerabilities
- Reduced ability to pivot or scale
True Engineering Practices Deliver:
- Predictable delivery timelines
- Sustainable development velocity
- Lower long-term maintenance costs
- Higher code quality and reliability
- Faster onboarding of new team members
- Improved security posture
The Path Forward
The solution isn’t to eliminate developer roles; skilled developers are valuable team members. Instead, organizations need to:
Be Honest About Roles
- Use accurate job titles that reflect actual responsibilities
- Distinguish between developers, engineers, and architects
- Set clear expectations for each role level
Invest in Engineering Practices
- Provide training on software engineering fundamentals
- Implement code review processes
- Establish testing standards and automation
- Create documentation requirements
- Invest in proper tooling and infrastructure
Foster Engineering Culture
- Reward quality alongside speed
- Allocate time for refactoring and technical debt reduction
- Encourage experimentation and learning
- Create psychological safety for raising quality concerns
When Engineering Matters Most
Not every project requires full engineering rigour. A quick prototype or proof-of-concept might justify developer-level practices. However, as soon as code enters production, serves customers, or becomes business-critical, engineering practices become essential.
The challenge is that many organizations don’t recognize when they’ve crossed this threshold, continuing with developer practices long after they need engineering discipline.
Conclusion
The software industry’s casual use of the “engineer” title has obscured an important distinction between different approaches to building software. By recognizing and respecting this difference, organizations can make better hiring decisions, set appropriate expectations, and ultimately build more successful products.
Your business deserves true software engineering when the stakes matter. The question is: are you getting it?
Drawing from my experience as a Microsoft MVP and CTO who has worked across industries from Formula 1 performance optimisation to startup scalability challenges, I’ve helped organisations transform their development practices to achieve measurable results. My Developer Experience and Strategic Technology Consultation services have consistently delivered 3-5x productivity improvements through systematic adoption of engineering principles. Reach out using the contact form below, and I’ll be in touch to schedule a free discovery call.