Being a co-founder of Solidstudio, Paweł has got to see all the development phases. He’s a skilled professional with years of experience, both in the software and in the eMobility worlds.

Paweł Głogowski

 on overengineering. I have explained its origins and provided some general tips on how to avoid it. However, the principles such as KISS and YAGN that I mentioned are quite complex, and it pays to take a deep dive into them. So, in this article, I will focus on those two principles and give some advice on how to handle them.

YAGNI - Why developers want to foresee the future?

Speaking from my experience, I have seen many times how developers try to outsmart the business and foresee the future by implementing a ton of unnecessary features that will "for sure" be used someday.

Usually, that's because, for developers, the original task often seems to be simple, and they think like that: "I already make some changes in this area of application so I will sneak some additional features into it to save some time in the future." This is a very bad practice because we usually end up with unnecessary code in the codebase, and the foreseen future might never come up. Usually, after 1-2 years, you might decide to delete that code after-hours lost on maintaining it.

At first glance, it does not seem to be dangerous enough to become a source of worry. However, if we end up with more and more unused pieces of code in the application, then it easily becomes very confusing to new developers. Also, someone needs to maintain all of this code, even the bits that aren't being used. This might end up costing a significant amount of time (and money) to your team.

"Always implement things when you actually need them, never when you just foresee that you need them."

It might sound very simple, but it's that kind of advice that is easy to remember, but hard to follow. I will try to provide some real-life examples that break the YAGNI rules.

Creating abstractions having just one well-defined case

Let's say that we have to implement a functionality to send some data to an external destination. For now, it is just one destination. Usually, good developers will think that additional destinations will eventually be the case for the application, so it's worth introducing some kind of abstraction. Let's take a look at following pieces of code:

This can be dangerous from two perspectives. First, you write unnecessary code and also make assumptions about further destination systems. So you may require a huge refactor even if other destinations finally come to life.

"Never introduce an interface or abstract class for only one implementation. Create an abstraction only when you actually need it."

In general, the strategy pattern is a great option to deal with algorithms based on various criteria. However, some developers abuse it by trying to use it everywhere to replace if or switch statements. If the logic is pretty simple and there is just one if - then there is no need to rebuild it and use strategy patterns. Let's take a look at the following example:

It's 5 classes just to implement something that can be done within ten lines of code. And in that case, it seems like we don't actually need it (YAGNI).

While YAGNI seems pretty straightforward, the KISS principle is much more problematic and misleading. Most of the time, that's because for many people, "simple" may sound like something incomplete or primitive. Also, each developer will claim that their solution is "as simple as possible" and not too complex. However, I will try to explain what the main concepts around simplicity are. Let's start by defining what complexity actually is.

In computer science, you can find two types of complexity - essential and accidental. Essential complexity is something that we cannot really cope with. Basically, it refers to the domain and the actual problem we are trying to solve. It's pretty obvious that writing a new Facebook or Twitter app will be much more complex than a simple web page with just one form to send a message.

On the other hand, there is accidental complexity - a complexity that is not related to a problem and originates in bad technical decisions, wrongly implemented design patterns, and so on. Let's try to go deep into some common bad architecture designs that make your system complex.

Layered architecture was very popular in the early days of programming and served as a great concept to separate presentation view from business logic. Then the layers came to the rescue. The ability to develop parts of the application independently was a huge change. However, times have changed, and new technologies have come up. It turns out that now the number of layers is growing, and it's harder to follow the layering rules and write an application that isn't too complex. It leads to a situation in which to fix some simple issues, you need to make appropriate changes in most layers, including unit tests, which might be painful and time-consuming.

Also, developers tend to have strict rules about layers - for example, that a layer:

Is independent of the layers on top of it, having no knowledge of the layers using it.

Layers are a good way of implementing encapsulation, data separation, and so on. However, try not to abuse them, and in case you need to use some layer just to proxy it to the layer beneath it - go ahead and use that layer directly.

“Use just the layers we need, the tiers we need, and nothing more!”

Why do developers want to outsmart everyone?

I experienced a few situations in my career when I started to contribute to an existing project and noticed that there are a lot of 'cool' patterns all over the place. I saw complicated CQRM systems, event-driven systems, factories, decorators, etc., created just to solve some really simple CRUD application.

