I am not sure I agree that the fact that their system was phased out when they merged is irrelevant. They system would never have survived that deal anyway, and the bottom line is that the selected solution proved most cost efficient given the outcome. Changing the strategy would have had zero effect on this, at least in this case.

Note that I did not work or consult at the companies as an architect, but was rather doing what you may call a due diligence of their systems. This is why I cannot provide any information about the process that led to their current implementation, as interesting as it may be though!

That is more what I would have liked to hear about. Your conclusions as to why that customer had to opt for an SSD. And the fact that their system got phased out isn’t interesting at all. That happens but perhaps it happened because their design was so poor they had to have an SSD to handle the load?

That would have been an architectural issue to talk about. The process that led the to their current implementation.

I just recently improved a leaderboard application by 40 times and that’s not even the end of it. Wanna know what made it so slow in the first place?

The scheduler issue… Well…

See, first of all you actually have to forget about all this modern lore about “agile” and equating thinking with the horrible waterfall model and other IT-related stuff and actually reconcile yourself with the fact that this profession, being an architect, is about problem identification, analysis, problematization , reduction, developing a solution and THEN realising it. And, yes, you read that right! It’s not about mindlessly hacking code. If you haven’t done the first five, what problem is your code solving?

Some things have to be thought through from the start or they will cost you, or – in this case n Indonesians, lots of good money.

Thinking ahead a bit and using the little grey cells doesn’t represent such a huge cost until it has to be done afterwards. Wonder why that is such a hard lesson to learn.

Yet another architectural issues I read nothing at all about.

Maybe you are indeed a duct tape architect after all.

Warning: do NOT use Guice to inject this, as serializing instances created by Guice creates a bad mess!

If you make the wrapper transient, you will have to deal with the possibility of it being null if the game state has been deserialized. Since I know that the transient memebers of the wrapper will be injected into the on each action, I know neither the wrapper or its members will be null when I handle an action. Does that make sense?

Stupid question: Wouldn’t it be more prudent to have the wrapper field declared transient instead of having each field within the wrapper transient?