Software craftsmanship

The Problems with Single Threaded Systems In early days of computers the entire operating system was executed on a single thread. The problem with these kind of systems back then was the long running tasks would prevent the execution of other tasks causing the other applications and OS to stop responding, And if the long running task has some bug in it, or if it goes to an infinite loop then the end user has no choice but to reset the system. This was a common problem for the 16-bit systems, as they were able to access only 1MB of memory. Microsoft knew that 16-bit Windows would not be a good enough operating system to keep Microsoft relevant in the industry, so they created a new OS to address the needs of Corporations and individual. Microsoft designed the new OS (Windows NT), they decided to run each instance of an application in its own Process. A Process is nothing but a collection of resources that is used by a single instance of an application. Each Process in windows has g...

Domain Driven Design A good code base creates value for the organization and to the client. The better the code reflects the problem domain the more Money it is going to create for the organization. In his book (Domain-Driven Design: Tackling Complexity in the Heart of Software), Eric Evans first introduced the Philosophy of the Domain Driven design (DDD). While the full explanation would take a couple of 500-page books, the essence of DDD is profoundly simple: capture the domain model in domain terms, embed the model in the code, and protect it from corruption. Although let me warn you DDD is not A Silver bullet for every problem It is not the new Shiny/Trendy design pattern it is not a new template in the latest and greatest IDE’s And certainly not some coding standard/guidelines for the rookie software developers. Why one should explore and apply DDD practices? It always feels good when you look at the code which is written by you sometime back, and you are still able...

D o you comment your code often? If the answer is yes, you need to rethink on how you could avoid or reduce the number of times you write comments? Why? There is nothing wrong in commenting the code, what’s wrong is writing the code that requires comments to explain what it is doing. As a developer, instead of focusing on writing comments, one should strive for writing self-explanatory code. Take a look at below C# code snippet,  It would be very difficult to understand the code if that comment wasn’t there. So how do you avoid commenting if it is difficult to understand the code without it? Makes sense Right? Ok, now take a look at below code snippet. With slight modifications, like putting the block of code inside the function with meaningful name, I’ve managed to avoid the comment, the reader of the code should not get confused now. There is another problem with the commented version of the code, what if the requirement changes? Like remove all the spaces, in this...

It was a very busy week.   One of our Project had a release date planned and at the same time the Web API team done some breaking changes. The application we were building is huge and we didn’t had much time to analyze what could break because of those changes. We in the team figured out couple of places which could get affected by these breaking changes and we started to incorporate these changes in the application. In a week our QA team had a test round on the part of the application which got affected and gave us the green flag. It was Thursday, There was a long weekend ahead of us, and we wrapped all the work at our end and provided the application for the internal QA team of the client. After testing the application, the internal Client QA team dropped a long mail at that night saying they are rejecting the build as one of the module from the application is not working at all. I was travelling to my home town for the long weekend, I received a call from my manager to inform m...

When building a large software, you will get overwhelmed by the overall complexity. Managing this complexity is very difficult without proper planning. You as a developer will then decide to conquer this complexity by dividing it in to smaller components. A Component in this system can have its own subsystem, which can be built on top of other small individual components. A component can be a class (if the software is being built in object oriented programming language) which will have a single responsibility. When you divide your system in to components and components into subcomponents, you will have a system where complexity is reduced to the web of individual components, where each component is responsible to handle a single responsibility and can focus on a specific area of a software. Any modification in such kind of a software does not require a change in other logically unrelated components. The DRY principle tells us, to not repeat these responsibilities anywhere else in the ...

Building software nowadays getting more and more difficult. Developers has to keep up with the always changing frameworks and technologies. We always feel that, "Can I keep up with these changes and stay competitive?" There is plethora of tools and frameworks to choose from to solve a problem, and still there are very few or none to solve the biggest issue, the issue of writing a good code which is flexible and easy to maintain. Every developer, while executing a project has to go through various stages. Before writing any code, He has to gather and understand all the requirements, he has to choose required tools and framework, he need to make sure that he meets the deadline and after doing all this, there is Maintenance. If deadlines are strict developers tends write code in a hurry which just works. Such kind of approach results in a code which after some time becomes hard to understand, hard to maintain and can take more time and energy to add simple feature to the softw...