Steve McConnell hosted a webinar that I think more people need to see.
We actually know a fair bit about how to create high-functioning, effective software development organizations. The knowledge exists but not enough teams are applying it.
So, if your team is struggling in any way or if you are trying to convince your manager to invest in better practices, this talk is well worth watching.
In chapter 3 of Rapid Development, Steve McConnell identified 36 “classic software mistakes.” That book was published in 1996 and a lot has changed since then. So I was happy to learn that he released a white paper that expanded and updated the list.
The new list was validated with a survey of about 500 software professionals. The data gathered from the survey allowed McConnell and rank the list, which makes it much more valuable.
Read on to find out which software development practices are actually the worst “classic software mistakes.”
In this post I want to explore the kind of software maintenance that happens after active maintenance ends. This is the stage of the software life cycle where the software has been in production for some time and the initial wave of bug fixes and enhancement requests ends. It’s also at this point that managers may cut the number of developers assigned to the project and turn their attention elsewhere.
Keeping this kind of project running safely, securely, and profitability as the years tick by–even if you’re not adding or changing functionality–is especially challenging.
I’ve spent more than a decade in this situation. And I’d like share some of my observations and advice about maintaining this kind of software with you.
Despite being all around us, safety-critical software isn’t on the average developer’s radar. But recent failures of safety-critical software systems have brought one of these companies and their software development practices to the attention of the public. I am, of course, referring to Boeing’s two 737 Max crashes, the subsequent grounding of all 737 Max aircraft, and its failed Starliner test flight.
How could such a distinguished company get it so wrong? Weren’t the safety standards and certification process for safety-critical systems supposed to prevent this kind of thing from happening? Where was the FAA when the Max was being certified? These questions raised my curiosity to the point that I decided to discover what this specialized field of software development is all about.
In this post I’m going to share what I learned about safety-critical software development and how a little knowledge of it might be useful to “normal” programmers like you and me.
This mini-sumobot is an advanced-level project programmed in Ada/SPARK and Arduino (C++). This document contains all the instructions you’ll need to build your own High Integrity Sumobot.
This is just a quick post to show you a 30 second video of my sumobot learning to fight…
The Make with Ada Contest is offering $8,000+ in prizes for “cool embedded applications programmed in the Ada and SPARK programming languages.”
I’ve always wanted to build a robot and I’ve been looking for excuses to play around with Ada so I thought this would be a great time to kill two birds with one stone.
Our industry is famous for delivering projects late and over budget. Many projects are cancelled outright and many others never deliver anything near the value we promised our customers. And yet, there is a subset of software development organizations that consistently deliver excellent results. And they’ve known how to do it since the 1970s. In this post I’ll tell you their secret.
This no B.S. guide will tell you what you need to know to survive and thrive as a software developer at my workplace (or just about any workplace).
Congratulations on being hired. You have a lot to learn. It’s not the stuff you think. And you’ve got to learn it fast
We don’t care where you went to school, where you’ve worked, or about any of the things you’ve accomplished. That’s all in the past. You are starting from zero.
Stop me if this sounds like you. Somewhere along the way someone put you in charge of something at your job. Maybe you’re coaching a new hire, maybe you’re a technical lead on a small team, or maybe you’re running a whole project. Regardless of what you’re managing, you need to deal with people and that’s not going quite as well as you had hoped because managing programmers is hard. And it can be hard on your sanity.
(As an Amazon Associate I earn from qualifying purchases.)
Maybe you even picked up a book or two about management in the hopes that you’d find something–some trick or skill–to help you manage your people better. I can tell you from experience that most of those books are crap. But there are a couple of exceptions and in this post I want to give you a summary of one of them: The Coaching Habit: Say Less, Ask More & Change the Way You Lead Forever (paid link) by Michael Bungay Stanier.