SIMPLE – A Minimalistic Programming Methodology

The most important answer to this question is about where you should not start: don’t start to code (yet)! Before we start to code, we should make sure to understand something more about the program. The goal is to make sure we have a basic understanding of what the program is supposed to accomplish, but not yet care about how it should accomplish it.

To get a feeling for what the program is trying to accomplish, we mine the specification. This means re-reading it, looking for some particular kind of information. To understand the program’s core behaviour, we pay close attention to the verbs and actions. Using a pen to underline or highlight them is not a bad idea.

For concreteness, I am copying in parts of the specification from above, highlighting as I go.

The simple warehouse program is an for … letter a-z), plus a shelf (an integer).

The simple warehouse program manages a database of wares and supports the following operations:

1. Adding a ware
2. Removing a ware
3. Editing the information about a ware
4. Printing the information for a specific ware
5. Listing all wares in the database
6. Undoing the last action
7. Quitting the program

When starting the program, the user is presented with the main menu with the above alternatives and picks a choice by entering the first letter of each alternative, i.e., A, R, E, P, L, U, or Q.

When choosing to quit, the user is prompted with a yes/no question: …

Looking at the text above, I have a pretty good overview of what the program is supposed to do at a high-level. Of course, this specification is extremely simple by listing the main menu with a lot of actions, but even if it didn’t, picking the actions probably would not be that much harder.

Now, I take a piece of paper and write these things down. A mindmap is usually a good way to capture hierarchical structures.

The mind-map tells me what actions that the program should support, but so-far nothing about how they should be implemented. So far, that’s fine.

This is what we are doing: We are abstracting and compartmentalising. If we tried to understand the entire system before starting to code, we would probably never start to code, because it is very hard to know when you truly understand something. Some people are good at convincing themselves that they “get it”, regardless of whether it is true or not. Others are good at convincing themselves that they don’t. The key is to not get into a situation where this matters. At least not yet.

What we are going to do is the following: we are going to alternate between thinking a little and coding a little. We are going to think just enough so that we understand what is a plausible next step forward. Then we are going to evaluate whether that was a good step or not by coding. This is good, because coding is a good way to understand sloppily formulated ideas. By forcing us to concretise, coding challenges us to understand what it is we understand.

Following the most fundamental principle of SIMPLE, we start with the minimal working program. If we are using C, we would probably write something like this:

#include <stdio.h>

int main(void)
{
  puts("Welcome to my warehouse program!");
  return 0;
}

%23include%20%3Cstdio.h%3E%0A%0Aint%20main%28void%29%0A%7B%0A%20%20puts%28%22Welcome%20to%20my%20warehouse%20program%21%22%29%3B%0A%20%20return%200%3B%0A%7D%0A

This program is pretty much hello world, but it compiles and runs.

Now, we take the actions from the mind-map and turn them into functions. For example, for “add”, we do:

// TODO: implement
void add_action(void)
{
  puts("Add action is not implemented yet");
}

%2F%2F%20TODO%3A%20implement%0Avoid%20add_action%28void%29%0A%7B%0A%20%20puts%28%22Add%20action%20is%20not%20implemented%20yet%22%29%3B%0A%7D%0A

And similar functions for all the other actions. We do this in order to have placeholders for code that we are going to write. Again we want to compartmentalise as much as possible: by focusing on just one small thing at a time, each problem is going to not just seem simple, but be simple. And that is one of the secret sauces to success. (More ingredients are coming up later.)

Between each function you add, compile the program.

We now have a working program that does absolutely nothing. Let’s start adding some functionality to our program following the specification.

The first six action all require either that there is some data in the program, or that we are able to add some data. We haven’t done any data design yet, so if we want to start with these, we should that. However, the last action, quitting, is very simple and does not do much so that is a good starting point.

We now go back to our mind-map and extend the specification of quit.

