Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

When to Build and When to Buy


Published on

Published in: Technology, Business
  • Be the first to comment

When to Build and When to Buy

  1. 1. When to Build and When to Buy<br />October 4, 2009<br />PoornimaVijayashanker<br />Software Engineer –<br />Blog:<br />Contact:<br />
  2. 2. Agenda<br /><ul><li>Motivation
  3. 3. Understand the business problem and your business needs
  4. 4. Business problem becomes an engineering problem
  5. 5. Cost of Building
  6. 6. When to Build
  7. 7. Cost of Buying
  8. 8. When to Buy
  9. 9. Tips for Building Quickly
  10. 10. Q&A</li></li></ul><li>Motivation<br /><ul><li>Resource constrained in an organization – don’t want to waste money or time, especially during a recession!
  11. 11. Need insight into your data or automate a repetitive process
  12. 12. 1. Build software solution yourself
  13. 13. 2. Buy software solution: shrink wrapped, web service, contractor, consultants
  14. 14. Expose the tradeoffs associated with each of these choices.
  15. 15. Bridge both the business and engineering issues</li></li></ul><li>Questions to answer to understand the business problem and your needs<br /><ul><li>What are you requirements?  
  16. 16. What is that you are trying to get done?
  17. 17. e.g. measure user issues, marketing emails, data aggregation
  18. 18. What are you costs?  
  19. 19. Cost per user, scale, security, and reliability
  20. 20. Time to market
  21. 21. Easy to get sucked into a sales pitch.
  22. 22. Anticipate need because contracts are based on usage</li></li></ul><li>Understand how the business problem translates to an engineering problem<br /><ul><li>e.g. tool to track metrics or keep track of user issues, mail server is a business need that satisfies customers needs.  
  23. 23. Engineering problems:
  24. 24. Maintenance: users will experience new problems that must be tracked,
  25. 25. Scale: it will become slow as the number of users grow
  26. 26. Security: it will need to be hosted on a secure server if it contains user specific or sensitive data
  27. 27. A mail server or any hardware solution has similar issues:
  28. 28. Cost of configuration
  29. 29. Reliability & backups
  30. 30. Graceful failover
  31. 31. Given how business problems turn into engineering problems it might seem like a feat to build and maintain than buy.</li></li></ul><li>
  32. 32. Cost of Building<br /><ul><li>List of features you want to build and have a functional spec
  33. 33. Hand off spec to developers to scope and break down
  34. 34. Breakdown of developers time:
  35. 35. New technology (e.g Flex, iPhone app, etc.) requires ramp up
  36. 36. Designing – features, database schema, and where it should be housed if it is a full app
  37. 37. Developing & Testing
  38. 38. Deploying and ongoing maintenance or optimizations if it sucks a lot of system resources!
  39. 39. Similar to regular release cycle!</li></li></ul><li>When to Build<br /><ul><li>Build the tool once you spot the need and include it into a product release cycle
  40. 40. Benefits of building:
  41. 41. In house developers have a vested interest.
  42. 42. Understand the problem and requirements and how it fits in with the rest of the business.
  43. 43. Investing time to learn a new technology or framework can then be leverage in future projects.
  44. 44. Drawback: takes time away from developing product features.</li></li></ul><li>Cost of Buying<br /><ul><li>Hiring a contractor
  45. 45. Understand the business needs, and be aware of the technology
  46. 46. Integrate code into your current system, may require additional APIs, understand data architecture
  47. 47. Need to be managed.
  48. 48. Working on multiple projects, less responsiveness, and focused on speed.
  49. 49. Code quality, maintainability, and addressing security issues.
  50. 50. Developers have to maintain the tool after the contractor is done.
  51. 51. Buying packaged software or software as a service
  52. 52.  Limits options to what is built. Pay for enhancements. You will have to keep an ongoing relationship.
  53. 53. You will still need to assign a developer or product manager to communicating the needs of the project.  
  54. 54. Web service reliability.
  55. 55. Want to assess quality of the data you are receiving</li></li></ul><li>When to Buy<br /><ul><li>Hire a contractor: when limited by number of developers or by their skill set
  56. 56. Software Consultants
  57. 57. Benefits of establishing an ongoing relationship:
  58. 58. Consultants have spent a lot of time learning a particular field such as web security, databases, or data warehousing     
  59. 59. They keep up with the latest trends in industry
  60. 60. Do research on the side, and publish papers
  61. 61. Large customer base, they will have had a lot of experiences that make them good problem solvers
  62. 62. In house developers who have only been looking at a single code base for a few years.  </li></li></ul><li>When to Buy<br /><ul><li>Benefits of establishing an ongoing relationship continued:
  63. 63. Bring in a consultant to educate your team.
  64. 64. The consultants solve problems and provide resources.
  65. 65. Your developers implement the solution.  
  66. 66. Builds up your team's knowledge base
  67. 67. In house developers become responsible for of building, but know how to maintain it!</li></li></ul><li>Tips for Building Quickly<br /><ul><li>Java is slow!
  68. 68. For pulling data or getting metrics Python is a good solution
  69. 69. Create a reusable template for UI development
  70. 70. YUI has a lot of good UI components
  71. 71. FreeMarker is faster for HTML development
  72. 72. Try open source or free product like
  73. 73. e.g. Google Analytics</li>