How we’ll build it

Notice how we’re already thinking about how to write this program, but only after gathering the what’s and why’s! Software development is much more than simply knowing a programming language and starting to code.

Ways to design software

There are several methodologies when it comes to building software and gathering requirements. In essence, these often come down to two camps: waterfall vs agile.

Waterfall

When approaching software design with a waterfall model, you essentially design the complete system beforehand, in multiple phases. You work out all the details, write detailed plans and documentation, and plan all the work and the phases in advance.

When building a house, this is a good approach to take. After all, you can’t just start building, only to find out at the very end that perhaps you should have built a different foundation. Or that the kitchen should have been put in the back of the house. Changing a house after the fact is more expensive than properly designing it upfront.

Agile

You might argue that the waterfall model can be applied to software design as well. And it can, and it’s being done. E.g., when building a spacecraft, perhaps the waterfall model is a valid approach too. At least NASA thought so! But in more recent history, SpaceX showed us that a more agile approach can give great results too. Sometimes you need to blow up some rockets and rebuild some parts to find out what works well. Similarly, sometimes you need to throw away some software to find out what works.

Because software is not built out of physical material, it lends itself perfectly to a more agile way of working. After all, it’s easy to either change or even throw away your code. In addition, it allows for the client (the user) to change his mind midway and still end up with something useful.

And so, in the past two or three decades or so, a new way of building software became more dominant. This so-called agile methodology is more flexible and often works in iterations. You might start by building a small proof of concept, to see if something is feasible at all. After showing it to a client, you might throw it away and start over. Or you continue building on it in the next iteration and add extra features and functionality.

The core concept is that work is not planned in detail in advance. Which doesn’t mean we should resort to chaos and throw away all types of planning. However, with each iteration, timelines become clearer and the product more mature and finished. The great advantage is that on each iteration, we have a moment to reflect and talk to our client. And on each iteration, we can decide what to do next. We might end up with a different product than initially planned, but more often than not, it will be a product that the client actually wants and needs. After all, it’s super hard to think something through completely, accounting for all the details, all upfront.

If you read about software development and agile vs waterfall models, you’ll read lots of different explanations and opinions. I’m trying to convey the global idea here, and not all the gory details and variations. Just know that there’s a whole world out there thinking about this stuff much more deeply than I ever will. It pays to, at some point, read about this too. Especially if you plan on becoming a professional software developer.

What we’ll do

Although the above mostly applies to large, long-running projects, there’s something we can learn from it that applies on our scale as well. We can either plan our TODO app meticulously at this point, or we can just start coding and see what happens. YOLO, right?! Well not exactly. I’d like to go for something in between.

With the list of requirements and the list of language features we extracted from it, we’ll start super small. We’ll constantly try to keep our code in a working state, by which I mean that we’re able to run it without getting all kinds of errors. We’ll keep adding features and rewriting the code until we have something that satisfies the requirements and is readable and maintainable.

My goal here is to show you how to create software and demonstrate the process of working on something in small iterations, constantly refining it. To help you think on your own, I’ll throw in some small assignments here and there along the way.

Let’s build! This is the fun part of the course, so I really hope you’ll enjoy this as much as I do 🙂