Re-reading the specification, we now know that triggering quit should enter into a confirmation dialogue, and if the user replies Y, then we quit, if N we return to the main menu, otherwise repeat the question.

To keep the program as simple as possible, we are not going to add functionality for choosing an action in the main menu just yet. That’s not needed, because the only thing we are going to implement is quit. So, although it is futile, let’s extend the program so that when we run it, it asks if we want to quit. To this end, we will add a while loop that loops forever and that in each turn of the loop asks us whether we want to quit. This will allow us to test both the yes and no answers.

#include <stdio.h>

int main(void)
{
  while (true)
    {
      puts("Welcome to my warehouse program!");

      if (quit_action()) break;
    }
  return 0;
}

%23include%20%3Cstdio.h%3E%0A%0Aint%20main%28void%29%0A%7B%0A%20%20while%20%28true%29%0A%20%20%20%20%7B%0A%20%20%20%20%20%20puts%28%22Welcome%20to%20my%20warehouse%20program%21%22%29%3B%0A%0A%20%20%20%20%20%20if%20%28quit_action%28%29%29%20break%3B%0A%20%20%20%20%7D%0A%20%20return%200%3B%0A%7D%0A

Once this edit is done, we compile and run the program. Just to be sure we did not break anything. But oh, it does! quit_action() must first be updated to return a bool. We fix this and add a return false; as the default return and also include stdbool.h at the top of the file.

Moving on, we now have a function quit_action() that looks like this:

// TODO: implement
bool quit_action(void)
{
  puts("Quit action is not implemented yet");
  return false;
}

%2F%2F%20TODO%3A%20implement%0Abool%20quit_action%28void%29%0A%7B%0A%20%20puts%28%22Quit%20action%20is%20not%20implemented%20yet%22%29%3B%0A%20%20return%20false%3B%0A%7D%0A

Our goal now is to implement the behaviour of the specification which was just re-iterated above. We are going to do this in a few small increments. (I will return in a little bit to how to come up with good increments.)

• Print confirmation question
• Read input
• Handle Y case
• Handle N case
• Handle remaining cases

Increment 1 is easy. Just change the existing puts():

// TODO: implement
bool quit_action(void)
{
  puts("Do you want to quit? [Y/N]");
  return false;
}

%2F%2F%20TODO%3A%20implement%0Abool%20quit_action%28void%29%0A%7B%0A%20%20puts%28%22Do%20you%20want%20to%20quit%3F%20%5BY%2FN%5D%22%29%3B%0A%20%20return%20false%3B%0A%7D%0A

Increment 2 is much harder. It requires us to know how to read input from a user in C. This is actually pretty complicated and there are many opportunities for errors. Therefore, I am going to use one of the best programming tricks ever – I am going to “cheat”. By cheating, I mean the following: I am going to assume the existence of a function that solves the problem for me. This makes increment 2 really simple:

// TODO: implement
bool quit_action(void)
{
  puts("Do you want to quit? [Y/N]");
  char input = get_char_input(); // <---- This line was added
  return false;
}

%2F%2F%20TODO%3A%20implement%0Abool%20quit_action%28void%29%0A%7B%0A%20%20puts%28%22Do%20you%20want%20to%20quit%3F%20%5BY%2FN%5D%22%29%3B%0A%20%20char%20input%20%3D%20get_char_input%28%29%3B%20%2F%2F%20%3C----%20This%20line%20was%20added%0A%20%20return%20false%3B%0A%7D%0A

You really need to understand that cheating is one of the best tools in the programming toolbox. You should use it all the time. The first rule of cheating is this:

If you don’t know immediately how to solve a problem, assume the existence of a function that solves this problem for you, and call that function.

This is great because usually when you are programming, you are going somewhere and you have a particular control flow in mind. Getting stuck implementing one step of this flow usually means your train of thought is interrupted and because your mind is now focused on solving the current step, you will have a harder time continuing where you got stuck once you are unstuck.

