When to Build and When to Buy

  • 1,201 views
Uploaded on

 

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,201
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
11
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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