SlideShare a Scribd company logo

Common Sense Software Development

•
•
Nitin Bhide
Nitin Bhide

The document outlines several "thumb rules" or best practices for software development proposed by Nitin Bhide. The rules include observing customers to understand their needs and pain points, ensuring software is easy to use and mistake-proof, prioritizing simplicity, avoiding unnecessary features, and allowing transparency into the development process. Bhide emphasizes the importance of passion in developing high-quality software according to these principles.

1 of 41
Thinking Craftsman’s Thumb Rules for Common Sense Software Development Nitin Bhide http://thinkingcraftsman.in
The Thumb Rules Observe and Understand your customer Make it Goof Proof First, Do no Harm Add Great Extras Beware of Feature Creep January 14 (C) Nitin Bhide 2
The Thumb Rules … Strive for SIMPLICITY Have a Backstage Pass Common Practice is NOT ALWAYS Common Sense The Passion Factor - I will not Ship Shit January 14 (C) Nitin Bhide 3
Acknowledgement  These ‘Thumb Rules’ my adaptation of David Kelly’s Art of Innovation applied to Software Development. January 14 (C) Nitin Bhide 4
OBSERVE AND UNDERSTAND YOUR CUSTOMER January 14 (C) Nitin Bhide 5
Find out who is your customer.  If you are developing a product, End User is your customer  If you are developing a library, Application Developer is your customer January 14 (C) Nitin Bhide 6
Understand the your customers needs Understand the your customers needs and not just expectations  Customer may have unreasonable expectations but his needs are real.  Needs and expectations can be totally different.  Once you understand the need, you can give satisfactory solutions  January 14 (C) Nitin Bhide 7
What are the current pain areas ?  Observe how customer is using an existing application  What are the current pain areas ? ◦ Is Performance a problem ? ◦ Is user interface /API a problem (cryptic, confusing, too many alternatives)? ◦ Is he trying to fit rectangular peg in round hole ? January 14 (C) Nitin Bhide 8
MAKE IT GOOF PROOF January 14 (C) Nitin Bhide 9
Make it Goof Proof  Remember that your Customer is Human. ◦ Hence he is bound to make mistakes at times. ◦ If you make sure that mistakes are caught early, you are making him productive.  Don’t violate commonly accepted conventions. ◦ E.g.. Don't put File Button at the end of Menu bar. January 14 (C) Nitin Bhide 10
Examples of ‘Make it Goof Proof’ ◦ Application Developers  Undo,  Error messages/recovery,  AutoSave features ◦ Library Developers :  Use assertions  Give attention to error handling  Provide logging and support for easier debugging January 14 (C) Nitin Bhide 11
FIRST, DO NO HARM January 14 (C) Nitin Bhide 12
First, Do No Harm  Doctors principle applied to Software  Take the pain/struggle/frustration out of your product, you will WIN over the customer.  Ensure that customer doesn't loose his data under any circumstances. January 14 (C) Nitin Bhide 13
Examples Clearly separate Inputs and Outputs for functions.  Avoid using same variable for input and output  If using same variable, do not change it unless your function is successful.  In C++, Use ‘const functions’ and ‘const variables’.  January 14 (C) Nitin Bhide 14
ADD GREAT EXTRAS January 14 (C) Nitin Bhide 15
Add Great Extras  At times, ‘Adding a Great Extra’ may make or break a product. ◦ The Extra can be someone else’s product added to your mix. ◦ The Extra can be something you have developed. January 14 (C) Nitin Bhide 16
Examples Visual C++ is popular not because the Compiler is best, but because IDE easier to use.  Support for multiple CAD file formats for CAD Application.  Add Support for writing Addins to the application  Giving a Installer/Uninstaller rather than ‘installation instructions sheet’.  January 14 (C) Nitin Bhide 17
Examples Support to multiple compilers to your library  Using a third party library (Geometry Kernel, Standard Template Library etc).  ◦ E.g. ‘This library is available on ACIS or Parasolid’ – Great. Customer’s efforts/cost/development time are reduced. Adding a Debugging support.  Making Sources available (for free or for fee)  ◦ Source availability is a ‘Great Extra’ for all Open Source software January 14 (C) Nitin Bhide 18
BEWARE OF FEATURE CREEP January 14 (C) Nitin Bhide 19
Beware of Feature Creep  Adding unnecessary bells & whistles complicates software ◦ It will make it difficult to design and implement.  If your users are struggling with manual trying to find how to do a common task, something is wrong with the product.  Simplicity is Essential. January 14 (C) Nitin Bhide 20
Beware of Feature Creep  Challenge every feature. ◦ For every feature, ask ‘why?, why?, why?’  Chuck out preconceptions of ‘how complex’ something needs to be ? January 14 (C) Nitin Bhide 21
Beware of Feature Creep  Spend more time driving your own product. ◦ Try ‘driving’ them as if you are trying them for the first time. ◦ Understand which features are ‘necessary’ and which are not ◦ You are having problems using the software definitely your users will have problems ◦ If you don’t like Unit Testing your product, mostly likely your users won’t like to test it either January 14 (C) Nitin Bhide 22
STRIVE FOR SIMPLICITY January 14 (C) Nitin Bhide 23
One click is Simple Than Two  Make your product Faster and Simpler to use then it has a better chance of success.  Don’t let Cloud of features Blur the most common use of your product.  Target for average common user and have advanced features available for experts. January 14 (C) Nitin Bhide 24
Strive for SIMPLICITY In Architecture Design,  In Coding  In API Design  In User Interface  In Documentation  January 14 (C) Nitin Bhide 25
Examples  Amazon.com – Its simple one click ordering process is a major of factor to make is popular  Pop Up /Context Sensitive Menu – Most needed tasks are available on single click on ‘third button’.  Drag/Drop File Open January 14 (C) Nitin Bhide 26
Examples  Visual Installers rather than install scripts/documents. ◦ InstallShield and Wise created a Industry around a simple user need.  Give a simple basic API and separately give advanced API.  Maintain the consistency of API. January 14 (C) Nitin Bhide 27
HAVE A BACKSTAGE PASS January 14 (C) Nitin Bhide 28
Have a Backstage Pass  Give your customer a view of what is happening behind the scene.  This gives them a sense of security.  Also provides them a view of what will work and what won’t work. January 14 (C) Nitin Bhide 29
Examples  Facility to provide detailed logs from the application or library  Details of implemented/used algorithms  Document format of the support files  A Progress Bar is a classic example of ‘a backstage pass’ January 14 (C) Nitin Bhide 30
COMMON PRACTICE IS NOT ALWAYS COMMON SENSE January 14 (C) Nitin Bhide 31
Common Practice is NOT ALWAYS Common Sense  Yesterdays Common Sense typically becomes today’s Common Practice  Common Practices doesn't necessarily mean its Common Sense in Today’s circumstances and context  Following Common Practice WITHOUT Understanding the Context is a recipe for disaster January 14 (C) Nitin Bhide 32
Classic Example  ‘For Portable code, Don’t use templates or STL’ ◦ Common Sense 10 years back ◦ Common Practice Today (not a Common Sense Any More) January 14 (C) Nitin Bhide 33
Classic Example  Circumstances 10 years back. ◦ C++ Compiler on most of Unix platforms did not support templates or STL ◦ Templates and STL are NOT part of C++ standard. ◦ Inconsistencies between different implementations of templates and STL  Hence, Don’t Use STL is a Common Sense 10 years back. January 14 (C) Nitin Bhide 34
Classic Example  Circumstances Today ◦ Templates and STL are Part of C++ Standard ◦ All compilers support templates and STL ◦ Still few inconsistencies in template implementation on different platforms  The Common Sense Today– Use STL and Carefully use Templates January 14 (C) Nitin Bhide 35
Other Examples of ‘Common Practices’  “Starting a new Project ?” ◦ ◦ ◦ ◦ ◦ ◦ ◦  “Use COM” “Use ActiveX” “Use Java” “Use XML” “Use Web Services” “Use RUP” “Use UML” The Latest “Use Agile” January 14 (C) Nitin Bhide 36
PASSION FACTOR January 14 (C) Nitin Bhide 37
The Passion Factor  All the above Thumb rules are useless if there is NO PASSION.  Passion Fuels the Fire  ‘Passion for work’, ‘Passion for Quality’ are prerequisite to make sure that all other Thumb Rules happen. January 14 (C) Nitin Bhide 38
The Passion Factor  For A Passionate Team, Nothing is Impossible.  Passionate Teams need ‘a tangible goal’. Something to shoot for and Be Proud Of.  Passionate Teams need ‘Recognition’ of the efforts to sustain and fuel the ‘passion’ January 14 (C) Nitin Bhide 39
The Passion Factor Only a Passionate Leader can Nurture and Sustain a Passionate Team January 14 (C) Nitin Bhide 40
References  Art of Innovation – Tom Kelly January 14 (C) Nitin Bhide 41

