Skip to main content

Deals You Can't Miss

1 Year Subscription

50 Common Misconceptions In The World Of Software Development


We all have our share of mistakes. We evolve over time learning our lessons. This post is to help you introspect your thoughts on varied things that float in the realm of software development. Below is a compilation of "some" common misconceptions that we hear and get influenced by for bad.

  1. Writing Unit Tests = Test Driven Development
  2. 100% Test Coverage Report = Code well done!
  3. Building deployment artifacts by central machine = Continuous Integration
  4. Every developer checking in code in his branch of remote central repository to be merged with main branch at a later date = Continuous Integration
  5. Coding more hours = Commitment
  6. Churning tons of code = Geek
  7. Crippling team with one-developer dependency = Star Developer
  8. CTOs, Architects and the like don't code
  9. Estimates = Commitment
  10. A CTO sheperds development team and need not understand business.
  11. Big Fat Product = Sure shot success
  12. Idea is rare and so expensive. Execution/Implementation is cheap.
  13. Developers don't need to know the business domain. Business Analysts and Product Managers are meant for it all.
  14. Developers are cheap and replacable.
  15. MVP = Lean Startup
  16. Variations of MVP like Minimum Lovable Product, Minimum Awesome Product, etc is Lean Startup++
  17. Startups don't do TDD, because they don't have time.
  18. Enterprises don't do TDD, because they hire really intelligent developers.
  19. Startups hoping to hire geeks with their sales pitch and not give adequate equity or salary.
  20. Enterprises hoping to hire awesome developers by virtue of their brand.
  21. Immature culture = Open Culture
  22. Reducing levels in org hierarchy = Flat hierarchy
  23. The ability to speculate user needs and add features to product = Product Management
  24. MBA grads deserve to be Product Managers
  25. Feature richness = UX richness
  26. Selling a product ain't that hard
  27. Developing a product that scales and thrives is just science and has no art to it.
  28. Code intelligence over readability
  29. Code brevity over maintainablility
  30. Product Manager > BA > Developer > UX Specialist > Quality Analyst
  31. Every task is a User Story in Agile
  32. Adding Story Points to Bugs = Improved Velocity
  33. SAFe is the safest Agile
  34. Increased Velocity = Increased Agility
  35. TDD is waste of time and is practised by mediocre developers
  36. Pair-Programming is practised by mediocre developers
  37. Agile Certification = Agile Expertise
  38. SAFe is scalable Agile
  39. Speculating  end-user needs = Business Analysis
  40. Using {substitute_your_choice_of_framework/language_here} solves scalability
  41. Cloud = Scalability
  42. Machine Learning is about algorithms and not domain knowledge
  43. Analytics has nothing to do with domain knowledge
  44. The strength of an Agile Coach is in his knowing how to use tools like Jira, etc.
  45. Software Craftsmanship is about using tools like Jenkins, SonarQube, etc.
  46. DevOps Team is the new jazzy name for Infrastructure Management team.
  47. Agile is the new way of managing developers
  48. UX is all about UI
  49. Full-Stack Developer = Frontend Developer + Backend Developer + Infrastructure Developer
  50. Product Manager is the new Project Manager

This list is surely not an exhaustive one. How about you contribute more to this based on your experience? Please do share yours thoughts as feedback/comments to this blog post.

My Popular Posts

Ten Commandments of Egoless Programming

We are nothing but the values we carry. All through my life thus far, I tried to influence people around me with the virtues I value. Thanks to some good reading habits I had inculcated, and the fortune of being in good community of peers and mentors alike, I managed to have read some real good books. This post is about the 10 commands of egoless programming in Weinberg's book. I shall explain the commandments based on my experience here. So very many decades ago, Gerald M. Weinberg authored  The Psychology of Computer Programming . In it, he listed The Ten Commandments of  Egoless Programming , which remains relevant even today for us as not just programmers but as team-members. Weinberg is regarded as a pioneer in taking a people-centric approach to computing, and his work endures as a good guide to intelligence, skill, teamwork, and problem-solving power of a developer. When they appear to inspire and instruct, we find that they can apply to just about every business area, and e

Should I buy refurbished laptop from Amazon?

This post is based on my experience with amazon.in and guess it to be true on all other platforms as well. At least you can check out and verify for these pointers before you make that decision to buy renewed/refurbished laptop on Amazon with your hard earned money. I see this question propping up in several forums and on many different occasions. In the recent past, I had my 5 year old dell laptop that gave up because its motherboard failed. One of the options that I had in my mind was to re-use the HDD and the 16GB DDR4 RAM of that old laptop in the one that I purchase next as secondary.  I had come to a conclusion that it is not worth buying a refurbished/renewed laptop at all. Why? For the following reasons, most of which I see as BIG #RedFlags: You got to remember that Amazon provides a platform for 3rd party sellers to sell their products as well. So in your search for refurbished laptops you wouldn’t want to choose some random 3rd party seller who Amazon doesn’t endorse. You cou

Multi-tenant Architectures

  Multi-tenancy Application Deployment Architecture could be modeled in 4 broad ways: Separate Apps & Separate Databases Shared Apps & Shared Databases Separate Apps & Shared Databases Shared Apps & Separate Databases There is no right or wrong here. It's about choice and consequence that you should consider taking into your business context and constraints. In this post I intend to jot down a some key points to keep in mind for each of these multi-tenant architecture. These are more of quick notes for my quick reference, a cheat-sheet of sorts when I have to make choices. And I guess this can come handy to you too in your wise decision making. Separate Apps & Separate Databases Easiest to implement from development and deployment stand-point. Just automate the deployment infrastructure for every tenant for quick set-up. Most expensive of all the models from infrastructure cost stand-point. Relatively longer deployment t