The Pessimistic Developer

Deciding how to migrate a software system depends on what you are starting from. So if it seems like you want to teach a fish to fly, you need to stop and ask yourself if that's really what you want. A common idea is that applying all the current buzzwords to your system will make it better. Add CI\CD, Kubernetes, DevOps, microservices, etc, etc. But what does all that get you, and at what cost? It all depends on identifying your bottlenecks. If you are developing so many features that you can't push them to production fast enough, then CI\CD makes sense. Otherwise, focus on where your bottleneck is. Testing? Agile process? Scheduling? Work on those before starting a major overhaul. The great thing about software is that you can make a fish fly, but you still need to answer why. Software is not a Field of Dreams, just because you built it, they may or may not come. Build the system you need first, and identify areas for improvement. Then build to address those areas. But if ...

As more teams are working remotely, communication is more important than ever. But few teams think about what information goes through which channel, they just add more channels. Slack, email, JIRA, Salesforce, and so on. But how much overlap is there between channels, and how little connection between them? A lot and very little. This leads to an environment where people are spending time reiterating things that were discussed and decided in other channels. This is a clear violation of the Don't Repeat Yourself principle. There need to be clear rules and boundaries around what gets discussed on which channel. Focus on actionable communication. Also, keep the focus on the takes to be solved. Tie those tasks to a development issue or project whenever possible. Assign the issue to a person to resolve and set a deadline for resolution or response. Discussion about how to do something can be done in other systems, but once the decision is made that should be linked to the underlying ...

Has there ever been a bigger elephant in the room than Java? Bigger in terms of marketshare, and bigger in terms of  footprint size. I started out as a Java developer, and have done most of my work with it, but I definitely feel that there are better tools for specific jobs. If you want one single language to do it all, maybe with some HTML thrown in, Java will do it. But how many times is that really the case? Java primarily suffers from what I call Unintended Dependencies, or Why Do I Need Your X to Build My Y? As everyone knows, Java ships with all the libraries to do everything from application UIs to database persistence to messaging to system calls, to building native platform calls, and more. I've been around long enough to remember when you needed to add J2EE as an additional package, and I think that's when things started to go wrong. Now, just to build a Docker image of OpenJava it takes about 500 megabytes of disk. Add Tomcat onto that plus whatever app you're d...

Hello and welcome to the Pessimistic developer. I want to take a closer look at so called best practices and see if they are just common practices. Or to put it another way,  i want to use a critical eye and see if common patterns are really the best choice for you and your project. So I don't want to be the guy giving a TED talk, saying how great the newest technology is. I want to be the guy giving the talk recommending caution and making sure it's the right fit for you. Modern stacks give us the ability to fit just about any square peg into any round hole, but now it's our job to decide if that's the right fit. I think the core of this problem is that developers have not paid attention to the principle of " You're not going to need it " and have added too much complexity to systems that could really be implemented more simply. But architecture is just as much a part of the design as the code itself, and it should be implemented as simply as possible u...