If you’ve ever been asked, “How long will this take?” and immediately felt a wave of dread, you’re not alone. Estimating software projects—or any complex endeavor—is notoriously difficult. The reason? A concept called The Cone of Uncertainty.
Ask any seasoned developer about essential programming books, and Code Complete by Steve McConnell will likely be on the list. It’s one of the most comprehensive guides to software construction, covering everything from code structure to debugging, with a focus on building high-quality, maintainable software.
In software development, it’s easy to get lost in the weeds—endless debates over tooling, methodologies, and frameworks. But at its core, software development is an investment, and like any investment, it should be judged by its return.
Motivation in software engineering, development, and architecture isn’t just about salaries, bonuses, or deadlines. The most engaged and high-performing engineers, architects, and teams thrive in environments that support autonomy, mastery, and purpose—three key principles that drive long-term motivation and satisfaction. These ideas, popularised by Dan Pink in Drive, are particularly relevant to how different roles function and how project approaches impact motivation.
Good documentation isn’t about writing endless pages of text. It’s about capturing the right information so developers can understand, maintain, and extend a system without reverse-engineering everything from the code.
Embedded systems often have a long lifespan, with software that must be maintained, debugged, or modified years—sometimes decades—after its original release. Writing code that’s easy to understand, modify, and test isn’t just a luxury; it’s a necessity.
There’s a popular mantra among developers: “Good code documents itself!” It sounds nice, doesn’t it? A world where code is so clean, structured, and intuitive that it magically explains itself.
MISRA C compliance is a crucial aspect of writing safe, reliable, and maintainable embedded software. If you've worked on an embedded system, you've likely encountered a long list of MISRA violations flagged by your static analysis tool. The temptation? Quick fixes—add a cast, suppress a warning, tweak a few lines—just to make the report look "cleaner."
At some point, most teams have had this experience. A new developer joins, or an architect wants to understand what a system actually does. Someone tells them: "Just look in Jira."
Tom DeMarco’s Why Does Software Cost So Much? is a collection of essays on one of the most misunderstood parts of software development. Why it’s expensive, why it’s often late, and why throwing more people at the problem rarely helps.