Tag Archives: CI

Where is that Red ‘Stop’ Button in Your Development Process?

Posted on by

If you don’t dare to stop the line, continuous integration might be waste. Here is the second part of my three-part series on building the quality in on the SmartBear blog.

In the first post of this series, I wrote about Toyoda Sakichi, the founder of the Toyota industries, who invented a loom that would automatically stop when a thread broke in the 1920. He thereby also invented the concept of “stop-the-line” to build quality in.

Incremental compile with visual feedback is a small step toward the automaticity of the Sakichi loom. Beyond that, we still have these longish feedback cycles, be it manually running unit tests or waiting on the automatic build or system tests run by our continuous integration (CI) system.

Read the rest of the blog at SmartBear.

Stop the Line – Build Quality In with Incremental Compilation

Posted on by

We in the software industry are still far behind when it comes to automated quality checks. Toyoda Sakichi for example invented the automated loom with stop the line capability almost 100 years ago. I write more about that in my first blog in a three-part series on building the quality in on the SmartBear blog.

It may seem old school, but every now and then I’ll start pristine Emacs and hack away on a piece of Java. I mainly do this for small stuff, since starting or setting up Eclipse takes a little bit too long for such minor projects. Even so, I don’t do this as often as I used to.

Why? I guess you know the answer: Nowadays, even the thought of not having instant feedback on syntactical and semantical correctness makes me shudder. It’s like coding in the dark. Incremental compilation is one of those great innovations that have increased the quality of our work.

Read the rest of the blog at SmartBear.

Encouragement for Continuous Integration pioneers

Posted on by

For all you heroes fighting a daily battles convincing teams, managers, tester, that deploying  software work to production anytime using CI it’s possible, well here is a story that might encourage you. (Thanks to Xavier Allue).

In the 1950’s, a japanese team struggled with a big die press. The die press could not be changed to new conditions fast enough, so they always had to work with big batches in order to make up for lost setup time.  (big software project ring a bell?). The team decided to get that setup time down from double digit to single digit number. It took them years. But – they actually finally made it.

At the time, there was an alternative point of view:

"While these japanese guys like to promote the notion of fast setup
changes, this simply isn’t viable on very large scale activities. For
example, this die press here next to me uses 3-ton dies and takes five
foremen a full day to configure…"

(Some forgotten Detroit engineer, circa 1950)