-The DSL can accomodate the improvement in the case of adding new sensors or actuators.
-For instance, if we want to add a new sensor, then it is easy to add new \emph{StoppingExpression}
-in the DSL. In addition, if we want to add a new actuator to the robot, we can just add
-a new action defined in the DSL and implement the use of the action in the program.
+\paragraph{Flexibility}
+The DSL can very easily be improved in the case of adding new sensors or
+actuators. For sensors we can just add clauses in the grammar within the
+\emph{StoppingExpression} that will process the values. For actuators the same
+thing can be done in the \emph{Action} rule. A change in the robot's
+configuration can also be handled very quickly albeit not in the DSL itself. We
+specifically chose not to incorporate the hardware configuration in the DSL to
+keep is a simple as possible and thus less error prone. This means that if the
+hardware configuration changes the underlying library must be changed as well.
+However, due to the modularity of the library this is very easy.
+
+\paragraph{Safety}
+The DSL by design does not generate \emph{safe} code implicitly. A programmer
+can make a program that can destroy the robot very easily. While safety is very
+important it would limit the range of missions a lot if some basic behaviours
+used in the demonstration for safety would be inherently present.
+
+\subsubsection{Development process}
+Booting the bricks takes around a minute to complete. When the robot is
+programmed launching the application takes another 30 seconds followed by
+another 30 seconds waiting on the initialization of the sensors. About once
+every 10 times on high battery and about every other time on low battery the
+ultrasonic sensor fails to initialize. We did not have the time to investigate
+this properly but the fault was hidden somewhere deep in the \emph{LeJOS} code.
+When all sensors were initialized the Bluetooth connection could be commenced
+by pressing a button on both bricks. Connecting via bluetooth has about the
+same error rate as the ultrasonic sensor has and takes about 30 seconds.
+
+This very long start up led to a rough development process with long feedback
+loops. After a long time we and other groups found out that applying power to
+the bricks during the initialization and pairing reduced the error frequency a
+lot.