This is very often the result of isolating developers from business people. They usually don't know where the business is all about and what is valuable to the client. They can't see the application from this perspective, and, as a result, they feel that delivering business value can be as satisfying as exploring new technologies and toys to solve even the simple problems. I have seen a ton of situations, where a group of really talented developers could not deliver anything valuable to the users because they were too focused on technical improvements.

If you're a developer, my advice to you is: try to understand what is valuable to your client and get out of your comfort zone. Understanding what the priorities of the client are will be beneficial for you. Then you could focus on implementing those features and solving real problems rather than building complex systems full of unnecessary patterns and designs that serve your ego rather than users.

 try not to be just a proxy between the client and the developers. Encourage your developers to understand the core business needs and let them join some non-technical meetings with managers and users. Try to change their priorities to regularly deliver something valuable to users rather than introducing new technical improvements.

Managing complexity in IT projects is a really difficult process. In this article, I highlighted just some hints, but it's a really complex topic that cannot be captured in a single article. The most important part is to change the attitude of developers - once they are aware of what is important, they will find solutions that serve clients and not just themselves.

How to deal with overengeenering? Read the article from our expert.

Read this article to find out what overengineering is and how to tackle this problem.

In this article, I would like to discuss some situations that could lead developers to overengineer and what the consequences of that could be. It might come as a surprise, but this could be a problem experienced by very ambitious and talented engineers who lack business skills.

Overengineering could be problematic since these programmers are usually of great value to the company, but at some point need to be supervised by analytics and more business-savvy developers.

Read this article to find out what overengineering is, what its common origins are, and what you can do about it.

Let’s start with some definitions. In this case, they might be problematic and not that straightforward.

"the act of designing a product to be more robust or have more features than often necessary for its intended use, or for a process to be unnecessarily complex or inefficient"

To be honest, this is not very helpful - especially for software developers. We should come up with a definition that is more understandable to the developers. A very straightforward simple definition could be: 

"Code or design that solves problems you don’t have."

It’s slightly better, but it still doesn’t answer all of the possible questions about what overengineering is. However, let's stick to it for now and refill this definition throughout the article.

Common reasons why developers overengineer their code

As I mentioned at the beginning, this problem very often concerns young and talented programmers. That’s because they usually learn about some useful principles like 

, or design patterns from book or course examples that can be very naive. They have a tendency to show that it’s easy to extend every kind of project and all the use cases will fit into 

Unfortunately, that's not always true since business requirements know nothing about these principles and follow their own patterns. That leads to speculation and wrong usage of design principles which I’ll try to explain in detail later on.

Let's take a look at some real-life examples

Using generics to support the "future" use cases

 programming is quite handy and can be a real help when we want to build an easy to extend abstraction. However, less-experienced developers often make the mistake of using generics prematurely.

 to search within CSV files. It’s SQL based so we get ResultSet that needs to be transformed to some more useful DTO object. Let's take a look at the following example:

We made generics just for one case and guess what - it was enough! It hasn’t been changed throughout the entire project. There were no gains thanks to that approach and it confused new developers.

In OO programming, we have quite a lot of concepts that can improve quality. I’ve already mentioned 

, but there are also other concepts like encapsulation and abstractions - and, of course, design patterns. There are also generics and exceptions. All these tools can improve the quality and extensibility of your code. But you need to apply them wisely because these rules aren’t going to make your code better automatically.

You need a closer look at the macro picture of your application to make sure which parts need abstraction and which requirements will most likely change. Take a look at the enterprise version of 

. At the micro-level, it looks perfect as it follows 

 principles, uses design patterns, generics, etc. In the end, it just solves a simple problem that could be easily written in less than 10 lines. Of course, the requirements could change in the future, but right now we’re using all of these principles based on speculations!

To sum up, always take a look at the macro picture - the current requirements and the easiest way to solve the problem.

Don’t generalize parameters when you know their current exact type.

Consider skipping the interface when using just one implementation that most likely won't change.

Don't convert every "if" statement into a separate strategy - use design patterns to complex problems.

Developers try to be smarter than business

Adding additional properties for "future" requirements

Some tasks during development can be a little harder than just writing code. Usually, they’re linked to database changes since a database requires migration, cooperating with other teams, running them on all environments, etc. It’s usually a risky operation and developers aren’t keen on taking that risk. This is where the approach of adding as much data as possible in one migration, "just in case" derives from.

