For some reason, I’ve been seeing a lot of people piping in and saying and/or predicting that monolithic software architecture is going to be making a comeback starting this year. It probably doesn’t help that once I started reading the first article about companies moving from services to monoliths, Google kept highlighting more, but I think the impetus of this was Kelsey Hightower’s unpopular opinion segment arguing that most companies that switch to service-oriented architectures end up creating “distributed monoliths” that are the worst of both worlds. By the way, you’ve likely noted that I’m just using the term “service-oriented architecture” (OK, “SOAs”, because I’m lazy) for both service-oriented architectures and microservices – that’s just to make my life easier – as far as I’m concerned a microservice is just an SOA service with a very small scope.
A couple of months ago, developers on Twitter started spamming jokes or frustrations about the mythical “10X engineer” in response to this tweet by a startup investor from India. Thankfully, outside of this guy’s original tweet thread, nobody else was buying the “10X engineer” nonsense. Unfortunately, the fact that this guy tweeted it in the first place means there’s too many people out there laboring under a delusion that desperately need to be set straight.
I’ve been developing in Java since late 2009. It’s a good language, but I’m starting to wonder what kind of future it has. I’ve been using Java 8 since shortly after it came out, even though Java is currently on version 11. Java’s obviously still being developed, so why not move forward? A big part isn’t the infamous module system that launched in Java 9, and broke a lot of stuff. Part of it is the fact that Java is owned and controlled a by a company that seems more interested in rent-seeking off oa Java than doing anything innovative with it.
Software is written to solve a problem. Sometimes, it’s more than one problem, but you get the idea. Being someone who both uses and writes software, I’ve found the best software out there doesn’t just solve a problem, but was written with a clear and definitive opinion about how that problem should be solved. That’s not by accident or coincidence, it’s very much causal.
I got a comment on my post about performance tuning a REST API call asking about code tuning with examples. I don’t have code examples handy, but I can certainly run through some general performance tuning tips I’ve found over the years. No matter where you find advice about improving your code’s performance, keep in mind that every situation is different, and those differences could impact the relevance and usefulness of any advice offered.
Probably 1 of the most difficult juggling acts in software development is scoping a minimum viable product. I’m pretty sure a lot of that comes from the juggling act and judgement calls that constitute defining said minimum viable product. It’s not easy to do, mostly because defining a minimum viable product involves balancing 2 mutually exclusive terms. That said, I think you can find the best set of tradeoffs en route to the minimum viable product by examining the principles behind each part and then combining them back together once we understand what we’re looking for to satisfy each keyword.
Automatic software testing is an interesting thing. Books have been written on the topic, libraries have been built to try to bring the practice to traditionally hard-to-automate sections of testing, and in some places, it’s so important it’s the first code that gets written. There’s a lot of different philosophies about how it should work, but in my experience, it’s probably an area where the less religious you are about it, the better it’s likely to work for you.
Java 8 introduced a lot of cool features, 1 of the most useful of which was the
stream() method. This nifty little method lets you treat an Iterable as a stream, enabling cool things like lambdas operating over a list. Related to
parallelStream(). This lets you group your stream into smaller streams that are run in, you guessed it, parallel. Specifically, your data is processed in a thread pool the size of the number of cores on your machine, minus the one running your app. That’s a handy piece of information you’re going to want to keep in mind before you start throwing this nifty little call around in your code.