Skip to main content


What is legacy code ?

Changing code with out tests is like doing aerial gymnastics without a net. 

What is legacy code?
Let's look at the strict definition: Legacy code is code that we've gotten from someone else. Maybe our company acquired code from another company; maybe people on the original team moved on to other projects. Legacy code is somebody else's code. But in programmer-speak, the term means much more than that. The term legacy code has taken on more shades of meaning and more weight over time.

What do you think about when you hear the term legacy code? If you are at all like me, you think of tangled, unintelligible structure, code that you have to change but don't really understand. You think of sleepless nights trying to add in features that should be easy to add, and you think of demoralization, the sense that everyone on the team is so sick of a code base that it seems beyond care, the sort of code that you just wish would die. Part of you feels bad for even thinking about m…

Software Development Lessons (learned the hard way)

These are the exhaustive list of lessons Julia Biason learnt in 30 years working with software development.

Folks who have spent some time in software development can easily connect with them. 


Before you start writing code...Spec First, Then CodeWrite Steps as CommentsGherkin Is Your Friend to Understand ExpectationsDesign Patters Are Used to Name Solution, Not Find ThemThinking Data Flow Beats PatternsThe Magic Number Seven, Plus Or Minus TwoCognitive Cost Is The Readability KillerLearn The Basics of Functional ProgrammingShortcuts Are Nice, But Only In The Short RunDebuggers Are OverratedThink About The UsersTesting SoftwareUnit Tests Are Good, Integration Tests Are GooderTesting Every Function Creates Dead CodeTests Make Better APIsMake Tests That You Know How To Run On The Command LineGood Languages Come With TestsDocumenting your codeDocumentation Is A Love Letter To Your Future SelfThe Function Documentation Is Its ContractIf A Function Description Includes An "An…

Design Patterns are not solutions

Design Patters Should be Used to Name Solution, Not Find Them

Most of the times I saw design patterns being applied, they were applied as a way to find a solution, so you end up twisting a solution -- and, sometimes, the problem it self -- to fit the pattern.

My guess is that the heavy use of "let's apply this design pattern" before even understanding the problem -- or even trying to solve it -- comes as a form of cargo cult: "We saw that people used this pattern and solved their problem, so let's use it too and it will solve our problem". Or, worse: "Design pattern is described by Famous Person, so we must use it".

Here is the thing: Design pattern should not be used as a way to find solution to any problems. You may use some of them as base for your solution, but you must focus on the problem, not the pattern.

"Do a visitor pattern will solve this?" is the wrong question. "What should we do to solve our problem?" is the real …

Design Differences Between RDBMS and Cassandra

Design Differences Between RDBMS and Cassandra

You cannot perform joins in Cassandra. If you have designed a data model and find that you need something like a join, you’ll have to either do the work on the client side, or create a denormalized second table that represents the join results for you. This latter option is preferred in Cassandra data modeling. Performing joins on the client should be a very rare case; you really want to duplicate (denormalize) the data instead.

Although Cassandra supports features such as lightweight transactions and batches, Cassandra itself has no concept of referential integrity across tables. In a relational database, you could specify foreign keys in a table to reference the primary key of a record in another table. But Cassandra does not enforce this. It is still a common design requirement to store IDs related to other entities in your tables, but operations such as cascading deletes are not available.


What does schema-less mean for a document database?

Document databases are sometimes called schema-less, but that’s misleading, as the code that reads the data usually assumes some kind of structure—i.e., there is an implicit schema, but it is not enforced by the database.

A more accurate term is schema-on-read (the structure of the data is implicit, and only interpreted when the data is read), in contrast with schema-on-write (the traditional approach of relational databases, where the schema is explicit and the database ensures all written data conforms to it).

Schema-on-read is similar to dynamic (run-time) type checking in programming languages, whereas schema-on-write is similar to static (compile-time) type checking.

Just as the advocates of static and dynamic type checking have big debates about their relative merits, enforcement of schemas in database is a contentious topic, and in general there’s no right or wrong answer.

Completely agree with the above the statements beautifully put by the author. An interesting exce…

Learn to Respond, Not React

You will continue to suffer if you have an emotional reaction to everything that is said to you. True power is sitting back and observing things with logic. 


If words control you that means everyone else can control you. Breathe and allow things to pass.
Let it R.A.I.N. - Recognize, Accept, Investigate & Not-identify


​"10% of life is made up of what happens to you. 90% of life is decided by how you react." -Stephen Covey

Source: Internet

A Wealth Of Information Creates A Poverty Of Attention

What information consumes is rather obvious: it consumes the attention of its recipients.
Hence a WEALTH of INFORMATION creates a POVERTY of ATTENTION, and a need to ALLOCATE that ATTENTION efficiently among the overabundance of information sources that might consume it.
~ Herbert A. Simon (Nobel Prize winner in economics)
Herbert Alexander Simon (June 15, 1916 – February 9, 2001) was an American economistpolitical scientist and cognitive psychologist, whose primary research interest was decision-making within organizations and is best known for the theories of "bounded rationality" and "satisficing".

Story about Samsara from Vidura in Maha Bharatha

From Sri Maha Bharatham - 11th Maha Parva (Stri Parva) - Jalapradanika Sub Parva - 5th Chapter

"Dhritarashtra said, ‘Tell me in detail everything about the ways of that intelligence by which this wilderness of duties may be safely covered.’

"Vidura said, ‘Having bowed down to the Self-create, I will obey thy behest by telling thee how the great sages speak of the wilderness of life. A certain brahmana, living in the great world, found himself on one occasion in a large inaccessible forest teeming with beasts of prey. It abounded on every side with lions and other animals looking like elephants, all of which were engaged in roaring aloud. Such was the aspect of that forest that Yama himself would take fright at it.

Beholding the forest, the heart of the brahmana became exceedingly agitated. His hair stood on end, and other signs of fear manifested themselves, O scorcher of foes! Entering it, he began to run hither and thither, casting his eyes on every point of the compass fo…

Not choosing is a choice

These are some of the quotes I found interesting on choosing.

You are your choices. 

It’s not about time, it’s about choices. How are you spending your choices?

Not Making a Choice is a Choice. 

Letting things happen by default is a choice. If we choose to give up our right to make a choice - we have made a choice.

“When you have to make a choice and don’t make it, that is in itself a choice.” -William James

“A man who procrastinates in his choosing will inevitably have his choice made for him by circumstance.” — Hunter S. Thompson

In one sense choice is possible, but what is not possible is not to choose. 

You can always choose, but you must know that if you do not choose, that is still a choice.