Predictions about AI replacing programmers are popular right now but I’m going to convince you that you don’t need to worry it.
It doesn’t take much critical thinking to see how wrong this idea is so let’s dive in.
Tag: Code Quality (Page 1 of 2)
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.
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.
I’m on a journey to become a better software developer by reducing the number of defects in my code. The Personal Software Process (PSP) is one of the few proven ways to achieve ultra-low defect rates. I did a deep dive on it over the last few months. And in this post I’m going to tell you everything you need to know about PSP.
My survey of the computer science literature suggests there are only two economical ways to achieve extremely low defect rates (< 1 defect per KLOC). The first way is to follow the Personal Software Process (PSP), which was created by Watts S. Humphrey at CMU. The second way is to use languages and tools that make it difficult to introduce errors into your code in the first place and easier to detect errors if you do manage to get some into your code. In this post I’m going to briefly discuss these two options and how I plan to explore them to become a better software developer.
I’m sure you spend a lot of time thinking about how to write better software just like I do. And if you’ve dipped your toes into the waters of unit testing best practices, you will have undoubtedly asked this question at some point: how simple is too simple to test?
So, if you’re reading this it means you’re involved in a software project that’s a steaming mess and you want to explore your options. Don’t be embarrassed. This is a safe place; we’ve all googled “rewrite vs refactor” at some point.
The problem is that our profession is long on opinions and short on evidence for what to do with troubled projects. And the opinions we have are all over the map. So, it’s hard to know what you should believe.
In this post, I’m going simplify things for you and help you navigate the rewrite vs refactor debate.