3 ms·

if (today.month != tomorrow.month): send_email()

by russh 9y ago

dvt 9y ago
I think you missed the point. The point isn't to be clever or figure out a way around the ill-suited requirements, the point is to avoid coming up with ill-suited requirements altogether!
- thwarted 9y ago
  Yeah, but this is a bad example of that. It's not that the last day of the month is an ill-suited requirement, it's that, in the example, the programmer who wrote the code for the end of the month did more work and wrote more error prone code than really needed to be. If this was a code review, the end of the month code in this example should get flagged for its complexity, when it can be replaced with the single conditional "if tomorrow.day == 1". It's entirely fine to question the specification/request here, and ask why the end of the month. Not because the code that detects the end of the month can be written in a complex fashion, as it was here. Rather it doesn't seem to meet the requirements: The Account Manager doesn't realize that by processing on the last day of the month, rather than after the last day of the month, is going to miss out on some portion of the last day of "accumulated fees" for the month (depending on the rest of the implementation). The Account Manager has requested an implementation detail that doesn't meet the requirements, and now rework is required.
  - dvt 9y ago
    > If this was a code review, the end of the month code in this example should get flagged for its complexity, when it can be replaced with the single conditional "if tomorrow.day == 1". But it's not a code review. It's a frivolous and simple example to show the underlying impact of not understanding the context of a hypothetical feature request. I have a feeling that in typical engineer fashion, you're missing the forest for the trees. Trust me, I've been there :)
    - someguydave 9y ago
      How does the computer know that today is the first day of the month without already having a complete calender implentation?
    - thwarted 9y ago
      It's a frivolous and simple example to show the underlying impact of not understanding the context of a hypothetical feature request. Yes, it is a contrived example, that's my point. But it's not the programmer that didn't understand the feature request, it's the entire organization. A questionable decision earlier made by the Account Manager led to an overly complex, questionable implementation that will lead to more code and more bugs. Trust me, I've been there.
- ramses0 9y ago
  "The Complicators Gloves" - https://thedailywtf.com/articles/The_Complicator_0x27_s_Gloves https://thedailywtf.com/articles/The_Complicator_0x27_s_Glov...
EliRivers 9y ago
Better come up with a way to calculate tomorrow's date, then. I suppose it'll be today's date, plus one, unless today is the last day of the month. I'll just write a function first to calculate if today is the last day of the month...

if (today.month != tomorrow.month): send_email()

by russh 9y ago

if (today.month != tomorrow.month): send_email()

dvt 9y ago

I think you missed the point. The point isn't to be clever or figure out a way around the ill-suited requirements, the point is to avoid coming up with ill-suited requirements altogether!

thwarted 9y ago
Yeah, but this is a bad example of that. It's not that the last day of the month is an ill-suited requirement, it's that, in the example, the programmer who wrote the code for the end of the month did more work and wrote more error prone code than really needed to be. If this was a code review, the end of the month code in this example should get flagged for its complexity, when it can be replaced with the single conditional "if tomorrow.day == 1". It's entirely fine to question the specification/request here, and ask why the end of the month. Not because the code that detects the end of the month can be written in a complex fashion, as it was here. Rather it doesn't seem to meet the requirements: The Account Manager doesn't realize that by processing on the last day of the month, rather than after the last day of the month, is going to miss out on some portion of the last day of "accumulated fees" for the month (depending on the rest of the implementation). The Account Manager has requested an implementation detail that doesn't meet the requirements, and now rework is required.
- dvt 9y ago
  > If this was a code review, the end of the month code in this example should get flagged for its complexity, when it can be replaced with the single conditional "if tomorrow.day == 1". But it's not a code review. It's a frivolous and simple example to show the underlying impact of not understanding the context of a hypothetical feature request. I have a feeling that in typical engineer fashion, you're missing the forest for the trees. Trust me, I've been there :)
  - someguydave 9y ago
    How does the computer know that today is the first day of the month without already having a complete calender implentation?
  - thwarted 9y ago
    It's a frivolous and simple example to show the underlying impact of not understanding the context of a hypothetical feature request. Yes, it is a contrived example, that's my point. But it's not the programmer that didn't understand the feature request, it's the entire organization. A questionable decision earlier made by the Account Manager led to an overly complex, questionable implementation that will lead to more code and more bugs. Trust me, I've been there.
ramses0 9y ago
"The Complicators Gloves" - https://thedailywtf.com/articles/The_Complicator_0x27_s_Gloves https://thedailywtf.com/articles/The_Complicator_0x27_s_Glov...

EliRivers 9y ago

Better come up with a way to calculate tomorrow's date, then. I suppose it'll be today's date, plus one, unless today is the last day of the month. I'll just write a function first to calculate if today is the last day of the month...