June 3, 2018

Microservices is more than just an architecture

DevOps is culture and not methodology! For the scope of this post, I do not plan to defend or say against the statement. But will be brave to claim that practice and patterns by which software teams (also organizations) are built/organized, it certainly does impact the culture of the team and individuals in the team.

Also, weather given practice would work for team or not also depends upon prevailing culture of the team.

Those agreeing to above two, and have pass-through adoption of Microservices in their software architecture, would likely to agree that making people accountable or have them convinced to take ownership of either a software service or any other area is easier than the teams having hard time adopting to Microservices architecture.

Those individuals and teams who understands Microservices architecture well, more likely to say “yes” for the question “Can you please own this”.

And I strongly believe that in this equation it’s not only a=b but also b=a. That is, if individual understand importance of taking ownership, she likely would understand and adopt Microservices easier than others.

June 3, 2015

Code refactoring is important

One great mind have said it well that “Change is the only constant in the life”

What is the difference between hardware and software? One aspect suggests that “Hardware is likely to have mechanical parts that are subjected to wear and tear, and will need maintenance and replacement to extend continues service. While software do not have any mechanical parts and it is not subject to wear and tear.” 

If we live in static world, this would be true, but unfortunately or rather fortunately we don’t live in static world. Like many other things, software or the environment within with it gets used changes. Change in the way business operates that uses the software i.e. requirement change, enhancements to support extended business needs, change in environment within which software was assumed to run, or any other assumption within which software was built proves to be wrong, these are some of the example why software needs regular maintenance.

In science entropy is well used word for explaining gradual decline in disorder. It is bound to happen, over the period of time till equilibrium is achieved. If I draw the analogy, well engineered code at one point is order state. In changing world demand towards software changes, and  it will be inevitable to have the situation in life cycle of the software that it would go towards disordered state. I have accepted this to be fact until proven wrong, and based of I would suggest business that depends on the software that put effort and money to bring the software back to ordered state, otherwise one is bound to pay higher cost down the line. Do talk to engineering team to understand accumulated disorder, and prioritize it in the backlog. Earlier it is done better it is.

January 20, 2011

Thought, Suggestion, Quote,

Filed under: random thoughts Himanshu @ 2:20 pm

Bad news is better than no communication

April 18, 2010

Question your guesses and assumptions

Filed under: random thoughts Himanshu @ 12:19 am

It’s fare to guess or assume, in fact it helps moving forward in at least one direction, and is inevitable many a times. But started believing that a guess or assumption is truth, can be really harmful. Eventually questioning guesses and assumptions is important, and that also helps being open for multiple perspectives.

Powered by WordPress