Date post: | 01-Nov-2014 |
Category: |
Documents |
Upload: | webgeek-philippines |
View: | 1,122 times |
Download: | 4 times |
Products == Mess
How to avoid it?
-By Suman Mukherjee
Saturday, September 29, 12
Is your product becoming like this?
Courtesy - http://www.flickr.com/photos/adamcathro/1035741023/sizes/m/in/photostream/
Saturday, September 29, 12
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
Stay on the same 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
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
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
Core should be SOLID
Single Responsibility - A class should have one and only one reason to changeOpen Closed - Open for extension, closed for modificationLiskov substitution - Derived objects should be able to substitute parent objectsInterface Segregation - Small interfaces that cater to specific clientsDependency Inversion - Depend on abstractions not concretions
Saturday, September 29, 12
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
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
Build like a framework 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
Why so Anti YAGNI?
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
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
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
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
Metrics
Collect metrics that matter
Data can be both quantitative and qualitative
Don’t collect and forget. Monitor and learn.
Saturday, September 29, 12
Successful technical teams deliver good quality software consistently.
Successful entrepreneurs solve problems of customers, not their own.
Saturday, September 29, 12