Like we did with the empty action functions from the start, we add a dummy function to the file called get_char_input() to stay true to the ideal of always having a working program:

// TODO: implement
char get_char_input() // <-- return type derived from the call-site
{
  return 'Y'; // <-- a good default because of how increment 3 is specified
}

%2F%2F%20TODO%3A%20implement%0Achar%20get_char_input%28%29%20%2F%2F%20%3C--%20return%20type%20derived%20from%20the%20call-site%0A%7B%0A%20%20return%20%27Y%27%3B%20%2F%2F%20%3C--%20a%20good%20default%20because%20of%20how%20increment%203%20is%20specified%0A%7D%0A

We can now compile and run our program as a kind of minimal testing.

Back to our increment 3, which is dealing with the base case of the user inputting a Y:

// TODO: implement
bool quit_action(void)
{
  puts("Do you want to quit? [Y/N]");
  char input = get_char_input();
  if (input == 'Y') return true;
  return false;
}

%2F%2F%20TODO%3A%20implement%0Abool%20quit_action%28void%29%0A%7B%0A%20%20puts%28%22Do%20you%20want%20to%20quit%3F%20%5BY%2FN%5D%22%29%3B%0A%20%20char%20input%20%3D%20get_char_input%28%29%3B%0A%20%20if%20%28input%20%3D%3D%20%27Y%27%29%20return%20true%3B%0A%20%20return%20false%3B%0A%7D%0A

Increment 4 is dealing with the case of the user inputting a N. Turns out it is already handled, as the function returns false as a default. This leaves us with increment 5, which is the user replying with something other than Y or N.

The reason why I left this case until now is because this is the case that removes some of the simplicity of the code we have been working on so far: we must now add a loop to this function to be able to repeat the question.