So, let's imagine that there’s a requirement to introduce a new entity in the system. Right now, we need only the id and name. We don’t know anything else so far, but developers often expect to need other fields in the future, so it's better to introduce them and avoid making another database change. And that’s how we end up with additional fields like address, tax number, etc. Most of those fields won’t be used for a long time or will never be used in the system. We may end up with a wrong data model that confuses every new developer and requires some ugly hacks, either in code or in the database model.

Another real-life example is Bugzilla - you can read more about it 

. To make a long story short, developers decided to introduce a new column to the database which indicates if an option is available for a certain user because they think this feature is so obvious and will be eventually available in Bugzilla. It turns out that business guys have a different view on that because this feature hasn’t been present till now.

Too much speculation leads to premature generalization

A common principle in OO programming is DRY (“Do not repeat yourself”). In most cases, it’s quite handy at the micro-level since we shouldn’t repeat our code in classes or methods. However, in the macro picture, following this principle could lead to premature generalization since we use abstract concepts almost everywhere. What is worse, we try to speculate over further requirements, hoping that they match our abstraction model. We would like to have something like this:

While we should rather start by following >KISS (Keep it simple, stupid) and write our system to be more like this:

Our shared logic will be more obvious when the system becomes mature, then we will see which parts can be shared easily.

There are two lessons to be taken from this paragraph:

Business requirements never converge. They always diverge.

At the beginning, it’s best to stick to the KISS principle over DRY.

In this article, I tried to explain the origins and mistakes of overengineering. It may sound like it’s not a big deal and a better approach than underengenerring, but the consequences of overengineering are also quite painful.

Overengineering can lead to building hard-to-extend and hard-to-maintain systems. At some point, developers may conclude that such a system needs to be rewritten because it’s too complicated. But if they repeat the same mistakes, it will end up exactly the same.

In this article, I would like to discuss some situations that could lead developers to overengineer and what the consequences of that could be. It might come as a surprise, but this could be a problem experienced by very ambitious and talented engineers who lack business skills.  Overengineering could be problematic since these programmers are usually of a great value to the company, but at some point need to be supervised by analytics and more business-savvy developers.

Overengineering in software development

Getting access to Java applications inside Docker.

Being an eMobility leader in various projects across multiple startups, Piotr was responsible for OCPI and OCPP integration as well as EMP and CPO platforms development. With extensive expertise in the open standards field and eMobility tech solutions, he is leading teams of experienced developers and contributing with invaluable knowledge and experience.

Piotr Majcher

Docker is a great tool that allows developers not to worry about servers, Ops/DevOps not to think about the servers they maintain. It’s also useful for developers who just want to run dependent components without digging into the details of those dependencies.

But Docker comes at a price. It creates an extra level of abstraction and makes accessing the internals of running code more complicated.

 in an environment that is really close to what we usually have in production.

Introduction - debugging a Java application

In order not to stick to any specific IDE, I’m going to use jdb for debugging. It’s a Java debugger which is a part of jdk. Let’s assume we have an executable fat jar with a Spring Boot application called app.jar.

If we want to run the application without debugging it all we need is:

In order to debug it, we need to add few additional parameters (I’m using a specific setup here):

Since we set the suspend parameter to ‘yes’, the application is hanging waiting for debugger.

In another console we can try to attach the debugger to a running application by using the following command:

After few seconds, we can see all the known logs from Spring:

Attaching the debugger to a Java app running inside Docker container

Now, let’s wrap our sample application and run it inside a Docker container. We can do it manually by using the following Dockerfile:

Then we can add the same debug parameters as previously:

Once we build the image and start the container, we can see the same log as before:

Can we now attach the debugger to the Spring application running inside the Docker? Yes, but first we need to expose port 8000 from the container. For instance, we can run a Docker container with the following command:

Now you should be able to attach the debugger without any problems.

Shell and Exec form of CMD and ENTRYPOINT

CMD and ENTRYPOINT are two commands that may be used to tell Docker what tasks need to be executed when starting the container. Both instructions may be used in two ways:

exec form - <instruction> [<executable>, <param1>, <p>, ...]

For instance, we could rewrite the initial docker file I showed you above using exec from:

It’s a small trap when it comes to passing the debugging parameters to exec form of instruction, as

consists of two separate parameters. To make it work, we need to pass it separately:

It’s important to remember that when working with tools like docker-maven-plugin from Spotify as they use exec form of ENTRYPOINT instruction in their documentation by default and it’s easy to just take “debug string” and pass it as a single parameter.

