The software requirements bitter feelings


Not knowing the full requirements is agile“, an old boss of mine told me in the past. As soon as I heard it, I freak out! I couldn’t believe it! I was so frustrated that I don’t know how I managed to keep my mouth shut! Lacking functional requirements is a recipe for disaster. A way straight to hell. You can’t build a system if you do not know how it works. Agile doesn’t alter the need for functional or other requirements, but it does change how you gather them. The waterfall way is to go through a long process of documents filling and revising them, till they contain all(?) the system’s requirements. The agile way to gather requirements is to specify the requirements for a small increment of the system, a minimum viable product as it is usually called, build it, then get feedback and work on the next increment. No matter the way the phrase “I don’t know” is embraced, should never be acceptable! Without the right context anyone might understand anything!

Team communication


Some people are really good in communication. They have the charisma, the talent, the skills, to communicate, to listen to others, and persuade them if needed.

Programmers are(?) not that social, at least not as much as the business or the HR people. Ιn addition to that, teams now have more than one formations. People together in a room or building, distributed, hybrid. Especially during covid era nowadays, distributed teams tend to be the standard.

Point of view*


Christmas is always a period of retrospecting. So let’s retrospect software design and development. When it’s time to design a new software system, a lot of variables must be taken under consideration. One variable is the past also. In order to paint the future, you have to look what you or others did in the past, but also what didn’t happen and why. Especially the what didn’t happen part might give you more insights.

If you take a step back, and look at similar to yours products and services, you will understand more the progress that has taken place in the domain, the growth, the risks and the failures, if they exist. The software analysis, design, and development processes, principles and tools have changed a lot in the past fifty to seventy years. But one thing is still the same. And this is people’s point of view to the goal, no matter if they are the stakeholders, the developers, the users. And the goal is to be better, faster, stronger, more successful than the competitor and keep or increase the power and domination.

Could the goal be different? Well individually yes, but in a corporate world the aforementioned explanation of the goal, is what you will hear from most of the companies, unless companies have become socialistic structures and I don’t know about it!

*Fates Warning – Point Of View (OFFICIAL VIDEO) – YouTube

Think, don’t just execute


I believe, and this might be a bit controversial, that many people write code, but not all of them are programmers. Programming has nothing to do with tools, languages, frameworks, IDEs per se, it has to do with your way of thinking. The process you follow to analyze and decompose the problem successfully, then to pick the right tools and use them correctly, without abusing them. My math professor, at the university, used to say: “Don’t kill a fly, with a shotgun”.

C# extension methods to save the day


Extensions methods, that are heavily used in LINQ and in fluent like interfaces, allow developers not just extend existing types but organize the code better. Especially functionalities related to those types. Also, extension methods can be used to add functionality to types we have no control upon them.

When no one is in charge, and why is wrong!


It’s not a new trend, nor the norm, but it is for sure a contemporary alternative way of management, at least, in the technology domain. Leaderless teams are temporarily or intentionally without a leader, but they are self-managed.

What’s the goal of a self-managed team? According to Andy Doyle, former Head of Operations at Medium, a self-management structure “aspires to empower individual voices and avoid the bureaucracy that often accompanies traditional organizational structures.”

C# and FP – episode 3 – OOP today, Inversion of Control and Dependency injection.


The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

Joe Armstrong, father of Erlang

He is right, you know! I totally agree with the quote above. The abuse of inheritance, leads to over complex systems with objects that have no clear responsibility and in general the SOLID principles go out of the window.

How to fail as a startup


You own a startup company, right? You, supposedly, have a super, modern, whatever idea that you want to develop it and sell it, and make money of it. Plot twist! What happens, as a startup company, not having totally defined your idea? Not any peripheral details, but the core idea itself of the product you want to sell! You are doomed to fail.