DEV Community

Discussion on: What "accepted truth" in software development do you find questionable?

Collapse
 
ben profile image
Ben Halpern

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.

Collapse
 
anpos231 profile image
anpos231 • Edited

Self discipline or good management.

Collapse
 
picocreator profile image
Eugene Cheah • Edited

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.