-\subsubsection{Discussion}
-%development process, use of dsl/technologies, general lessons
-From our experience, the most important think in the development process was to
-start working from a small functionality and to test it. As soon as we knew
-something wrong with the program we can fix and test it again in order to ensure
-the functionality worked. This would be good for the development of the next
-functionality. The difficulty in the development was in the testing phase. The
-reason was sometimes we got an error when running the program in the robot (for
-example: sensor exception) and it took so much time for loading all sensors to be
-ready for testing. Moreover, there was a time when the robot was crashed and needed
-to be restarted which took some time from the development time.
\ No newline at end of file
+\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}
+\paragraph{Feedback loop}
+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.
+
+\paragraph{Techniques}
+Using the combination of all tools such as DSL, XText, XTend and eclipse went
+surprisingly well. In the beginning there were some technical difficulties
+setting everything up and there was quite some overhead since the tools
+required a lot of computing power. But when everything was set up correctly it
+worked like a charm.
+
+Creating our solution was a bit difficult at the beginning due to extra works
+designing the DSL to accomodate the robot's missions and behaviours. However
+when the DSL was created appropriately the generation of different missions and
+behaviours for the robot became very easy.
+
+\paragraph{General lessons learned}
+From our experience, the most important thing in the development process was to
+work iteratively in small building blocks. Another lesson learned was the fact
+that robots are not always reliable and can behave in unexpected ways.
+
+Another lesson learned was that plans mostly take longer than expected. Our
+planning was very generous but still we did not have time to implement some
+extra functionality. If we would have more time we would have tried to make the
+robots autonomous in start up. The current robot needs to have a button pressed
+when the bricks can pair. We have experimented with autonomous pairing but we
+never got it stable but with more time we could make it stable. Another option
+is to try to get more requirements. For example the mapping and internal
+representation of the locations of the lakes. This problem is not trivial at
+all and because of the lack of time we could unfortunately not spend time on
+it.