ASP.NET Security Consultant

I'm an author, speaker, and generally a the-way-we've-always-done-it-sucks security guy who specializes in web technologies and ASP.NET.

I'm a bit of a health nut too, having lost 50 pounds in 2019 and 2020. Check out my blog for weight loss tips!

The difference between good code and good software

Published on: 2011-11-27

Most good developers are passionate about finding ways to write better code. This is a good thing, because writing better code (usually) leads to more reliable systems, shorter delivery times, and lower maintenance costs. But unfortunately I've met fewer developers where were just as passionate about writing better software

What's the difference?

The quality of software can (and should) be measured based on adoption, usability, profitability (if applicable), fitness for its purpose, maintainability, etc. All people involved in software, from its users to its owners to its developers all have a stake in the quality of the software. Quality code, on the other hand, is only directly seen by the developers themselves. While quality code is a large component of software maintainability, maintainability itself is only a small component of software quality.

Why do we care?

As mentioned earlier, we have plenty of people within technology who are passionate about improving the way we write code. But since we have relatively few people looking at improving software quality we as an industry are making many of the same mistakes over and over again. 

What do we do about it?

First, we have to admit that there's a problem and that we cannot continue focusing just on code quality. Editing note: more and more technologists are looking at improving the quality ad consistency of delivery and project management is starting to be done by people knowledgeable about software delivery, so improvements are being made. Second, we need more people passionate about improving all aspects of the software development process, not just code quality. Finally, I would hope that business users become less tolerant of problems within technology teams, forcing those who are not thinking holistically to get better anyway.

This article was originally posted here and may have been edited for clarity.