Following are the code quality criteria I came up with and asked the team to rate themselves against it:

This list will only make sense if you’ve read the context from the previous post.

• Conceptual Integrity: Does the design of various components feels seamless? Do you feel the application is build out of random, incongruent components that have just been plumbed together?
  • Do you have odd ball solution smell between various components?
  • Consistent error messages are used throughout the application
  • Navigating from one part of the application to another part feel like one smooth flow.
• Appropriateness: How appropriate is the current choice of technology stack? Are we using the right technology for solving the right problem and are we using the technology appropriately. How well the software is using the supporting framework and underlying building blocks?
  • If its using a RDBMS, is your data really relational data
  • If you are using a framework like Wicket and not really using component based design for webpages
• Understandability: Is the code and the concept behind it easy to understand? Is the purpose of the product clear? Purpose of the product goes further than just a statement of purpose – all of the design must be clear so that it is easily understandable.
  • What do you think of the Code’s Complexity? (Are branch decisions too complex?)
  • Are variable names descriptive and representative of the right entity?
  • How much documentation is required to understand the code and its design?
• User Experience: Do the Users enjoy using the product? It is convenient and practical to use. This is affected by the human-computer interface, but goes far beyond just the GUI.
  • Is the user interface intuitive?
  • Is it easy to perform any operations?
  • Is the complexity of difficult operations hidden away from the user?
  • Does the software give sensible error messages?
  • Do the widgets behave as expected?
  • Is the user interface self-explanatory/self-documenting?
  • Is the user interface responsive or too slow?
• Conciseness: Is there excessive (redundant) information present? In other words, does it follow the DRY (Don’t Repeat Yourself) principle?
  • Code is easy to understand and has optimal amount of code (small well defined classes) and configuration.
  • Does the code have Dead Code Smell (Is all code reachable?)
  • Is any code redundant? Duplicate Code Smell
• Adaptability: Is the code nicely decoupled? Does it have any irreversible design decision? More generic solutions does not necessarily mean more adaptable.
  • Can we use a different database?
  • Can we use a different third party library or framework?
• Consistency: Conceptually and Semantically, is the code uniform? Does it have consistent notation, symbology and terminology within itself?
  • Is one variable name used to represent different physical entities in the program?
  • Are functionally similar arithmetic expressions similarly constructed?
  • Does the code have odd-ball solution smell?
  • Is a consistent scheme for indentation used?
• Maintainability: Does the code facilitate enhancing existing features or adding new features to satisfy new requirements? Are you spending a lot of time fixing bugs on the existing code?
  • Is the design cohesive, i.e. , each module has recognizable functionality?
  • Does the software allow for a change in internal data structures (encapsulation)?
  • Well modularized?
  • Does it have a Solution Sprawl smell?
• Testability: Is it possible to establish automatable acceptance criteria and evaluate its performance? Complex design leads to poor testability.
  • Are complex structures employed in the code?
  • Higher test coverage does not always necessarily mean testable design.
• Reliability: Can it perform its intended functions satisfactorily every single time fast enough? The extent to which a program can be expected to perform its intended function with required precision. This implies a time factor in that a reliable product is expected to perform correctly over a period of time. It also encompasses environmental considerations in that the product is required to perform correctly in whichever conditions it finds itself – this is sometimes termed robustness.
  • Are boundary conditions properly handled?
  • Is exception handling provided?
• Structuredness: Are all the building blocks architected well? Right behavior exists in right places.
  • Is the business logic bleeding into the UI?
  • Is the code tightly coupled and dependent on external sub-systems like type of Database.
• Efficiency: Can it fulfill its purpose without unnecessarily wasting resources? (memory, CPU, external sub-systems, filesystem, etc). A performant application does not necessarily mean that its efficient. For Ex: one might throw a lot of hardware or put a lot of caching to make the app perform better, but may be there was a simpler efficient way. Lots of time, premature optimization leads to less efficient complex solutions.
  • Are we using Connection Pools efficiently?
  • Is your use-case flow logical? (logically inefficient)
• Security: Is the data protected against unauthorized access and does it withstand malicious interference during its operations? Besides presence of appropriate security mechanisms such as authentication, access control and encryption, security also implies reliability in the face of malicious, intelligent and adaptive attackers.
  • Does it allow its operator to enforce security policies?
  • Can the software withstand attacks that must be expected in its intended environment?
  • Is the software free of errors that would make it possible to circumvent its security mechanisms?
  • Does the architecture limit the impact of yet unknown errors?

I always find it very difficult to rate something using an absolute scale. Not sure if this is 1 or 2. Personally I prefer using a relative rating scale. Hence I came up with the following scale for the teams to use while they rate themselves on various criteria.

This entry was posted on Monday, November 17th, 2008 at 8:19 PM and is filed under Agile, Coaching. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.