You never needed to memorize. Push toward a position you're comfortable with, especially if you happen to know your opponent prefers a different type of position. An open player can f2f4 in a complicated position which can be very jarring and put the opponent into time trouble simply because he wants to figure out what you think you see. Or g2g3 and locked pawns can frustrate the hell out of an open player. At my absolute best I was 1800, and I memorized very very little. You're no Fischer and I'm no Capablanca so theory at the B-A levels doesn't mean anywhere near as much as positional awareness.

The #1 reason to refactor is to make code testable. The standard recipe is dependency injection with an IOC container, resulting in no live constructor calls, no dependency issues when a constructor changes, and decoupled dependencies. It's not a magic bullet but it's a big step in the right direction. Interestingly, testable code can have no tests and still be higher quality as a result.

From : http://news.lenovo.com/article...

LENOVO STATEMENT ON SUPERFISH
Superfish was previously included on some consumer notebook products shipped in a short window between September and December to help customers potentially discover interesting products while shopping. However, user feedback was not positive, and we responded quickly and decisively:

        Superfish has completely disabled server side interactions (since January) on all Lenovo products so that the product is no longer active. This disables Superfish for all products in market.
        Lenovo stopped preloading the software in January.
        We will not preload this software in the future.

Once a month I submit my timesheets, so I'll see about 22 lines with a default option side by side with an ad hoc option. I click each of them in turn, see spinners, and see an error if any don't go through.There's nothing you can say that involves no javascript or a change in behavior that could possibly make this a better experience. An absolute minimum of clicks and an absolute minimum of time.

Did you mean ads? I'm as OSS as you'll find. No crapware, nothing but trying to make the world a bit better using software.

I write performant web applications using SOLID methodology, leveraging OSS contributions. I use bundling and minification with in most cases a rather miniscule async javascript footprint pulled from CDNs with fallback. There's simply no such thing as a performant SOLID web application without javascript, and saying that there is in a trivial sense doesn't make it true in a real sense.

On a 3g connection in a grocery store on a hand-held, you're not going to get great response. The crappy connection scenario was the whole underpinning of my OP. Plus, it's a terrible UX if you have multiple pages on a small device to have to find the bottom -- or, shudder, display fewer items to keep some anachronistic submit button visible. It's as easy to deliver a crappy UX today as it ever was. No way hose A.

newbie? Mate, I provided input into the original C++ ANSI ratification. I used to write C because that was the available choice.

Two clicks where one suffices? That's a reduced UX. Trust me, I have no qualm about losing the 1% of my audience that your like represents. There's simply no upside to the likes of you using my software.

Snob? Maybe but I've made significant contributions to a few blue chip software concerns in AU and I never once heard a UX guy say adding an extra click to make the luddites happy was okay. In fact, the luddites never came up. Not once.

A structured web app will use something like AngularJs to bind that click to a controller method, separating layout from logic. To have any level of quality in the code delivering a web app, even a 'simple' one, you're going to have to use an html5 browser with javascript enabled. If you prefer not to, I prefer you not use my apps because I'll be damned if I'm going back to the days of slow-loading pages glued together. Even my personal shopping list app which is a glorified simplification of the standard todo app, uses ajax to provide a responsive experience. When I select 20 items to be removed, I don't have to wait for 20 page reloads on a slow connection. 20 async remove requests spin up and the entire job is done in about a second. Go back to the old days? Hell no.

And to expand on this, in a design-dead module, you will too often find indirect dependencies on side effects, as well as "Hail Mary" calls via hooks into completely unrelated modules that can be devilish to decouple. You also have to consider how widely used a module is. 100+ usages of a design dead module will blow a simple time-boxed DI approach out of the water, resulting as I said in having to schedule it as a formal work item. Decoupling is easy, except for the times it's not.

MAKE IT TESTABLE implies mocks as the first course of action, but even in Java this isn't always possible, and in C++ it's significantly harder.

First off, 220k lines of source isn't that big.

You're not going to solve this with a big bang so get that idea out of your head. You're going to solve it gradually, and for a code base of that size it's going to take maybe a year of relatively slow improvement. Everyone on the team has to be on board, and every code review must include "What has been improved?" and "Did anything get worse? If so, that's not okay."

1) Pick your battles. The code you're not changing is code that doesn't need to be looked at. Address your pain points as they come up.
2) When you find a pain point while making a change, MAKE IT TESTABLE. Since you're in here making a usually simple fix, a single nominal test verifying that fix is fine. Testing anything else is a waste of time. Testable code will improve over time.
3) If you can't make code testable because of an intractable dependency graph, welcome to the hell of "Design Dead". The only way out of this scenario is a rewrite of that area.
4) Find your comfort level with regard to time boxing refactoring work. On my engagements, they just happen automatically, without explanation outside the team, nor apology to anyone. When estimating a piece of work, pad it with some extra time for cleanup. Only actually create work items for design dead areas. Your definition of done must include testable, tested and improved code.
5) Duplicate code in itself isn't evil, and inconsistencies are simply inevitable. If you find duplicate code, pick one and deprecate the rest. However, code that is tightly coupled to the deprecated code will need to be refactored and if the coupling traverses an extended dependency graph, you'll simply have to live with the duplication and just stop adding to it.

Outside the window near me I can see the Lyndt store in Sydney that just yesterday has started to be repaired from the hostage killing by a nutjob. In crowded places, near infrastructure, IEDs (whether E means Educational, Entertaining or Explosive) are no longer an option. I'm certain the residents of Boston and Atlanta largely agree.

The needs of the many outweigh the needs of the few. Or the one.

Christ I wish I had points I haven't laughed this hard in far too long.

The crusades are returning, and every attack hardens our defenses. In the end, AK-47s and RPGs are no match for a thousand years of military advances while they neuter themselves with infighting.