Program quality and code quality
Good programs are clear and readable. They are easy to extend, get along well with other programs, and work with them will not be your nightmare. The quality of the code is not negotiable. It has to be high, and that’s it. When considering it, no excuses like a bad mood of the coder or too tight deadlines are acceptable (those deadlines!).
One of the most important points in software development is to design a program in such a way that it is easy to maintain and modify in the future. Today, almost all software is modifiable and often this process takes place even without the user’s input or requires nothing more than “the update to your program has arrived, click OK or Postpone”. Of course, users have the right to demand new features from applications (especially when it comes to long-running corporate software written in Java or online games that can be played for years).
The piece of code itself can hardly be called useful. Useful software functions begin where disparate chunks of applications interact with each other, exchange data, and work together to do the job of presenting data and interfaces to users.
Programs should be designed with these points in mind! What messages do they receive? What events do they monitor? How do they authenticate and authorize?
Another equally important sign of a good program is the understandability of the code, not the number of tests passed by the application or even good test coverage. Seemingly simple questions: “Can anyone but me understand my code?”, “Will I, having written this code today, be able to understand it in a few weeks?”.
A popular quote about the two most difficult things in programming reads:
“There are only two really hard things: cache handicapping and naming entities.”
Phil Carlton
Code readability is much more important than is commonly thought. Unfortunately, it’s impossible to define exact metrics or parameters for code clarity. Memorizing generally accepted language norms, good software models, and development practices can help in part. But usually this is not enough. Real professionals with time and experience develop a “sense of clarity”, something akin to intuition. The writing metaphor works well here: knowing a lot of words won’t help you write short and clear in meaning.
“I would have written shorter, but I didn’t have time.”
Mark Twain
The ability to fix bugs quickly and easily is a key sign of good software. Bugs in a program should send clear messages and be centrally logged for tracking. When a new bug is reported, whoever is going to fix it should be able to debug it. He needs to be able to connect to the system easily, to access runtime information at any time, and to be able to easily check the functionality of any part of the system.
