%&pre
\title{Yesterday, my program worked. Today, it does not. Why?}
\date{2016{--}03{-}16}
\begin{document}
\maketitle
\subsubsection*{Summary \& Evidence}
%Summary (as briefly as you can - two or three sentences)
The paper proposes an automatic method of narrowing down the lines of code
responsible for a specific change in behaviour. Besides the method it also
proposes extensions that allow handling of interfering fault-inducing subsets
and inconsistent configurations. It also shows that with a little extra
knowledge about the program the searching time can be decreased significantly.

%Evidence (what evidence is offered to support the claims?)
Evidence of the claims are presented through showing the performance on a real
life case studies of a small size and big size. Besides the real world
applications the properties of the algorithm are proven in an earlier published
report about the algorithm.

\subsubsection*{Strengths \& Weaknesses}
%Strength (what positive basis is there for publishing/reading it?)
The strengths of the paper is that is an easy read. The reader is slowly
introduced into the theoretical framework to later get clear real world
examples showing the capabilities of the algorithms.

%Weaknesses
Weaknesses are that the writer makes assumptions about the data that are not
supported. For example on Page $255$ it states that worst case you need to test
all $2^n$ configurations. But in practise this almost never is the case. Also
he cites almost no related work and assumes by looking at one related paper
that thus is no related work.

\subsubsection*{Evaluation}
%Evaluation (if you were running the conference/journal where it was published,
%would you recommend acceptance?)
The author is very clear about the strengths and weaknesses of the proposed
methods. It even provides a full implementation. I would recommend acceptance,
but possible only after more related work was found.

%Comments on quality of writing
Concerning quality of writing; the paper is an easy read and is a good mix of
formal descriptions and natural language. Also the structure of the paper is
clear and it navigates the reader in a natural order through the materials.
It's not very deeply embedded in the literature, this was already mentioned in
the introduction.

\subsubsection*{Discussion}
%Queries for discussion
\begin{itemize}
	\item Page $255$ states that worst case you need to test all $2^n$
		configurations. But in practise this almost never is the case. Is this
		really almost never the case? This is not obvious since is other fields
		of computer science, such as time complexity the average complexity
		usually is closer to the maximal complexity than to the minimal
		complexity.
	\item Would it be better to research not so much the delta debugging
		algorithm but the heuristics in searching since different clustering
		heuristics give significantly different results.
\end{itemize}
\end{document}