Summary - how to solve common problems with debugging a Java application on Docker

It’s very easy to connect the debugger to a Java application running inside a Docker container. There are two things we have to remember here:

the exposing port we are going to use for debugging,

properly passing parameters to the JVM, having in mind differences between exec and shell forms of CMD and ENTRYPOINT instructions.

Once we have those two things set up, we can debug our code locally in almost the same environment as the production environment.

Learn the easiest way to debug your Java application by reading this piece of content.

Debugging Java applications running on Docker.

Scaling means everything and automation is the key to do this effectively.

It seems like all anyone can talk about in the business world these days is scaling their technology and automating their processes, but the actual process behind this - including the 

Too many organizations are unaware of how much time and effort it actually takes to effectively scale technology and automate processes, leading to frustration when companies discover that the process is more involved and time-consuming than they initially realized. The purpose of this article is to give you a general idea of what scaling and automating really mean, how to determine if a process should be automated, and show you how 

 can help you determine your business objectives and create custom solutions to meet your needs.

Every organization relies on multiple processes to get work done, either as part of their core business or the operations surrounding it. To scale effectively, companies need to understand the details of their processes and find a way to automate them, whether using technology or other methods.

For example, many organizations rely on automated sales funnels, which rely on automated reporting programs to gather relevant data on potential customers instead of relying on employees to complete this labor-intensive task manually.

understanding project delays and how to avoid them

, the planning stage is one of the most critical phases of any project. When you invest time and energy into the planning phase, you are setting yourself and your team up for success later on. That is why the team at SolidStudio always takes the time to learn the details of each customer’s business model in order to create the best solution to meet their needs.

First, we analyze the process itself: If the current process is flawed or can't be improved, then automating it won't improve the situation because it doesn't actually address the underlying issues. By doing our due diligence and analyzing your business, the SolidStudio team can verify that the current process in place meets your organization's needs and can't be improved before determining if the process could benefit from automation or additional technology.

Once the process has been assessed and found to be effective, we know that we are working on a solid foundation, and we can turn our attention toward the question of automation.

As a product development company, our goal isn't to just throw software at a problem and hope it solves the issue at hand. Instead, our goal is to create solutions for our clients so they can achieve their business objectives. While most of our solutions involve using software, even the most elegant piece of software isn't effective if it hasn't been created with the client's actual needs in mind. By taking the time to understand the details of a client's business, we are able to gain a deep understanding of which processes are vital and are worth automating and which processes won't benefit from automation or need to be improved first.

Determining whether or not a process should be automated can be part of a total 

, which involves integrating the right digital technology tools into different aspects of a business to improve productivity and increase the value they deliver to their customers.

The Benefits of Automation: T-Cup & Cracow Local Tours Case Studies

In this section, we will discuss 2 SolidStudio clients who benefited greatly from automating processes that were previously performed manually: T-Cup and Cracow Local Tours.

 is a health and wellness app that helps customers track their health and overall well-being and sends them regular reports based on the data the app has collected. While these reports were initially created manually by T-Cup’s staff, all of the data was already stored in the app itself, making the report generation process ripe for automation.

 for the T-Cup team that allowed them to take the data in the app and sort it into the correct schema so it could be automatically formatted and sent out to clients. By automating this process, T-Cup was able to bring on more clients while also scaling back on the number of workers they needed in the back office, improving revenue while reducing costs.

Cracow Local Tours offers tours to hundreds of tourists each day, and the sheer amount of bookings made it difficult for them to manage their pick-up and one-day trips effectively.

To help them increase efficiency and better allocate their resources, we worked with them to create an ERP system that automatically matched tour drivers with tourists in the same location, thereby reducing the non-revenue generating driving time between tours. This new system also made it much easier for customers to automatically book tickets for larger groups, which are more profitable than smaller groups taking the same tours, allowing the company to maximize earnings while improving the customer experience.

Using technology to scale and automate processes can be a great way to increase efficiency and make it easier for your business to grow if applied to processes that are already effective and can benefit from automation and technology. Before you commit to scaling or automating a particular process, make sure you have a thorough understanding of the processes you are considering automating and have verified that they can't be improved further. The SolidStudio team is here to help you get this valuable information and create automated and scalable solutions that meet your needs.

Deep dive into KISS and YAGNI principles

06 JUNE 2020 • 10 MIN READ