Your SlideShare is downloading. ×
When to Build and When to Buy
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

When to Build and When to Buy


Published on

Published in: Technology, Business

  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. When to Build and When to Buy
    October 4, 2009
    Software Engineer –
  • 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