Don’t break the build.
There is absolutely no question that the build process is a pivot in the software quality process. Build every day, don’t break the build and do a smoke test before releasing the latest version.
This morning, I installed the latest build of an extremely complex network security product from one of our customers and lo and behold, one of the most basic functions did not work (and has not worked for about 3 revisions now apparently). Wrote a love letter to the customer service and QA managers and chided them for sloppy QA.
An article I saw recently, talks about the “confluence of compliance and governance” and the direct link to software quality. If you read Jim McCarthy’s classic – “Dynamics of Software Development” you will remember the chapter called Don’t break the build.
You may be using Linux make, Microsoft nmake or Apache Ant but in all cases, the build expertise of the person running the build is more important than the tool itself. the development team runs a daily build with a build-meister personally responsible for running the construction of a working system from all the components. If the build breaks he doesn’t go home.
It is better to have a non-programmer do the smoke-test before the final release to manufacturing. A person outside the engineering team does not have the blinders or personal interest to ignore basic functionality that gets broken ( not to mention having motivation to one-up the engineers).
Anyhow, maybe there is still hope if the compliance gurus have discovered software quality.
An article I saw recently, talks about the “confluence of compliance and governance” and the direct link to software quality. If you read Jim McCarthy’s classic – “Dynamics of Software Development” you will remember the chapter called Don’t break the build.
You may be using Linux make, Microsoft nmake or Apache Ant but in all cases, the build expertise of the person running the build is more important than the tool itself. the development team runs a daily build with a build-meister personally responsible for running the construction of a working system from all the components. If the build breaks he doesn’t go home.
It is better to have a non-programmer do the smoke-test before the final release to manufacturing. A person outside the engineering team does not have the blinders or personal interest to ignore basic functionality that gets broken ( not to mention having motivation to one-up the engineers).
Anyhow, maybe there is still hope if the compliance gurus have discovered software quality.
