In the previous article, we discussed one of many possible journeys for the evolution of ‘System Design’ in search of nirvana of Independence, i.e. Independence of development, technology, deploy-ability, scalability, and team structures (autonomous).
If we weave this whole journey so far, it is evident that effort and direction were always to achieve the following goals of System Design:
Is story point estimation mandatory for being Agile? Can we use Hours?
“Let’s use Story Points
We are following agile now
Yayy.. story points!
How many hours will these stories take?
But are we not using story points now?
Yeah, but we still need to plan. Hours are better for that. 1 SP = 5 hours. ok?”
Heard this story of story points and hours many times. It is important to understand
Why do we need Story Points?
Is it mandatory for being agile?
Are hours prohibited?
The key motive for story points or hours is that we want…
I started my career in an early-stage startup. That gave early exposure to a few of the responsibilities which are sometimes bestowed after years of experience. One of such experiences was to be involved in the hiring process. I took my first interview in 2002. Being an early-stage startup, our focus was to hire engineers who have a good grasp of software engineering concepts so they can be productive soon and have a ‘can do’ attitude. The interview process was designed around these focus areas.
Evaluation for technical skills was easy with some specially designed questions around Core Java and…
This is an incident from my childhood. Back then, our daily routine used to start very early in the morning (4 am). I learned this habit from my mother and grandmother. They used to wake me up every day. At some point, I grew a wish to surprise them by waking up earlier than them. However, at a tender age, it was not easy to wake up that early without an alarm clock or without help.
I kept on thinking for many days. That wish was growing stronger and stronger. And to my surprise, one day I woke up earlier…
If someone asks me who is my Guru for Java, I would say ‘Sun Microsystem’ and ‘Apache Foundation’.
I am from a generation, where most of the programming learning was by reading Java source code. Internet was not a big store of many rich blogs or forums, and hence reading through code was the best resource to learn. Moreover, the kind of components we built, was not possible without understanding the behavior of the system that we were extending. Hence reading through the code of Java libraries and components was almost mandatory for building the right extension, and the products.
“In some ways, programming is like painting. You start with a blank canvas and certain basic raw materials. You use a combination of science, art, and craft to determine what to do with them.” — Andrew Hunt
My first lesson on the importance of logging was in 2001–02, from my manager and coach Puneet Agarwal. We were building a framework for Data Bound Swing Components which can be used to design any application dynamically using a Net Beans kind of IDE, to enable rapid application development.
The design was to extend Swing Components, attach metadata for data sources (and data)…
When I think about documentation in code, I think about a fellow developer reading it a couple of years down the line when I am not around. And that defines the test/quality criteria of documentation for me:
Will a developer who just understand the system domain, would be able to make sense of this code or not?
I have a short memory so I even forgot code written by me also after a couple of years or even in a much shorter span. Hence, I am a good test case for my code and documentation to see if I could…
Albert Einstein once said “Setting an example is not the main means of influencing others, it is the only means.”
To complement this quote, let me tell you a story.
I started working as a shop supervisor back in 1998. It was a mechanical workshop with approx 25 technicians. Most of them were very experienced and were in the age group of the ’30s to ’50s.
It was a challenging job for a 20-year-old boy to manage the workshop with such experienced workers. Hence, for all the obvious reasons, I had various interesting experiences and learning during this job. …
This is the second article in the ‘Art of Clean code’ series. Refer to the first one here.
Error Handling is to accept that surprises are inevitable and to be prepared to manage any surprise gracefully with as minimal impact on customers as possible.
But isn’t error handling something which we do as part of coding normally. We use try/catch and throw the error. Let us try to understand what is more in Error Handling.
Back in 2005, I was tasked to implement a BPEL-compliant workflow engine, which can process a large number of requests concurrently without degrading performance. It…
Microservices architecture bring us so many great benefits, as we discussed here. However, nothing comes free and so the benefits of Microservices. There are various challenges which are by-product of microservices, and it makes all sense to understand these well before beginning journey in new fancy world.
One of these challenges is the complexity of troubleshooting which comes with microservices pattern. We shall discuss this and its possible solution in this article.
Troubleshooting is part of development life. Life is comparatively easy when debugging is for one monolith system. But microservices world has many smaller services, which interacts with each…
Enjoy building great teams and products, a learner, an explorer of matrix