Good question. I think I need to unpack “code quality” a bit to answer properly. Here’s one definition:
Code Quality = well designed + easy to maintain + well tested + well documented
-
Well designed would apply as much to the user experience as to the underlying architecture, but in general a well designed product works the way a reasonable person would expect, is fast enough, stable, and can handle spikes in demand (within reason).
ClientSpot was written in PHP, using an MVC architecture with a framework called CodeIgniter, so there was good separation of concerns, and it was pretty obvious where to make changes to database calls, user interface, or utility code. So that by itself made things much simpler to explain, and I was able to refer to the CodeIgniter documentation to help the new developer get oriented.
The same would apply to someone now using Ruby/Rails, or Python/Django, or ASP.NET/MVC, or any other combination of modern language and framework.
In terms of buyer questions - everyone was very concerned as to whether the technology was “modern” - meaning would they need to invest in development to bring it up to some expected user standards. This was more around user experience, performance, and whether it looked like a 1990s app. I did 2 UX overhauls over the lifetime of ClientSpot, and that was well worth it in terms of staying up to date (though not cutting edge). By the end, I think the fact that there were slicker UIs coming out from competitors (single-page apps, etc.) started to hurt sales some.
-
Easy to maintain - this one is a bit subjective, but what it means to me is that it was easy FOR ME to maintain. I didn’t have to cringe on every small change or tweak in behavior, or worry that I was probably breaking something. Were there some areas that I was a little uncomfortable with? Yes, absolutely, but those were definitely limited to just a couple of places, and I knew exactly where those were.
The buyer didn’t have any trouble at all as far as I could tell - I didn’t really have to answer any questions at all about how to modify a certain section. So I guess the test is if a reasonable programmer came along behind you, knowing the language and framework, would they be able to make changes without talking to you or breaking everything.
I did have to submit some code samples for buyers to evaluate, so it was important to have something that looked standard and reasonable, with at least a few comments for sections that were not obvious.
-
Well tested - This one is critical, but mainly in terms of how “buggy” the product is. I was obsessive about testing new features and fixing even the slightest bug if it was reported or I noticed it. This really kept customer support down a lot. It’s easy to dismiss minor bugs, but they have a way of multiplying until someone stumbles across one of them every single day. Problems that affect 1% of your customers are really problems that affect you 100% of the time if you have more than 100 customers.
All of the buyers I spoke with were very concerned about the potential customer support burden. I was able to truthfully say that it was very low, and I think that was largely because I squashed bugs whenever they were reported, even when I wasn’t adding new features.
Whether or not you have unit test coverage is a different issue. It’s obviously very helpful for developers, but the goal ultimately is to have a product that isn’t buggy, however you get there. I didn’t have much in the way of unit tests at all, and that never came up as a an issue.
-
Well documented - like I mentioned earlier - leaning on a popular framework for development is a big win here in terms of not doing things in some odd way that requires you to personally explain the code structure. It’s also a good reason not to use the latest bleeding edge technologies - when you are selling, buyers need to know that they can find someone to maintain the code - it’s scarier to contemplate that when it’s an unusual language or a framework that has been abandoned.