Tag Archives: quality

Stop-the-line spoken word performance

Posted on by

Agila Sverige 2012 höll jag min första ignite i form av en Majakovski- och Bob Dylan-inspirerad Spoken World performance om hur vi på Polopoly skapade kvalitet genom extremt fokus på automatiserade tester och en stoppa-bandet-kultur.

Förra veckan fyllde konsultbolaget Adaptiv 5 år och firade genom att låte en utvald skara Agila Sverige-talare reprisera sina alster. Jag fick äran att stå för en liten del av middagsunderhållingen. Här är uppläsningen:

Testbarhet för utvecklare för SweNug

Posted on by

Idag fick jag gästa SweNug och prata om testbarhet för utvecklare. Presentationen finns på Slideshare.

read more »

A bug is just an unwritten test that failed

Posted on by

In the first week of March I attended two Spotify unconferences about Continuous Deliver and Quality (which I also had the pleasure to facilitate). I am amazed on how many we were (people had flown in from a lot of other places), the energy in the room, the quality of the discussions, and the massive number of practical initiatives that where suggested and started.

One reoccurring theme was the importance of a stop-the-line culture and what that actually means. I have to admit I was quite active in those discussion, and also held a short lightning talk about the broken windows syndrome. My this simple formula when it comes to bugs is this:

  • You write tests to create a product without defects
  • When a test fails you fix the underlying problem
  • A bug found outside testing is just an unwritten test that would have failed
  • Failing tests are always fixed
  • Therefore: a zero bug policy is the only thing that works in the long run
  • Otherwise you will suffer the broken windows system
  • Just do it
  • Now

Here’s my slides:

Interview with Peter Antman on software development

Posted on by

In May this year I was interviewed at the SmartBear MeetUI user conference in Stockholm about my background as a journalist, Linux and open source, software development in general and testing more specifically. Here’s a post containing the video and interviews with the other speakers at the conference.

The Solution to Technical Debt

Posted on by

(related article: Good and Bad Technical Debt – and how TDD helps)
(Translations: Russian)

Are you in a software development team, trying to be agile? Next time the team gets together, ask:

How do we feel about the quality of our code?

Everyone rates it on a scale of 1-5, where 5 means “It’s great, I’m proud of it!” and 1 means “Total crap”. Compare. If you see mostly 4s and 5s, and nothing under 3, then never mind the rest of this article.

If you see great variation, like some 5s and some 1s, then you need to explore this. Are the different ratings for different parts of the code? If so, why is the quality so different? Are the different ratings for the same code? If so, what do the different individuals actually mean by quality?

Most likely, however, you will see a bunch of 2s or worse, and very few 4s and 5s. The term for this is Technical Debt, although for the purpose of this article I’ll simply call it Crappy Code.

Congratulations, you have just revealed a serious problem! You have even quantified it. And it took you only a minute. Anyone can do this, you don’t have to be Agile Coach or Scrum Master. Go ahead, make it crystal clear – graph the results on a whiteboard, put it up on the wall. Visualizing a problem is a big step towards solving it!

Don’t worry, you aren’t alone, this is a very common problem. <rant>However, it’s also a very stupid, unnecessary problem so I’m baffled by why it is so common.</rant>

Now you need to ask yourselves some tough questions.

read more »

Stop the line presentation at SmartBear MeetUI

Posted on by

Sisyphus, artistry, cult of quality, weaving, broken windows and all the other stuff you have to care about if you want to build high quality software. Here’s my speech on how we did it at Atex Polopoly, held at the SmartBear MeetUI user conference May 23 2013.

And here’s the slides:

Stop the line song

Posted on by

I ended my talk on the SoapUI user gathering MeetUI singing the stop the line song. Now it has ended up on youtube.

Here’s the text:

I keep a close watch on these tests of mine
I keep my Jenkins open all the time
I see a defect coming down the line
Becuse you’re mine, I stop the line

From Aristotle to Descartes – A Brief History of Quality

Posted on by

What is quality? Why do it energize us so much? Can we measure it? In a new Smartbear blogpost I trace the philosophical history of quality, and what that might mean for us.

Socrates started his quest to find out what knowledge is by taking on the lurking trap of the relativists, Protagoras and Heraclitus. Both meant that the world was in constant flux and that the only thing we could know was the sensations we get through our perceptions, or as Protagoras formulated it: “Man is the measure of all things.”

We recognize this stance from today’s definition of quality in business settings: Quality is the extent to which a product or service meets and/or exceeds a customer’s expectation. Quality is relative to the need of a user and is expressed as the right combination of price and quality. High quality, per se, is not desirable. Man is the measure.

That was not the view of Plato.

Read the rest of the blogpost here

Stop the line as eBook

Posted on by

Here’s the eBook collecting my articles on building the quality in by stoping the line: Stop The Line – Why it’s crucial to include a human touch to your automated processes

Every bug means two problems

Posted on by

Finding a bug in your application actually means you have at least two kinds of problems: symptoms and process issues. To deal with quality in a sustainable way, you have to fix both!

read more »

Always Fix Broken Windows

Posted on by

I keep a close watch on these tests of mine
I keep my Jenkins open all the time
I see a defect coming down the line
Because you’re mine, I stop the line

A zero bug policy is the only valid way to look at quality, just like there should never be any broken windows in your neighbourhood. Here is the third part of my three-part series on building the quality in on the SmartBear blog.

Think of old bicycles in cities. A bike is left tied up on the sidewalk for a while. Someone steals the ringing bell. Left in that shape in the same place for long enough the bike will magically fall apart, as if rotting.

In 1982, the social scientists James Q. Wilson and George L. Kelling formulated a sociological theory from observations like these called “The Broken Windows.” A landscape, they meant, signals the type of social norms prevalent in the local society. A broken window left broken says: “it’s okay to break windows.” A broken bicycle sends the same signal.

Read the rest of the blog at SmartBear.

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.

The Last on Code Review

Posted on by

Code quality. It has been haunting me for so long I forgot when I started to think about it. Do other people think about it? For sure. Do everyone? Certainly not.

I was doing RUP and before that some waterfall process from DoD. Before that I was programming Fortran. Now, what has been my single most important recommendation for reaching code quality?

Peer code review.

But enough. It just struck me how much I do not miss code reviews.

I’ll tell you why and I’ll tell you what is the replacement, because there should be one.

I had completely forgotten about code reviews until I ran into a colleague from the past and suddenly remembered a code review in particular.

It was humiliating. First of all, it was boring to print the code on paper and then spend hours reading it. Secondly, I had to face the fact that a lot of the code was copied but not used. I put a big X across the whole page of dead code. Humiliation became a fact when everyone saw it on the meeting.

It was so boring that despite we were caring about code quality and believed in code review, it was hard to make it happen.

Code review is dead – long live the new code review: pair programming!

There are today two very important practices for code and design quality, one of them is pair programming and the other one is test driven design.

Pair programming is code review because there is somebody looking at the code as you type. If you write code that is either hard to understand or breaks some design rule, it is spotted before you have put down hours into it.

It easier to change something before you get emotionally attached to it.

The old code review also had another downside, the reviewers became attached to the flaws they found. Imagine building up arguments for a position on the design of the code that you think needs to be fixed. You come to the review meeting and the design is already changed. Would you not be tempted to tell everyone what you had found, despite being useless information? I would.

Pair programming is also a setting where two people help each other to solve a problem. A code review is a meeting were a group of people discuss a single persons efforts, the one that was the last to touch the code. I hated it when it was me.

Bye, bye peer code review. Will you rest in peace and not be awaken ever again.