New answers on old questions using new language features

Question

Times and technologies advance, and, as a consequence, code that was up for review 'years ago' would be done differently using current technology.

Is it OK on Code Review to add answers to old questions that suggest ways to solve those old questions using the new technologies/language features?

A specific example came up: Remove-Last-Comma-Problem

This three-year-old question has now had two new answers given today (here and here). Both answers rely on Java8 Language features which did not exist (and were not even speculated) at the time the question was asked.

Is this OK? If it is, are there any constraints?

Answer 1

Yes, modern suggestions should be allowed on old questions.

Initial authorship of code is only part of the software lifecycle. It is quite possible that code that was posted to Code Review years ago is still alive today, and the author might even be interested in maintaining it up to modern standards. Times change, and unmaintained code can "rot". For example, Y2K was once not much of a concern, MD5 was considered a reasonable hash algorithm to use, and Java's String.substring() used to have different performance characteristics. Having a modern perspective added to the pool of knowledge can only be beneficial.

Furthermore, we can't reasonably prevent modern replies to old questions, unless we delete anachronistic answers or place historical locks on all old questions. As with any answer on Code Review, reviewers contribute advice that they feel is helpful, and the original author can take it or leave it. Anachronism might not be a concern: we don't know the original author's answer-acceptance criteria, and in any case the original author is not the only audience for answers.

Answer 2

I don't see anything wrong with posted answers with new technology on old posts. Times change and what would have been good advice 2 or 3 years ago might not be the best advice to give today. It is also reasonable to assume that OP just might still be maintaining the code and should be alerted to new alternatives.

I think we should be careful about two things when adding new answers to old questions though.

1. It must be an acceptable Code Review answer. Meaning, it must be an actual code review. Neither of the answers referenced give a meaningful review. They offer alternative solutions without any explanation as to why the alternatives are better.
2. Answers providing solutions using new technology should probably disclaim themselves a little bit. "I know that Java 8 wasn't around when you posted this, but I think this new feature [x] would be perfect for this because [reasons]." This answer at least mentioned the new technology, but failed to mention that it is a new technology.

Stack Exchange is built to be a question and answer archive. Part of this paradigm is allowing new information and technologies to be taken into consideration long after the question was originally asked and answered. I would say that not allowing new answers goes against the spirit of Stack Exchange in general.

Answer 3

It Depends!

Is it reasonable to assume that the code could be updated and still work? The answer to this question depends on many factors.

If we're talking about MS SQL Server, stored procedure, functions, views, etc., all reside on the server or operate on the server. When we're talking about databases, they're not typically updated until it is 100% absolutely necessary.

SQL Server 2005 is getting a bit old today and there have been several versions of SQL Server since this version... yet there are tons of SQL Server 2005 servers in use today. Language features added since SQL Server 2005 simply won't work on a SQL Server 2005 server. In a case such as this, the server version should be specified in the question, and answers using language features that won't work on the specified server version should be downvoted at a minimum.

On the other side of this coin however, I'll provide the example of Objective-C and iOS development.

When a new version of iOS comes out, users quickly upgrade to the new version and at a high pace.

As of this posting, over 87% of all iOS devices are running iOS 7.x, and another 10% of users are on version 6.x, leaving fewer than 3% of all iOS users on version 5.x and lower. Another interesting aspect is when you look at the per device breakdown and see that the bulk of iOS 6.x users are on either the iPhone 3GS or the iPod Touch 4G, neither of which is capable of upgrading to iOS 7.x.

iOS apps are always doing one of two things. Either they're constantly updating themselves with new language features introduced by the new version of iOS, or they're not being updated at all. Extraordinarily rare is the iOS developer who is still updating his app, but needs to continue to support devices on iOS 5.x.

As such, an answer posted to an old Objective-C question which suggests new language features is absurdly appropriate because either the asker simply won't care to look at the answer because he's no longer maintaining that code (in which case the answer doesn't hurt), or he IS updating his app still and he is always pushing for it to be as modern as possible.

And in fact, while SQL Server questions should specify what server version they're on, I'd recommend iOS questioners let it be known if they're waiting for iOS 8 (or whatever next version) before their release so that EVEN NEWER features of the language can be suggested!

Answer 4

Is it OK on Code Review to add answers to old questions that suggest ways to solve those old questions using the new technologies/language features?

Absolutely! If there are new ways to kill a zombie, we want to have them here!

The problem with the linked answer isn't that it's using language features that didn't exist when the question was asked; it's that the answer doesn't quite review the OP's code; it's just showing the shiny new way, without much explanation.

Answer 5

I feel a bit differently, for all it is worth. I think killing zombies is great, but I do think Answers should be given in scope of the original Question, as in, review the code with the version that was available at the time the question was asked. I realize this is unpractical in some cases, but I think context should supercede "newest features" of X language.

Answer 6

No

Reviewing code requires understanding the code context. The context in which the code was written is just as important as the code itself. In many instances, the question asker adds to their context, saying things like: I can't use third party libraries, or I know that I am reinventing the wheel, or I am a beginner.

Those context statements indicate the constraints on the review. There is no value in suggesting an improvement that is not useful to the asker. You can challenge those constraints, and say "why can't you use a third-party-lib", etc., but recommending a third party lib when you've been told it is not possible, is.... useless.

The 'landscape' of the language at the time the question was asked is an important part of the context. At the time the question was asked, it was not possible to suggest the features that were only introduced 3 years later. The language features are an implied 'constraint'.

Unlike Stack Overflow, Code Review is not a perpetually maintained reference for current fixes to old problems. Code Review does not have the same concepts of duplicates as SO, and we don't have the same concepts of many things. Similarly, we review the asker's code in the asker's context, not in the context of our convenience.

If we allow people to start updating old questions with new answers that assume a different context, then we should revise a lot of things about Code Review, like duplicate handling, and so on.

Answer 7

I'll have to go with @rolfl's answer instead of @200_success's. While saying 'initial code authorship is only part of the software lifecycle' is a very nice idealism*, code refactoring by current code maintainers of the posted code here can't possibly depend on newer answers to the original question years on. I would imagine that the current code maintainers ought to have posted their own questions, or explored newer and better solutions by themselves in the future.

Very hypothetically speaking, if we have helped someone solve the Y2K problem here (handle YYYY instead of YY), should we allow new answers to solve the Y10K bug (handle YYYYY instead of YYYY) down the road?

Therefore, I think we should naturally let questions 'retire', and if we do come across way-too-helpful answers on ages-old questions suggesting new features that are not available originally, perhaps an edit remarking so should do it.

* - This reminds me of coding for violent psychopaths, but that's another story...