I got a ping-back from another blog post written by Jay Wren. He mentioned that his dev team doesn’t have a ‘test culture’ so he has to play a ‘noisemaker’ role when he is challenging bad designs or code.
I read with interest because, to be fair, code review and design review is not usually done by the test team. Functional testing is usually where the test team really digs in, although they have a healthy input in other places.
Designers need to ‘test’ the design, but this is most often done by having the architect create high level designs and having other team members, including other architects, review the design.
This is, far and away, the most important ‘test’ of software, in my opinion, but is too rarely done, especially for code that is written for internal use as most IT systems are.
Frequently, there is no architect available.
Even if there is a senior person available who can play the role of reviewing architect, what process would they follow? I’d suggest that any company in this position investigate the ATAM method from SEI. This is a way of evaluating a design from the standpoint of the tradeoffs that the design accounts for.
Essentially, the concept is: each design must serve the purpose of meeting functional requirements, organizational requirements, and cost/complexity requirements. By reviewing first collecting and prioritizing requirements for reusability, scalability, maintainability, and other ‘abilities’ (called system quality attributes), you can then evaluate the code to decide if it is ‘scalable enough’ or ‘maintainable enough’ to meet the needs.
This allows a realistic review of a system. It takes a lot of the ‘personality conflict’ out of the equation. There is no perfect software system. However, if a system’s design is a good match for the requirements of the organization that creates it, that’s a good start.