Skip to main content

Posts

Showing posts from August, 2017

Knowing the limitations of an architecture is the key to preventing technical debt

Monolithic applications. Microservices. There are different types of architectures and they all have their pros and cons. Believing that one type of architecture ONLY has advantages and no disadvantages is not going to help your team and your organization. For instance, the microservice architecture has a lot of advantages, but if you don’t understand the microservice to microservice dependencies, it can easily get out of control and it becomes a disadvantage. When pros and cons of a specific approach are summarized at the beginning of a given project, what gets forgotten is noting down the disadvantages and making sure that they don’t turn into technical debt for your tech teams. It is very acceptable to have limitations in your architecture or a specific part of your system as there is not such thing as perfect architecture. We are always on the path to achieve that architecture elegance and staying on that path without reaching the perfect elegance is a norm in software e

Prototype — Turning it into Final Product quickly in order to see innovation in action !

I have a saying “There is nothing more final than a POC/Prototype”. Sadly a lot of times an unpolished prototype just becomes your production version of software. On the other hand, we have cases where prototypes fully become a throw-away work.  How do we take a prototype into a final product quickly to see the fruits of your innovations with minimal effort and at the same time not have a drastic difference between the design of a prototype and the design of the final product? In other words, how do we introduce agility and flexibility? What’s on the table. You have the following in the picture regardless of the type of architecture: * Product owners and innovative ideas * Front-End development * Web-tier (server-side) development * Business logic development in some forms of web services or APIs. When you develop prototypes, you can take the Business-Logic component out of the equation most of the time and for the purposes of this article, I will not focus on that part.

OneNote as a Task Management Tool — My System for task management

OneNote 2013 and OneNote in general is a very useful task management tool. It is really designed for note-taking and organizing your notes. When it comes to task management, its main purpose is not to organize your tasks unless you use it together with Outlook tasks, but I have developed a pretty good system that works well for me by utilizing some beautiful features of OneNote. How did I end up using OneNote? Over last 9–10 years I have spent time trying to improve my organization skills and as a result of that, I searched for tools that can simplify my professional and personal life. I liked the simplicity of Tasks application on early Blackberry phones and I was a big user of that app. I also went through the phase of maintaining my to-do list in text files and managing them via some useful editors such as Notepad++, Editpad, and CrimsonEditor. As my role and responsibilities changed and as the need for rich text format notes increased, I needed to find a tool that is Microso

Teaching kids the importance of information security — A simple fun example with encoding/decoding

Teaching kids about information security is very important today because the social network websites and applications are blurring the line between what should be shared securely and what not. Everybody is busy over-sharing the good, bad and ugly over the internet and in the process of doing that forgetting the basics of information security or never taking the time to learn it. Or is it that nobody is introducing these concepts in school? It is something that needs to be introduced in our education systems from early days. Do you remember the days when we used to send those short messages on a piece of paper in our classrooms? Some encoded those messages because you did not want another person in the middle to open it and understand what it says. How were those messages encoded? The simplest example is: You create a simple mapping for each letter and number in the alphabet. Then you encode your message and write it on a piece of paper. Then the person on the other end decodes

Yes, we software engineers do care about the business value

The perception is that software engineering only care about the low-level details and that’s where they find their motivation. Let’s go to Day 1 out of college and you have a first professional software engineering job. It is overwhelming just to deal with the reality of having a professional job and the junior software engineers are generally all about solving the low-level technical problems and being motivated by the technology that is used in problem solving. Later in your career as a software engineer, you learn the business better and then you start understanding what it takes to deliver an enterprise-level application to production and keep the end customers satisfied. That’s the turning point in your career where you find the motivation in: * Optimizing the code and working on other geeky things * Understanding how your application or your module or your few lines of code relate to the overall revenue numbers and customer satisfaction. Then even further in your caree