I've gradually become convinced of just the opposite: a good developer doesn't think ahead at all. The best way to prepare for the evolution of business needs isn't to add extension hooks in the middle of your code, it's to keep the code as simple as possible so that you can change it in a very direct way as and when you need to.

For instance, putting related code into a data structure allows you to add more to it later without replumbing the whole system (as opposed to functions with five arguments).

With enough experience with refactoring, just choosing a structure that’s easy to refactor can serve as an extension point. (I have even tricked people into implementing a feature the way I had it in my head by writing the intermediate version in such a way to suggest a simple change for part 2.)

Try to make sure that reasonable extensions are cheap to add, and that even some of the more unreasonable ones are at least possible without complete system redesign.

This should not significantly impact either implementation time, or design time. But it will almost certainly make you avoid some really bad design choices that make quite plausible changes extremely expensive.

Good design is more about avoiding obvious traps than finding a path to nirvana.

I do a lot of data mining, and the first step is always securing the data source and archiving it. There have been times where I wasn't able to revisit the project and finish the actual parser of the data for 5-6 months, at which point I can run through the old data. Other times, I'll write the parser but we'll only be parsing a subset of the data we acqiured. The additional unparsed portionisn't necessarily without merit, it's just not something we are dealing with yet (either because it's still of an unknown quality, or requires more effort than we want to spend at that moment). Knowing it's there and that it may need to be parsed in the future can subtly affect your design such that you leave yourself the openings you'll later need to easily parse this additional data. Sometimes that's as simple as just avoiding situations that would make it extremely cumbersome later, and not necessarily actively making it easier.

I'm not sure ignoring something as obvious as this makes one a good developer, but what's "obvious" and what isn't is actually quite different at different software engineering experience levels.

Ignoring cost of change can be absolutely devastating in the long run, but believing you can somehow scry the future for all possible extension points necessary is equally so.

Designing for (anticipated) change in my mind is not at all about adding hooks, API's, or any code at all for that matter.

I think of it more like making sure your system respect analogues to gravity and the other natural laws as best translated into the more abstract relations relevant for the particular kind of system you are building.

One could call it programmer and refactoring friendly design and not miss the target by much.

I'm leaning towards the coffee explanation, but multiple negative (or negative connotating) words probably didn't help...

In the clear light of day, that comment was just me vomiting words onto the forum in the vain attempt to justify the effort I put into grokking that comment. :/

Sometimes the object approach gets a bit silly. Organisation by the first parameter being special doesn't always work too well. For example, GAMS is a better classification for math than simply putting all vector or matrix code in the one classification. Curation is hard at the end of the day.

Would "releases" cause major brick-shitting (like the instance where Mr. L deployed a problematic release)?

We did have one rather insidious error where the risk was too strong and preventing some orders going out. It took us a few months to track it down as it was making the system feel clumsy but it was still working. We assumed the market had changed a bit. Cost us a few million and it was a mistake from our best software dev. It didn't change the fact he was our best software dev (he's at Google now). Lesson learnt was to check for the positives and not just the errors.

We introduced a number of risk check evolutions. A separately developed shim was the final check on orders to make sure that regardless of risk the order made sense, e.g. not a zero price. This code was structured to be as independent as possible from code in the main system. That saved our butt a few times. Adding timing throttles was also important to prevent the system reacting in a way that would send a silly number of orders per sec. We also evolved to giving the broker html web pages where they could view the risk in real time and control risk if necessary. This often included integration with broker risk systems and taking their risk files and integrating the constraints to our engines.

At a later firm, we had automated test systems that also ran performance tests with hardware like that which Metamako now provides. The unit tests on code check-in would run not only the unit tests but there was a suite of performance tests where each would reconfigure the network and run things with external performance measurement on the network. This would allow us to track performance bumps of tens of nanoseconds to specific code deltas. Very useful indeed. A slightly customised version of graphite allowed us to see the chart of the performance of all components and tests over time.

Further to this, we evolved to a specific kernel, OS, and bios settings being replicated so that we could reproduce exactly a production system and vice versa. Tuned BIOS and Linux kernels became important.

The risk controls, unit and systems tests are probably the most important things an HFT does. YOLO is very true.

Production was getting a branch to pass unit and system tests locally. Then run in an acceptance test environment against the official test exchange. Test exchange wasn't always totally realistic. You'd typically have to mirror some captured production traffic to make it somewhat realistic. Also, some exchanges had slightly different production versus test versions. Trapped us once with some spaces being insignificant in Canada in the spec and the official test exchange but not allowed in production. Uggh. No real way to test for that.

It evolved to linux repo deployment where a yum command would summon the versions & scripts. Convenient for rollbacks too.

Another aspect was testing the ML parameter set. This would typically be updated daily and even though it was not a code change it is like one as it affects behaviour. ML parameter sets would have to pass profit simulation benchmarks to make it to production which was often a challenge in construction and testing on the grid to meet deadlines.