Let's assume something can be called "Waterfall", there's a spectrum on the other side from "Agile": A) The less you know about something in advance, you want

Let's assume something can be called "Waterfall", there's a spectrum on the other side from "Agile": A) The less you know about something in advance, you want to iterate in small increments in order to learn&fail fast, pivot and have many small gains and something to show early (Agile). B) The more you know about something in advance (ie. re-implement Z on platform Y instead of X), you want more up-front design and re-use of already established patterns. Since the end result is mostly already known, you don't want to waste time&energy hunting down clever solutions, but spend shorter time on pure implementation. For a typical golang project you have some idea of scope, or purely convention/convenience, you could decide to setup according to minimal structure. Even though we know java-programmers will want to implement their "architecture" on the project filesystem-level, we don't have to go all the way to the other end of the spectrum either. A plain main.go file would require more refactoring, but hold the most promise in terms of freedom, innovation and creative input. But the Go-community have started to follow some minimal conventions already, so as to rein in the worst and unnecessary cases of divergence.