re: What "accepted truth" in software development do you find questionable? VIEW POST


I find that there is an accepted truth that when you ship things "to be fixed up/improved later", that "later" actually means "never".

I think it's a decent mindset to have. Don't expect to find the bandwidth to come back to this TODO later, but in my experience we do come back and fix these issues. It just doesn't happen right away. I think it's good to have the self-awareness that the team will probably move on to other things, but in terms of accepted truths, I find this one isn't always the case.

I've met plenty of folks who genuinely don't have refactoring and cleanup in the vocabulary, and that might be the root cause for this feeling of "later" meaning "never", but if you have the discipline to clean things up, things end up okay.


To me, this sounds more like a project management/culture issue rather than a development issue. Due to any of the following.

  • Extremely difficult testing and approval of changes post-launch. AKA: the waterfall model
  • Customer refuses to pay for maintenance or tweaks, only new features. So management will never allocate time for it.
  • High company turns over (due to other reasons), and lack of issue tracking. So the "todo" is forgotten.

All the reason above has less to do with development and more of project management which the team with discipline can work on.

Unfortunately, one that is all too common in many places. And has somewhat rightfully gained its place as a "truth" or "rule of thumb". Something I hope will improve in time.

  • Its probably also driven by the young developer desire to produce the best code ever, now. Instead of a solution for the user.

Self discipline or good management.

Code of Conduct Report abuse