We start by wrapping the entire function inside a while. The exit condition of the while is that input is either Y or N. Otherwise, the specification dictates`, an error message shall be printed and the question shall be asked again indefinitely. Here is a first attempt at doing this:

bool quit_action(void)
{
  while (true)
    {
      puts("Do you want to quit? [Y/N]");
      char input = get_char_input();

      if (input == 'Y') return true;
      if (input == 'N') return false;

      puts("Only Y or N are valid answers!");
    }

  return false;
}

bool%20quit_action%28void%29%0A%7B%0A%20%20while%20%28true%29%0A%20%20%20%20%7B%0A%20%20%20%20%20%20puts%28%22Do%20you%20want%20to%20quit%3F%20%5BY%2FN%5D%22%29%3B%0A%20%20%20%20%20%20char%20input%20%3D%20get_char_input%28%29%3B%0A%0A%20%20%20%20%20%20if%20%28input%20%3D%3D%20%27Y%27%29%20return%20true%3B%0A%20%20%20%20%20%20if%20%28input%20%3D%3D%20%27N%27%29%20return%20false%3B%0A%0A%20%20%20%20%20%20puts%28%22Only%20Y%20or%20N%20are%20valid%20answers%21%22%29%3B%0A%20%20%20%20%7D%0A%0A%20%20return%20false%3B%0A%7D%0A

Note how I insert “paragraph breaks” into the code to capture what belongs together, and to help the reader “breathe”. Asking the question and getting the reply feels like two related concepts. The two checks of the exit conditions are clearly also related. Thus, I group these together by separating them with a paragraph, and also put another paragraph before the error which is the logical conclusion of the function.

Also note that I removed the // TODO: implement comment since the function is now properly implemented, modulo the cheat – the call to the (yet) non-existent function.

The quit_action() function was developed in a series of steps. The choice of the steps was very deliberate. Here are the rules to follow:

If there is any kind of branching, start with the most basic interesting case first

In our example, Y and N are equally basic but only Y leads to something interesting, i.e., exits the program. The non yes or no cases require retrying which is more complicated, so we delay those even further. In the end, the order is Y, N, and “the rest”.

Always finish a straight-line version first

This means that any code that involves loops, you start by focusing on getting one iteration of the loop working in the working program. Once that is done, you can more easily wrap the working code inside a loop. Note that by this rule, the Y case would still be implemented before “the rest” even if Y called some other functions to save the database etc.

Each increment should accomplish something sensible

Each increment should result in a working program.

Each increment should ideally have a testable outcome

For example, when we implemented (skipped…) increment 4, we should also have changed the get_char_input() to return N to test this. And similar for increment 5.

Now: back to the running example.

We have finished quit_action(), but mostly because we cheated. To finish implementing this part of the program, we will now remove the cheat by implementing get_char_input(). However, the reason why we didn’t write this piece of code down immediately from the start was because we thought it was complicated and did not know exactly how to do it. So, how do we proceed now?

Well, we cannot magically suddenly grasp how to read user input. This knowledge generally comes from somewhere. Let’s cover the three most basic cases:

1. Google/Stack Exchange
2. A text book
3. Man pages

Now that we are done with quitting the program, it is time to move on to the next action. However, in order to get to the next action, we must first extend the main loop of the program so that the user can choose between whatever action we choose to implement next, and quitting.

Looking at the specification, the user’s input is again by reading a character. Great that we have already implemented get_char_input() to do exactly that. (If we hadn’t, we could just rely on the existing cheat, but eventually we would have to implement it of course.)

Following the instructions on how to develop in increments, etc. and looking at how we implemented the dialogue in quit_action(), we can relatively quickly write something like this:

#include <stdio.h>

int main(void)
{
  bool should_quit = false;

  while (!should_quit)
    {
      puts("Main menu:");
      puts("[A]dd ware");
      // ... <--- remaining actions, or just omit them for now
      puts("[Q]uit");
      char input = get_char_input();

      // Hmmm ... code formatting?
      if (input == 'A')      { add_action(); }
      else if (input == 'Q') { should_quit = quit_action(); }
      else                   { puts("Invalid choice!"); }
    }
  return 0;
}

%23include%20%3Cstdio.h%3E%0A%0Aint%20main%28void%29%0A%7B%0A%20%20bool%20should_quit%20%3D%20false%3B%0A%0A%20%20while%20%28%21should_quit%29%0A%20%20%20%20%7B%0A%20%20%20%20%20%20puts%28%22Main%20menu%3A%22%29%3B%0A%20%20%20%20%20%20puts%28%22%5BA%5Ddd%20ware%22%29%3B%0A%20%20%20%20%20%20%2F%2F%20...%20%3C---%20remaining%20actions%2C%20or%20just%20omit%20them%20for%20now%0A%20%20%20%20%20%20puts%28%22%5BQ%5Duit%22%29%3B%0A%20%20%20%20%20%20char%20input%20%3D%20get_char_input%28%29%3B%0A%0A%20%20%20%20%20%20%2F%2F%20Hmmm%20...%20code%20formatting%3F%0A%20%20%20%20%20%20if%20%28input%20%3D%3D%20%27A%27%29%20%20%20%20%20%20%7B%20add_action%28%29%3B%20%7D%0A%20%20%20%20%20%20else%20if%20%28input%20%3D%3D%20%27Q%27%29%20%7B%20should_quit%20%3D%20quit_action%28%29%3B%20%7D%0A%20%20%20%20%20%20else%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%7B%20puts%28%22Invalid%20choice%21%22%29%3B%20%7D%0A%20%20%20%20%7D%0A%20%20return%200%3B%0A%7D%0A

Here, I added printing of (part of) the main menu, a call to get_char_input(), and I also changed the code a little to make use of a should_quit() variable to control whether the main loop should continue or not. The reason for this is simply because code with fewer exit points is simpler to understand.

However, looking at this code and the code for quit_action(), I notice that there is a small modicum of repetition. In both cases, I have to handle the failure mode, i.e., when the user presses something that isn’t part of the protocol.

Now refactoring enters into the picture. What I want to do now is to improve the code for get_char_input() so that it can handle the failure for me. A simple way to do that is to pass both the question and the valid alternatives to the get_char_input() function:

char input = get_char_input("Do you want to quit?", "YN");
char input = get_char_input("Choose menu item!", "AREPLUQ");

char%20input%20%3D%20get_char_input%28%22Do%20you%20want%20to%20quit%3F%22%2C%20%22YN%22%29%3B%0Achar%20input%20%3D%20get_char_input%28%22Choose%20menu%20item%21%22%2C%20%22AREPLUQ%22%29%3B%0A

The code for this is almost given in the specification of this assignment, so won’t be repeated here. However, the resulting code for main() is nice. Here rewritten with a switch statement just for fun, and the main menu printed in its own function:

#include <stdio.h>
int main(void)
{
  bool should_quit = false;
  while (!should_quit)
    {
      print_main_menu();
      switch (get_char_input("Choose menu item!", "AREPLUQ"))
        {
        case 'A': add_action();                break;
        case 'R': ...                          break;
        case 'E': ...                          break;
        case 'P': ...                          break;
        case 'L': ...                          break;
        case 'U': ...                          break;
        case 'Q': should_quit = quit_action(); break;
        }
    }
  return 0;
}

%23include%20%3Cstdio.h%3E%0Aint%20main%28void%29%0A%7B%0A%20%20bool%20should_quit%20%3D%20false%3B%0A%20%20while%20%28%21should_quit%29%0A%20%20%20%20%7B%0A%20%20%20%20%20%20print_main_menu%28%29%3B%0A%20%20%20%20%20%20switch%20%28get_char_input%28%22Choose%20menu%20item%21%22%2C%20%22AREPLUQ%22%29%29%0A%20%20%20%20%20%20%20%20%7B%0A%20%20%20%20%20%20%20%20case%20%27A%27%3A%20add_action%28%29%3B%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20break%3B%0A%20%20%20%20%20%20%20%20case%20%27R%27%3A%20...%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20break%3B%0A%20%20%20%20%20%20%20%20case%20%27E%27%3A%20...%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20break%3B%0A%20%20%20%20%20%20%20%20case%20%27P%27%3A%20...%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20break%3B%0A%20%20%20%20%20%20%20%20case%20%27L%27%3A%20...%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20break%3B%0A%20%20%20%20%20%20%20%20case%20%27U%27%3A%20...%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20break%3B%0A%20%20%20%20%20%20%20%20case%20%27Q%27%3A%20should_quit%20%3D%20quit_action%28%29%3B%20break%3B%0A%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%7D%0A%20%20return%200%3B%0A%7D%0A

Now, we can compile and run the program again, and test that it works to trigger add_action(), which will print “Add action is not implemented yet”. Time to implement it!

A good candidate for this is adding a ware, because editing, removing, listing, undoing, etc. all presuppose the existence of some data in the database. Adding something new is often simpler than editing or removing. This means that is a good place to start.

It is now time to go back to the specification again, and read about the add action. We extend our mind-map accordingly:

We have now arrived at a good place to do some data design. In other programs, we might have started with that if there weren’t any functions that did not manipulate any core data for the program. But what do we mean by core data?

Unsurprisingly, perhaps, the program’s core data is the central data for the program. A complicated program might have tons of different kinds of core data, but in our example, we are more lucky. To understand a program’s core data, we simply mine the specification again, this time looking for nouns. Let’s do that now!

Again, for concreteness, I am copying in the specification and highlighting as I go:

Every ware in the warehouse has a name, a description, a storage location, a pricetag, information about the number of items of the particular wares stored in the warehouse, and the cost of each item. A storage location is a section (a single letter a-z), plus a shelf (an integer).

The simple warehouse program manages a database of wares and supports the following operations:

1. Adding a ware
2. Removing a ware
3. Editing the information about a ware
4. Printing the information for a specific ware
5. Listing all wares in the database
6. Undoing the last action
7. Quitting the program

Looking at the highlighted information above, and reading the surrounding text, a pattern emerges. There is a database, which stores wares, that each store name, description, storage location, pricetag, and number of items. There is also a mentioning of action, which makes sense: in order to undo an action, we need to somehow record what the program did just before, and enough information to undo it. We don’t know exactly what this information is yet, but that’s fine. It probably does not make sense to implement undo until there are actions to be undone. (Read more in the aside below.)

The specification gives us a (mostly) very good idea for a data type for ware. Name and description are clearly strings. Price and number of items (which I will be calling amount from now on) are clearly integers. The storage location is less clear, however. Rather that getting stuck on this detail, let’s cheat and assume that there is a type storage_location_t that solves the problem. Now, we can write the type for ware:

struct ware
{
  char *name;
  char *description;
  storage_location_t storage_location;
  int   price;
  int   amount;
};

struct%20ware%0A%7B%0A%20%20char%20%2Aname%3B%0A%20%20char%20%2Adescription%3B%0A%20%20storage_location_t%20storage_location%3B%0A%20%20int%20%20%20price%3B%0A%20%20int%20%20%20amount%3B%0A%7D%3B%0A

By cheating a little, we now have a type ware. However, in the interest of making progress and working in an incremental fashion, we are also going to apply another great simplification trick: dodging.

Getting information from the user at all is a great first step in an incremental development methodology. Once that is done and works, we can start caring about making sure that the information is correct. It is time to dodge.

Dodging means temporarily simplifying the specification. In the current example, a good dodge is to say: for now, I am going to only store string data in wares, and worry about integers and storage locations later. This allows us to use a single function for reading input from the user to complete the entire specification for adding a ware, modulo saving it to the database.

Temporarily, we change to type of ware to this:

struct ware
{
  char *name;
  char *description;
  char *storage_location; // TODO: storage_location_t
  char *price;            // TODO: int
  char *amount;           // TODO: int
};

struct%20ware%0A%7B%0A%20%20char%20%2Aname%3B%0A%20%20char%20%2Adescription%3B%0A%20%20char%20%2Astorage_location%3B%20%2F%2F%20TODO%3A%20storage_location_t%0A%20%20char%20%2Aprice%3B%20%20%20%20%20%20%20%20%20%20%20%20%2F%2F%20TODO%3A%20int%0A%20%20char%20%2Aamount%3B%20%20%20%20%20%20%20%20%20%20%20%2F%2F%20TODO%3A%20int%0A%7D%3B%0A

And then we can make a version of get_char_input(), for example get_string_input(). We will probably also cheat and assume its existence on the first pass through the code. We will also cheat and assume the existence of a add_to_db() function, which does nothing except prints out the obligatory disclaimer of it not yet being implemented.

Here is a list of suitable steps for almost implementing add_action(). Each step notably results in a program that can compile and run, but probably does not do anything useful.

1. Read all the inputs as strings and save them into a ware object, assuming the existance of several functions (This could quite possibly be several increments.): a. get_string_input(), b. print_ware() (to print a ware to the user before answering the save, edit, abort), c. edit_ware(), (for when the user selects edit above) and d. add_to_db().
2. Implement get_string_input().
3. Implement edit_ware().
4. In 1. above, we are writing straight-line code. No loops, and the only branching is the calls to edit_ware() and add_to_db() based on the users input. This means we do not yet implement the case where the user makes an edit, gets a printout and makes the edit again. This support we add in this step.
5. Make price and amount ints in ware and replace the two calls to get_string_input() with calls to an assumed get_int_input().
6. Implement get_int_input().
7. Decide how to do the storage location. And implement that. This is likely several steps given that we cheated on the type for storage location before.

The last thing we will do is to deal with the database – a final piece of the puzzle missing to finish this action.

Choosing the proper database design is of course very important for the program at hand. There are multiple alternatives ranging from simple to hard, for example:

1. A statically sized array of wares
2. A dynamically sized in-memory structure like a list or a tree
3. An external database back-end

There is however one very important realisation at this stage and that is that right now, it does not matter (right now).

The rationale is that we are trying to piece by piece construct a piece of software that fulfils the specification. We are just about to wrap-up the part of the program that will be adding the first item in the database. We don’t have the code to remove items, edit them, etc. So really, we could not care less at this point how the database is designed.

This is a great opportunity to dodge again. This time, we are going to dodge in three discrete steps:

1. The database holds only one single element
2. The database is an array of fixed maximal size
3. Make the final decision once the program’s done otherwise

The first database design will allow implementing everything except adding and removing with multiple wares, and listing multiple wares. The second design will allow us to do all that. The third design will make the program less of a Mickey Mouse program.

Following the first database design, we can now define a struct for the database like so:

struct db
{
  struct ware ware; // TODO: improve later
};

typedef struct db db_t;

struct%20db%0A%7B%0A%20%20struct%20ware%20ware%3B%20%2F%2F%20TODO%3A%20improve%20later%0A%7D%3B%0A%0Atypedef%20struct%20db%20db_t%3B%0A

Now, we can finally finish the implementation of add_action(). To do this, we will go through the program and make a few simple changes:

1. We want to create a db_t value in main.
2. We want to pass a pointer to the db_t value to add_action().
3. We want to pass a pointer to the db_t value to add_to_db().

Now we can implement add_to_db() like so:

void add_to_db(db_t *db, struct ware ware)
{
  db->ware = ware;
}

void%20add_to_db%28db_t%20%2Adb%2C%20struct%20ware%20ware%29%0A%7B%0A%20%20db-%3Eware%20%3D%20ware%3B%0A%7D%0A

And now we are done with add_action().

As we finish more actions and move on to the second database design, we simply update struct db:

#define Max_elements_in_db 128
struct db
{
  struct ware wares[Max_elements_in_db]; // TODO: improve later
  int size;
};

%23define%20Max_elements_in_db%20128%0Astruct%20db%0A%7B%0A%20%20struct%20ware%20wares%5BMax_elements_in_db%5D%3B%20%2F%2F%20TODO%3A%20improve%20later%0A%20%20int%20size%3B%0A%7D%3B%0A

That was easy, and now we can finalise more complex parts of out program. Moreover, if we have isolated the how the database works from the rest of the program correctly, only functions like add_to_db() etc. will have to change as a result:

void add_to_db(db_t *db, struct ware ware)
{
  // Saves ware on the next available index and increase size by 1
  db->wares[db->size++] = ware;
}

void%20add_to_db%28db_t%20%2Adb%2C%20struct%20ware%20ware%29%0A%7B%0A%20%20%2F%2F%20Saves%20ware%20on%20the%20next%20available%20index%20and%20increase%20size%20by%201%0A%20%20db-%3Ewares%5Bdb-%3Esize%2B%2B%5D%20%3D%20ware%3B%0A%7D%0A

Think/code/refactor/remove cheats. Repeat until done. Find a good balance.

Almost all hard problems can be broken down into less-hard subproblems, which in turn can be broken down to even less-hard subsubproblems, etc. After a while of breaking work down into smaller and smaller tasks, the tasks finally become simple, and that is the right time to start solving them. That’s SIMPLE in a nutshell.

As soon as we hit a bump in the road – a problem we don’t know immediately how to solve, or don’t know how to solve well, or just cannot be bothered with solving right now – we keep things simple by cheating and dodging. We reserve ourselves that right by always making clear notes about our cheats and dodges and by promising ourselves that we will set things straight in the future. And by keeping our promises.