In the Software development industry, "over engineering" can be defined as ‘implementations that anticipate problems we may encounter in the future'. This means thinking short-term and developing solutions similar to the original requirements. Be careful, to avoid falling into DRY (Don't Repeat Yourself, No Te Repitas), as you end up writing extremely generic code, with some features that are not very explicit and therefore difficult to understand and maintain.
Ready to be inspired?
Thank you for signing up
Join our newsletter for expert tips and inspirational case studies
Your welcome email is on its way! You can pick the emails you’d like to receive by clicking the link to the Preference Centre.
For example, for the sprint we're working on, we are asked for a solution to update room availability on a hotel booking page. The developer, who knows the business model, anticipates the next request: A solution to update travel package publications. When they start working on the solution for the original request, they do it so it is not possible to replicate in the future for the anticipated functionality. This decision is, however, correct. Avoiding code reuse is one of the basic concepts of programming, therefore proceeding in this way is something that we have internalised. However, for that sprint, anything other than upgrading hotel functionality should not be a priority. By anticipating possible future implementations, and making work-affecting decisions based on that anticipation, you're directly impacting your ability to finish the sprint and the relevant tasks within it on time. And what is worse, we may never be asked for those functionalities that we imagine and anticipate, and therefore we would have been working on something unnecessary. Developers are very into acronyms, and of course, there is one for this concept: YAGNI (You Aren't Gonna Need It, You won't need it).
Go, That simple language that helps not to anticipate
A few months ago, I started to get into the world of Go by participating in a study group that we set up in Codurance. Naturally, I had high expectations, being that it is a newer language (its first version dates back to 2009) and is considered an "evolution" of the old and beloved C, something like "the new C++".
Go caught my attention because it does not include some of the basic concepts present in other languages such as Java, TypeScript, Python, etc. For example, Go does not allow defining classes or inheritances, nor does it have control structures to iterate, such as while. This is why I have even come across the joke that, rather than “the new C++”, Go is “C–”. Jokes aside, let's see why, for me, it's a great language.
It could be said that it is a minimalist and humble language, and a priori those things that it "does not have" can be interpreted as deficiencies. ” However, as the language begins to be used, we observe that we can solve problems in the same way. By having a reduced toolbox in Go, we don't need to think about too many options, and can focus more on what we have to solve. That there are no classes? Let's use structs and functions. That there is no while or Streams? Let's use a for, it works the same. Do we also have inheritance? Better yet: let's use composition. I find in Go, then, a good ally to not anticipate features that are not necessary to solve what I need at any given time with my code. With Go we easily write only what is necessary, and that's fine. It allows us to be agile and release features to production more frequently and with confidence.
This simplicity helps us to be more explicit with our code. I have found, for example, that it is common practice to implement your own test doubles "by hand" (mocks, spies, etc). At first I thought it was a bit awkward, but over time, you get used to it and see how much we depend on libraries and frameworks to do the same thing on other platforms (I'm looking at them, Java and Mockito). Relying less on external code gives you almost total control, it's not as heavy-handed as one might originally think, and best of all, it gives you the freedom to be creative with your implementations. Going back to the example with which we started this blog: its simplicity allows you to reduce certain tendencies to anticipate that can make tasks very difficult and harm the code.
Now we want to open a GO study group! and invite you to join the initiative. We meet regularly, we make katas, share readings, tips and our progress with this language and we give each other support to improve our experience with it. We are preparing a calendar of activities to share with you, so stay tuned and join us in our Meetup because the Codurance Go Study Group will start soon - and, you are invited.