I actually liked the article much more than I was expecting to given its opening tone and provocative title.
There is definite truth in the fact that the decision to minimise (as far as is possible) technical debt accrued throughout a project's journey to release should be carefully considered if the actual, "real world", goal of the project is in some way time sensitive.
However I take issue with a number of statements made throughout the article; Namely:
- "With that said, "best practices," however you define it, should be a natural coding standard for any decent developer". In my experience this is simply not true. A lot of tried and tested best practices (SOLID etc...) are not necessarily intuitive at all. How would I, as an unexperienced programmer, have known that the "new" keyword is often a code smell, if someone had not told me?
- "If the client needs a Christmas promotion, and you deliver the best product in the history of promotions -- on December 29th -- it's worthless". This is true. It is also an exercise in reductio ad absurdum. The author chose an example with a hard deadline, which is unusual. Furthermore, to turn that example on its head:
No Christmas promotion is due to arrive on Christmas day.
It might, instead, be due to arrive on December 1st. If
the outcome of releasing the promotion on time would be
worse than if it was delayed by a week (i.e. The project
had major technical flaws), then delaying by a week would
be the correct decision. This is a decision that business
men/women should make in conjunction with engineers. Is
a working promotion on the 7th of December worth more than
a non-functional one on the 1st? Probably.
Mostly, though, I agree with the idea that engineers should be conscious of the broader "why" & "when" of their work, rather than just the "what" & "how". This is often achieved through communication, which should (IMO) be the true takeaway from articles such as this.
EDIT: Obviously being late on a project is never good. This is why contracts should have penalty clauses, which should be factored into the decision I discussed.
There is definite truth in the fact that the decision to minimise (as far as is possible) technical debt accrued throughout a project's journey to release should be carefully considered if the actual, "real world", goal of the project is in some way time sensitive.
However I take issue with a number of statements made throughout the article; Namely:
- "With that said, "best practices," however you define it, should be a natural coding standard for any decent developer". In my experience this is simply not true. A lot of tried and tested best practices (SOLID etc...) are not necessarily intuitive at all. How would I, as an unexperienced programmer, have known that the "new" keyword is often a code smell, if someone had not told me?
- "If the client needs a Christmas promotion, and you deliver the best product in the history of promotions -- on December 29th -- it's worthless". This is true. It is also an exercise in reductio ad absurdum. The author chose an example with a hard deadline, which is unusual. Furthermore, to turn that example on its head:
Mostly, though, I agree with the idea that engineers should be conscious of the broader "why" & "when" of their work, rather than just the "what" & "how". This is often achieved through communication, which should (IMO) be the true takeaway from articles such as this.EDIT: Obviously being late on a project is never good. This is why contracts should have penalty clauses, which should be factored into the decision I discussed.