Too Big, Too Small, Just Right

The First Ideal: Locality and Simplicity

Hi,

I once developed a backend with just two engineers. It was the backend for Sunrise Village .

I joined the team already in the pre-production stage, together with my then colleague. For over three years, we were the backend team.

The other teams were larger. We had up to 8 frontend developers, a similar number of artists, two game designers, product owners, product managers, and 2 test automators.

Even the fact that there were only two of us was actually too many. We kept it that way for risk minimization - in case one of us was unavailable.

Marcus Held

"I think Loom is going to kill reactive programming." ~Brian Goetz

Hi,

“I think Loom is going to kill reactive programming.”

This statement comes from Brian Goetz .

Do you know who he is? Brian has been the Java Language Architect at Oracle for 13 years.

He is the author of “Java Concurrency in Practice” - a standard work for every Java developer .

He was also the one who brought JSR-335 - Lambda Expressions - into the language.

What Brian says has substance. You’ll hardly find anyone else in the world who can provide a better outlook on the future of Java and its ecosystem.

Marcus Held

Surprising Documentation

Hi,

Class comments, architecture documentation, method comments, API documentation, inline comments, feature documentation, wireframes, entity-relationship diagrams, use-case diagrams, process documentation, end-user documentation…

There are so many things one can document. But what do I really need?

Documentation doesn’t write itself. Someone has to take the time. And for it to truly add value, it needs to be well-written, as complete as possible and focused. Not everyone can do that.

In large corporations - with thousands of employees - a lot is documented. There are software architects who have the time and education to write good documentation. There are so many developers that enough time is allocated to document the code. And technical writers produce the highest quality end-user documentation.

Marcus Held

Double-Entry Bookkeeping

Hi,

An error in accounting can be costly. Especially in large companies, where there are many transactions, it is easy to overlook one.

And when that happens, I might not even notice it. Perhaps the company is doing much better than the books indicate? Or maybe it’s actually unprofitable?

Merchants in the 13th century recognized the problem. A system had to be found that would make errors less likely. They invented double-entry bookkeeping.

Marcus Held

Nobody Talks About Project Loom

Hi,

“Why isn’t anyone talking about Project Loom?

On the JVM, one of the largest changes in years is looming over us.

And it will massively influence the way we work.

Asynchrony is difficult. There’s so much to consider:

How do I configure my thread pool? Does the code path have more wait-time, or does it take a long time to calculate? And how large should the queue be in front of the thread pool? Are spikes in the code path to be expected?

Marcus Held