World class Software
Institutions such as banks have a client lifetime measured in decades so the idea that software should be robust and reliable is taken for granted. The reality is however, that the software produced in companies that really ought to be irreproachable is often somewhat less than mediochre and that the attention to code quality is less that one would assume.
My rules for world-class software are simple:
#1 All code must be documented with inline comments and white-papers that describe the motivation behind the implementation. When this is in place the superhero programmer cannot die in a skiing accident or be headhunted by the company up the road and leave the development team wondering how the code works.
#2 All code must be tested. Unit testing, black-box testing and white-box testing ensure that the software performs as intended. All three types of testing are needed because none of the individual techniques cover all of the usage scenarios. Testing is a serious business so, rather than leave testing to novice programmers, companies should hire the most expert and devious code-killers possible to test the software. These people are few and far between and should be paid a lot!
#3 Software factories that do continuous build and test are essential. Without these, mistakes in the build can go unseen for days, weeks or months, depending on the release cycle of the application.
#4 Source-control rules must be draconian. Developers must not be allowed access to the same file at the same time. If they need to then you probably have the situation of more than one class in a file. This is totally unacceptable. Checking in of a file that breaks the build should be accompanied by public ridicule in stand-up, daily or weekly meetings. A great thing to do is to have people wear a stupid hat if they break the continuous build.
#5 Code should be monitored on a daily basis. Companies I advise often have code metric analysis tied into the daily builds so that it is easy to see whether a class has become bloated with too many methods, methods are more than a certain number of lines, cyclomatic complexity is too deep or there aren't enough comment lines in the code.
My rules for world-class software are simple:
#1 All code must be documented with inline comments and white-papers that describe the motivation behind the implementation. When this is in place the superhero programmer cannot die in a skiing accident or be headhunted by the company up the road and leave the development team wondering how the code works.
#2 All code must be tested. Unit testing, black-box testing and white-box testing ensure that the software performs as intended. All three types of testing are needed because none of the individual techniques cover all of the usage scenarios. Testing is a serious business so, rather than leave testing to novice programmers, companies should hire the most expert and devious code-killers possible to test the software. These people are few and far between and should be paid a lot!
#3 Software factories that do continuous build and test are essential. Without these, mistakes in the build can go unseen for days, weeks or months, depending on the release cycle of the application.
#4 Source-control rules must be draconian. Developers must not be allowed access to the same file at the same time. If they need to then you probably have the situation of more than one class in a file. This is totally unacceptable. Checking in of a file that breaks the build should be accompanied by public ridicule in stand-up, daily or weekly meetings. A great thing to do is to have people wear a stupid hat if they break the continuous build.
#5 Code should be monitored on a daily basis. Companies I advise often have code metric analysis tied into the daily builds so that it is easy to see whether a class has become bloated with too many methods, methods are more than a certain number of lines, cyclomatic complexity is too deep or there aren't enough comment lines in the code.