Code Quality

This past week I went to an internal seminar about code quality. The senior consultant that was presenting made an interesting statement:

The software architect is responsible for the quality of a project.

That got me thinking… Am I? Well maybe I am. A lot of the things I talk and worry about on a project are actually quality indicators according to ISO 9126. Does this also mean I get to decide what the quality level should be? Not really. Let me try to clarify that with an analogy.

Compare the ordering of a custom piece of software to buying a car. What brand of car does the client buy? Since cars have implicit quality levels the selection of a brand tells you something about the quality the client is looking for. Does he buy a Fiat or a Ferrari? The answer of course is: It depends.

If the client only needs to get from A to B then any brand will do so he might just as well buy the cheapest. If he needs to do a endurance race like the 24 hours of Le Mans then it is more important what brand he selects because of those implicit quality levels.

So we need to find out about the needs of the client. Does the software only serve some short lived purpose or will it live for decades? Will it be used by a lot of users or just a few? Will it be used every day or sporadically? Is it ok if the software makes mistakes or should these be prevented at all costs? The answers to those questions give an indication to the kind of quality the client is looking for.

If that was it the world would still be simple and possibly quite unsafe. There are also rules for the minimum quality level a car is allowed to have. Those are mostly baked into law by countries. Renault can only sell cars in the Netherlands if these have at least a minimum level of security features and the government wants that certified by a trusted auditing body (NCAP does that for most Europe countries).

In our companies there are also laws to follow. Our DBAs want stored procedures, no triggers and we must not use the systems stored procedures (the stored procedures starting with sp_ in Microsoft SQL server). Our internal hosting provider tells us that our folder structure should look like this, we have log to the servers event log and must not use more than ye megabytes of memory or we will be shut down. To top it all off there are also other projects and existing systems to take into consideration. Somewhere between all those constraints is where we as software architects make the choices that satisfy all parties.

In order to be effective as a software architect you have to know what all the laws in your company are. You have to know what the client wants. You have to know what all the other projects need. And finally you have to tell everybody participating in the project which choices were made and remind them occasionally so they can keep those choices in mind while building.

Does this make the software architect responsible for the quality in a project? We may not always be responsible for all the constraints in place but we sure are responsible for creating a solution that satisfies all of them.

Leave a Reply