Software craftsmanship

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 ...