The minimal system

My husband and I just spent the end of the afternoon doing our first sprint planning, and we are both thrilled about it. So far, he was working mostly on research, documentation, and the code he wrote was done without planing. The pre-design document (aims and design rules) is almost complete, the next step is to send it to some friends in order to get their feedback, and iterate from there. He also discovered tons of things doing the research, but now it is time start working on the real thing.

In order to kick-off the first sprint, we used an agile method to define the minimal system. The minimal system is the version of our project that has as few features as possible, but complete the whole sequence of the project. In our case, we have a compiler that takes a source file as an input, and output the matching program. Once we have a very basic compiler, we can iterate on it until it is perfect i.e. forever!

Making a compiler is very complex, and in any ambitious project, it can be very hard to know where to start, and how to organize your work. Since we don’t have a lot of experience in the matter of compilers, we will make lots of discoveries along the way, and the earlier we make them, the more effective we become on the long run.

The trick is to divide the project into smaller tasks/features. For high priority features, we aim to have tasks under 16 hours. The smaller the task, the more precise the time estimate. It is much easier to compare a small task to something you have done in the past, than the package as a whole. Task of lower priority are kept as a bigger tasks, to be divided later.

We organised the tasks on two axis, from left to right, it was the chronological order of the feature, the order in which they happen when the program is used. For example, on the right was the the grammar, then the parsing, then the code generation. The second axis is the importance for the system. At the top, the feature that the system cannot exist without, at the bottom, stuff that are optional. The minimal coherent system is the first line at the top.

The first surprise, for both of us, was that the minimal coherent system was much more “minimal” then we though it would be. But at the same time, it is very logical, every task will confirm that the previous one was correct, so it is more effective not to go too deep just in case the following step shows you how you were wrong in the first place.

We have decided on the goal of the first four sprints, and all tasks for the first sprint are defined and evaluated.

  1. A compiler that compiles a function of a single add instruction of int32.
  2. A compiler that compiles a function of multiple add instructions of int32.
  3. Add support for the other basic instructions on an int32
  4. Add support for the if instruction

Alex also realized that a friend was right when he said: “You know, there are lots of boring stuff to do when creating a compiler for your language, it will be very hard at some point to keep your motivation”. He has some amazing innovative ideas, but he has to start with the very basic things before getting there. He calls this project C³0, a very basic compiler, similar to C. But we believe the exercise we just made is a big part in the solution to this problem. With a clear goal, and a clear planning, it is more motivating to see how the little things fits in the bigger scheme of the project, and how much time you are going to spend on such things. Seeing what is coming up is also a very good motivator, I like to put the spotlight on a very interesting task that needs less interesting things to be completed in order to get started.

Working alone is a big challenge, for motivation, to keep the focus on the right things. So we talk about how he could organize his time. He wants to reach the sprint goals, but he wants to keep on reading and learning, he also would like to write more on his blog to get the input from all our fantastic readers! We came up with a list of “rules” to have the good balance of everything.

  • Usual business hours are spent 100% on the current sprint tasks.
  • Reading of books or other documentation not directly related to a sprint task are done on lunch hours, evening or week-end.
  • One post on twitter per day, it can be an update about the project, a joke about programming languages, a picture, a link, anything!
  • One post on the blog per week-end (unless we are out of town).

The exercise went really well, and my husband felt it helped him a lot, figuring out how he will implement his compiler, and setting the objective of the next few weeks. I feel there is a lot of learning ahead, but we are on the right track! Alex is very nervous about this post, it is very open on the fact that all his ideas are on paper and not coded yet, (aside from the spirit prototype parser)… but it is part of the experiment to raise his motivation to a new level!

Leave a Reply

Your email address will not be published. Required fields are marked *