Peak of Complexity

So, I was at Devoxx 2024. During the opening keynotes, Brian Goetz spoke regarding Peak of Complexity.

You can find it below at [1].

It's important to me on a personal level, as I do tend to make things more complex than they should be.

Often times, it means I overengineer my solutions and program for exceptional situations that are unlikely to occur.

One of those overengineered ways of thinking happened today.

A colleague asked if he was doing it right. He was reading in an XML file of about 5000 entries in a Batch process.

1. First I thought we should use a stream, build the stream ourselves, so we can have an XMLReader that provides us each piece of information we need without loading the entire thing in memory.
2. Then I found out that it's bloody hard to make your own streams. A default builder in the JDK uses a SpinedBuffer which is basically an ArrayList containing ArrayLists. Which means the entire thing is still read into memory.
3. So I thought I could use a simple Consumer. The Consumer gets a new one from the XMLReader when he has one available.
4. Then I found out that that doesn't really mesh well with the Batch Reader process. So I started thinking about using an iterator, instead of an Consumer.
5. But in the end, after everything's said and done, the XML file contains only 5000 entries, and the entries are not very complex and the whole thing could be put into a List of simple POJOs. So now it's just a simple List.

Once again, in the end, I've managed to whittle it down to the simplest solution, but it would be nice if I started from the simplest solution, and only increase complexity when needed.

I guess I still need to work at it.

References

[1] Postcards from the Peak of Complexity by Brian Goetz

https://www.youtube.com/watch?v=Yiye8lqh0Ig