This applies especially to projects that are just starting out.
Recently, I’ve been reading a little on domain driven design and building a small software project. Whenever I add certain specific object structures, it makes it harder to solve the problem. Turns out, I was focusing on building a nice model and project structure, rather than building code that focuses on the domain.
Its easy to just say, “let’s focus on the domain and problem”. But doing it is really difficult and painful. Sometimes, we can’t even identify the problem or perhaps, new problems pop up or the scenario is not what we expected. Its even more difficult when you’re starting out a new project.
Hence, one should try to build structures that can easily be changed. Not modularity or decoupling, but software that is built for change. Modularity allows ease of adding components around a certain formed structure. Software that can be easily change means more than that. It means structures that can be easily broken down and changed as and when the need arises.
Of course, architecture and certain structures should still remain in place to keep things consistent.
Other than that, this also applies strongly to startups and companies. Stop building god damn structures and start focusing on solving problems. (Or at least start pretending that you are solving a problem lol.)