Passionate developer in Java and Scala. And sometimes, something else. A few months per year, someone calls me "professor". CoFounder of Scala By The Lagoon @scalagoon
Clean Code emphasizes long-term maintainability over immediate results. And often immediate results are premium: there is no point in long-term maintenance if you can't win the demo next week/impress the VC tomorrow/score the POC next month, and therefore have no long term to talk about.
Add to this low experience, incomplete information, communication issues and you pretty much can explain most projects.
While Clean Code is an important discipline to know and practice (if only to raise the level of what we can write everyday), life is not perfect and does not always value perfect solutions.
On the surface, this is correct. However, "long-term" in my experience starts showing within a month of development.
That is: If you rushed and prioritised immediate results, you will begin to stumble and lose pace within a month.
Not doing clean code/architecture and other practices (like TDD, CI/CD, etc.) from the start is sensible only if a project is estimated to not last longer than a couple of months. That is - if the entire feature set can be completed after a couple of months and there are no new feature requirements after that. Ever.
I have never seen a project like that except prototypes & demos.
For further reading, check out these two articles by Martin Fowler:
Clean Code emphasizes long-term maintainability over immediate results. And often immediate results are premium: there is no point in long-term maintenance if you can't win the demo next week/impress the VC tomorrow/score the POC next month, and therefore have no long term to talk about.
Add to this low experience, incomplete information, communication issues and you pretty much can explain most projects.
While Clean Code is an important discipline to know and practice (if only to raise the level of what we can write everyday), life is not perfect and does not always value perfect solutions.
On the surface, this is correct. However, "long-term" in my experience starts showing within a month of development.
That is: If you rushed and prioritised immediate results, you will begin to stumble and lose pace within a month.
Not doing clean code/architecture and other practices (like TDD, CI/CD, etc.) from the start is sensible only if a project is estimated to not last longer than a couple of months. That is - if the entire feature set can be completed after a couple of months and there are no new feature requirements after that. Ever.
I have never seen a project like that except prototypes & demos.
For further reading, check out these two articles by Martin Fowler:
martinfowler.com/bliki/DesignStami...
martinfowler.com/articles/is-quali...