More Related Content

Common Sense Software Development

  • 1. Thinking Craftsman’s Thumb Rules for Common Sense Software Development Nitin Bhide http://thinkingcraftsman.in
  • 2. The Thumb Rules Observe and Understand your customer Make it Goof Proof First, Do no Harm Add Great Extras Beware of Feature Creep January 14 (C) Nitin Bhide 2
  • 3. The Thumb Rules … Strive for SIMPLICITY Have a Backstage Pass Common Practice is NOT ALWAYS Common Sense The Passion Factor - I will not Ship Shit January 14 (C) Nitin Bhide 3
  • 4. Acknowledgement  These ‘Thumb Rules’ my adaptation of David Kelly’s Art of Innovation applied to Software Development. January 14 (C) Nitin Bhide 4
  • 6. Find out who is your customer.  If you are developing a product, End User is your customer  If you are developing a library, Application Developer is your customer January 14 (C) Nitin Bhide 6
  • 7. Understand the your customers needs Understand the your customers needs and not just expectations  Customer may have unreasonable expectations but his needs are real.  Needs and expectations can be totally different.  Once you understand the need, you can give satisfactory solutions  January 14 (C) Nitin Bhide 7
  • 8. What are the current pain areas ?  Observe how customer is using an existing application  What are the current pain areas ? ◦ Is Performance a problem ? ◦ Is user interface /API a problem (cryptic, confusing, too many alternatives)? ◦ Is he trying to fit rectangular peg in round hole ? January 14 (C) Nitin Bhide 8
  • 9. MAKE IT GOOF PROOF January 14 (C) Nitin Bhide 9
  • 10. Make it Goof Proof  Remember that your Customer is Human. ◦ Hence he is bound to make mistakes at times. ◦ If you make sure that mistakes are caught early, you are making him productive.  Don’t violate commonly accepted conventions. ◦ E.g.. Don't put File Button at the end of Menu bar. January 14 (C) Nitin Bhide 10
  • 11. Examples of ‘Make it Goof Proof’ ◦ Application Developers  Undo,  Error messages/recovery,  AutoSave features ◦ Library Developers :  Use assertions  Give attention to error handling  Provide logging and support for easier debugging January 14 (C) Nitin Bhide 11
  • 12. FIRST, DO NO HARM January 14 (C) Nitin Bhide 12
  • 13. First, Do No Harm  Doctors principle applied to Software  Take the pain/struggle/frustration out of your product, you will WIN over the customer.  Ensure that customer doesn't loose his data under any circumstances. January 14 (C) Nitin Bhide 13
  • 14. Examples Clearly separate Inputs and Outputs for functions.  Avoid using same variable for input and output  If using same variable, do not change it unless your function is successful.  In C++, Use ‘const functions’ and ‘const variables’.  January 14 (C) Nitin Bhide 14
  • 15. ADD GREAT EXTRAS January 14 (C) Nitin Bhide 15
  • 16. Add Great Extras  At times, ‘Adding a Great Extra’ may make or break a product. ◦ The Extra can be someone else’s product added to your mix. ◦ The Extra can be something you have developed. January 14 (C) Nitin Bhide 16
  • 17. Examples Visual C++ is popular not because the Compiler is best, but because IDE easier to use.  Support for multiple CAD file formats for CAD Application.  Add Support for writing Addins to the application  Giving a Installer/Uninstaller rather than ‘installation instructions sheet’.  January 14 (C) Nitin Bhide 17
  • 18. Examples Support to multiple compilers to your library  Using a third party library (Geometry Kernel, Standard Template Library etc).  ◦ E.g. ‘This library is available on ACIS or Parasolid’ – Great. Customer’s efforts/cost/development time are reduced. Adding a Debugging support.  Making Sources available (for free or for fee)  ◦ Source availability is a ‘Great Extra’ for all Open Source software January 14 (C) Nitin Bhide 18
  • 19. BEWARE OF FEATURE CREEP January 14 (C) Nitin Bhide 19
  • 20. Beware of Feature Creep  Adding unnecessary bells & whistles complicates software ◦ It will make it difficult to design and implement.  If your users are struggling with manual trying to find how to do a common task, something is wrong with the product.  Simplicity is Essential. January 14 (C) Nitin Bhide 20
  • 21. Beware of Feature Creep  Challenge every feature. ◦ For every feature, ask ‘why?, why?, why?’  Chuck out preconceptions of ‘how complex’ something needs to be ? January 14 (C) Nitin Bhide 21
  • 22. Beware of Feature Creep  Spend more time driving your own product. ◦ Try ‘driving’ them as if you are trying them for the first time. ◦ Understand which features are ‘necessary’ and which are not ◦ You are having problems using the software definitely your users will have problems ◦ If you don’t like Unit Testing your product, mostly likely your users won’t like to test it either January 14 (C) Nitin Bhide 22
  • 23. STRIVE FOR SIMPLICITY January 14 (C) Nitin Bhide 23
  • 24. One click is Simple Than Two  Make your product Faster and Simpler to use then it has a better chance of success.  Don’t let Cloud of features Blur the most common use of your product.  Target for average common user and have advanced features available for experts. January 14 (C) Nitin Bhide 24
  • 25. Strive for SIMPLICITY In Architecture Design,  In Coding  In API Design  In User Interface  In Documentation  January 14 (C) Nitin Bhide 25
  • 26. Examples  Amazon.com – Its simple one click ordering process is a major of factor to make is popular  Pop Up /Context Sensitive Menu – Most needed tasks are available on single click on ‘third button’.  Drag/Drop File Open January 14 (C) Nitin Bhide 26
  • 27. Examples  Visual Installers rather than install scripts/documents. ◦ InstallShield and Wise created a Industry around a simple user need.  Give a simple basic API and separately give advanced API.  Maintain the consistency of API. January 14 (C) Nitin Bhide 27
  • 28. HAVE A BACKSTAGE PASS January 14 (C) Nitin Bhide 28
  • 29. Have a Backstage Pass  Give your customer a view of what is happening behind the scene.  This gives them a sense of security.  Also provides them a view of what will work and what won’t work. January 14 (C) Nitin Bhide 29
  • 30. Examples  Facility to provide detailed logs from the application or library  Details of implemented/used algorithms  Document format of the support files  A Progress Bar is a classic example of ‘a backstage pass’ January 14 (C) Nitin Bhide 30
  • 31. COMMON PRACTICE IS NOT ALWAYS COMMON SENSE January 14 (C) Nitin Bhide 31
  • 32. Common Practice is NOT ALWAYS Common Sense  Yesterdays Common Sense typically becomes today’s Common Practice  Common Practices doesn't necessarily mean its Common Sense in Today’s circumstances and context  Following Common Practice WITHOUT Understanding the Context is a recipe for disaster January 14 (C) Nitin Bhide 32
  • 33. Classic Example  ‘For Portable code, Don’t use templates or STL’ ◦ Common Sense 10 years back ◦ Common Practice Today (not a Common Sense Any More) January 14 (C) Nitin Bhide 33
  • 34. Classic Example  Circumstances 10 years back. ◦ C++ Compiler on most of Unix platforms did not support templates or STL ◦ Templates and STL are NOT part of C++ standard. ◦ Inconsistencies between different implementations of templates and STL  Hence, Don’t Use STL is a Common Sense 10 years back. January 14 (C) Nitin Bhide 34
  • 35. Classic Example  Circumstances Today ◦ Templates and STL are Part of C++ Standard ◦ All compilers support templates and STL ◦ Still few inconsistencies in template implementation on different platforms  The Common Sense Today– Use STL and Carefully use Templates January 14 (C) Nitin Bhide 35
  • 36. Other Examples of ‘Common Practices’  “Starting a new Project ?” ◦ ◦ ◦ ◦ ◦ ◦ ◦  “Use COM” “Use ActiveX” “Use Java” “Use XML” “Use Web Services” “Use RUP” “Use UML” The Latest “Use Agile” January 14 (C) Nitin Bhide 36
  • 38. The Passion Factor  All the above Thumb rules are useless if there is NO PASSION.  Passion Fuels the Fire  ‘Passion for work’, ‘Passion for Quality’ are prerequisite to make sure that all other Thumb Rules happen. January 14 (C) Nitin Bhide 38
  • 39. The Passion Factor  For A Passionate Team, Nothing is Impossible.  Passionate Teams need ‘a tangible goal’. Something to shoot for and Be Proud Of.  Passionate Teams need ‘Recognition’ of the efforts to sustain and fuel the ‘passion’ January 14 (C) Nitin Bhide 39
  • 40. The Passion Factor Only a Passionate Leader can Nurture and Sustain a Passionate Team January 14 (C) Nitin Bhide 40
  • 41. References  Art of Innovation – Tom Kelly January 14 (C) Nitin Bhide 41