Quick iterations as the secret to progress

So, what is this topic doing in this book? It's a tip to novices and people getting stuck in a project. Sounds familiar? Well, you are not alone and complexity is the enemy.

Premise

At the premise of a project most features and constraints are theoretical and the upcoming result is still a promising playground and place of wishful projections. Then the problems start as we need to manifest fleeting thought. The first choice in software development arises from the platform(s) we are targeting and continues with the tools we choose to cater to the technical needs of our target. Software is easier to remold (refactor) than hardware but design and architectural choices are still locked in and influence capabilities and your future choices and possibilities. It is basically a machine you build, even though it's a virtual machine.

Getting started

Given we would have to dismantle our production line when changing tooling, topics like modularization and good planning come into play. These require a certain level of experience and might create a conundrum to get started when expertise is the thing we actually need. My take on this is fast and plentiful iteration. First think about the problem and maybe even do some scribbles about the flow and logical progression on paper if that helps. Then just use the knowledge and tooling you have and try to build it. There might be problems and certainly many errors along the way and therefor having great feedback on errors (messages, lines etc.) is key. Once an idea works try to modularize it as much as possible as that offers reusability and most important the possibility to replace the module with a better one down the line.

From idea to project

Once, you have your basic modules in place you can start building your project. One thing holding back progress is complexity and if possible you should try to keep that down. At least at the level of interaction between modules. If a module does internally something complex that is fine but try to expose only the needed result to other parts of your application. This also adds the benefit that you only need to test against expected results when isolating an error to a certain module. Also, it offers the possibility to isolate the module from your project for an isolated inspection.

Copies and backups are your safety net

Often you find yourself pilling up one module on top of the next and then fearing to topple it over the higher (or more complex) it gets. This can slow down progress as you might get fearful to add or change something as it might break what already works. If you are not using version control at least use the vast capacity of your hard drive. Make copies of your project before engaging in the next feature and don't shy away from refactoring something as you know you have a safety net made of project copies you can go back to. This gives you the freedom to iterate with different approaches until you get it finally to work according to your expectations and beyond. Often I have multiple solutions for a problem each giving me insights into the benefits and shortcomings of an approach and then I chose one branch to pursue. The unused approaches and ideas remain on my hard drive in storage and might even get reused or refactored for some other projects