Products = Mess - How to avoid it? By Suman Mukherjee

Products = Mess - How to avoid it? By Suman Mukherjee

• 1.
  Products == Mess How to avoid it? -By Suman Mukherjee Saturday, September 29, 12
• 2.
  Is your productbecoming like this? Courtesy - http://www.flickr.com/photos/ adamcathro/1035741023/sizes/m/in/photostream/ Saturday, September 29, 12
• 3.
  Symptoms Takes too long to fix bugs? Takes too long to deploy bug fixes? Takes too long to build features? Spend too much time doing QA? You completely depend on one developer for core features in your app? Developers are more interested in working on new features than modifying of existing ones? You are not aware of how to use certain features in your app? Saturday, September 29, 12
• 4.
  Stay on thesame page Understand your domain Capture the language of the domain Formulate a vocabulary Management, marketing and tech team - all on the same page Saturday, September 29, 12
• 5.
  Specify specify specify Do not jump into features Invest time to gather all information for a feature Specify behavior of the system Unspecified behavior leads to bugs Saturday, September 29, 12
• 6.
  Lessons from specification Behavior is too complicated to specify == Hard to use Too many preconditions == Hard to use Too many fail safes == Numerous bugs Don’t know what to specify == Take a nap & rethink Saturday, September 29, 12
• 7.
  Core should beSOLID Single Responsibility - A class should have one and only one reason to change Open Closed - Open for extension, closed for modification Liskov substitution - Derived objects should be able to substitute parent objects Interface Segregation - Small interfaces that cater to specific clients Dependency Inversion - Depend on abstractions not concretions Saturday, September 29, 12
• 8.
  Quick Code review Classes with single responsibilities Small methods Meaningful method and variable names Common classes reside in single namespace Minimal use of global states and/or singletons Saturday, September 29, 12
• 9.
  Code for humans Avoid super smart code that only you understand Avoid monkey patches Raise meaningful errors Keep things private unless needed publicly Document the code Saturday, September 29, 12
• 10.
  Build like aframework developer Identify common reusable behaviors Build libraries/interfaces to support them Leave callbacks for customizations Test your libs thoroughly Use your libs for customized app specific logic Saturday, September 29, 12
• 11.
  Why so AntiYAGNI? Cause the product grows and complexities creep in Cause you will always have good developers and not so good developers in your team Cause at some point of time you will have scalability issues Cause you might out source some of your work Cause you might want to open source some stuff Saturday, September 29, 12
• 12.
  Test test test Do not behave like a caveman and do manual QA Be always ready to deploy Be confident of what you build Humans are more intelligent than machines, make them do something useful Do not rush features without tests cause they’ll come back and bite you Saturday, September 29, 12
• 13.
  Deploy deploy deploy Let every one in your team deploy Let everyone have access to the servers Deploy multiple times a day or at least once a day Do not deploy right before the week end Saturday, September 29, 12
• 14.
  Project management Use a tool that you know well Follow a school that you understand Do not get excited like a kid with every new tool Do not change workflow all of a sudden. Make slow and continuous changes Saturday, September 29, 12
• 15.
  Metrics Collect metrics that matter Data can be both quantitative and qualitative Don’t collect and forget. Monitor and learn. Saturday, September 29, 12
• 16.
  Successful technical teamsdeliver good quality software consistently. Successful entrepreneurs solve problems of customers, not their own. Saturday, September 29, 12
• 17.
  Thank You Follow me - @mukherjeesuman or Email me - [email protected] Saturday, September 29, 12