The Mortal Mamba

Thoughts about random bits of universe.

Lessons in Software Development – Learnt from failures

Following are some of the critical learning I have absorbed in my career as a Software Engineer till now, some of these have costed me big failures  : 

Never assume anything 

One thing that has costed me most are the “assumed” pieces. Pieces that I have assumed in the design, requirements, code, or may be didn’t put a little more effort in going deeper, or simply procrastinated. 

Always clear out any assumptions or unknowns no matter how small or insignificant they are. Doing this you will save any surprises later on. 

There are 3 categories of knowledge : 

  • Known known (KK)
  • Known unknowns (KU)
  • Unknown unknowns (UU)

It is the KU and UU that causes us most sufferings. UU can’t be fully ruled out but we should still try to do our best due-diligence. KU should be investigated as much as possible. 

Think end to end  

This is slightly related to the previous concept. Always simulate the design end to end with different sort of scenarios, different nature of data, different nature of inconsistencies. Consider multiple scenarios, ask questions at each step of the flow.

Kill switch 

The goal should be to always leave things better the than the form in which you have found it. One of the implications of this is that your system should be easy to fallback to an earlier stable version of the system which didn’t include your change. All of your new changes should be kill switch guarded, if that switch is on then no new changes would be executed. The kill switch should function well for the code, well for the data as well. No assumption should be made for omitting a particular piece of code to be kill switch guarded.

Extreme ownership 

Owning the mission along with changes you are working to the maximum extent possible. Own it for success and failure both. Keep the bigger mission in mind and do whatever you can to make it success. 
Go for “why” before “how”, it should be clear why something has to be done.

Resolve low priority task 

Resolve it while it is small. This might seem very trivial, but often we keep a low hanging task which can later on become a blocker or highly urgent task and at that time we might not be able to devote enough time to it due to other ongoing projects. It is best to keep a check on the low priority tasks on the regular basis.

Published by

Leave a comment