- It should solve a problem and thus it must be valuable to its users. In short, it should do what it must do and simply work.
- It should be very easy to change. Every piece of code is subject to change, so it should be darn easy to alter its behavior without complete rewrites. Some piece of software that is difficult to change should be fixed, even though it works correctly.
- It should unmistakably communicate its intent to the developers who need to maintain it. If this is not the case, then it should be fixed, even though it works correctly.
Most software I’ve seen throughout my career as a developer only satisfies the first category. Heck, I’ve even seen a lot of code that doesn’t even has any of these qualities.
The second item is something that almost every business implicitly demands, but that is also never added to the requirements.
As for the the third quality, most developers think that its all about writing code but they are wrong. Its all about reading the code. This is why I believe in fluent interfaces and DSL’s (and by DSL, I mean the one-and-only language DSL and not the inferior graphical DSL as popularized by Microsoft).
Are there some additional qualities that I missed?
there is one quality that i’d add to the list:
it should be easy to test
code that is easy to test is often easy to change, and should ‘work’. However, code that is easy to change and that works is not always easy to test 🙂
Agreed, but I actually implicitly applied that by the second point. Code that is easy to change, in my view, also has a good ecosystem around it (CI, unit tests, acceptance tests, code analysis, etc. …) Without this implicit thinking, its true that something that is easy to change doesn’t necessarily need be easy test.
true, but when it comes to the presence of tests, i’d rather be as explicit as possible 😉
Nice post