2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- November 7, 2018
- Rants
One question that I hear a lot of people asking is whether they should buy or build the software that they need to run their enterprise. This is often a difficult question to answer. One thing I can say having lived through many major software purchases is that the main cost was understanding a system that was purchased and that cost of understanding turned out to be far greater than expected. Large, expensive software products are often more costly to purchase then the price tag would indicate.
If you can gain a competitive edge through embodying it in software then it’s almost always better to build rather than to buy. This applies to entire products. Technology companies are sometimes purchased because of their customer base or inroads into a particular market segment or any number of other reasons. Of course, I’m not talking about off-the-shelf software. I’m talking about integrating essential components that were not developed in-house.
When we purchase a codebase we also often purchase all of the headaches and shortcomings in that system. It’s very difficult for most engineers to discern where a system’s strengths and weaknesses are and therefore they are not able to accurately evaluate the value of the system. Of course, a system’s value depends on many things, not least of which is the market, but the quality and flexibility of the system and how it was written is certainly an important aspect of its value.
On the other side of the spectrum, developers often “borrow” snippets of code from the development community to build projects rather than reinvent the wheel each time. The Open Source movement allows developers to reuse other people’s code and learn from how they do things. Thanks to the Internet we can access source code in virtually any language and draw from repositories that let us quickly build systems.
The main problem with buying a foreign codebase is that you can get the source code and even the documentation but the process of building the software gave us the greatest benefit, which is understanding the problem so that we could build the solution. Without gaining that intimate understanding of the problem needed to code a solution, software is often not as valuable. Software that is opaque is difficult to change in the ways needed to fix bugs or add features. Without the ability for the software to change, its usefulness is often greatly reduced.
Outsourcing software development is the same problem. Often the understanding gained through building software is not propagated throughout an organization when it outsources its software development as broadly as when development is done in-house. Outsourcing often works best when remote teams partner with local teams and do things like pair programming and writing acceptance tests together.
Software development is engagement and discovery. When you’re building something that has never been done before it is useful to get as much feedback as possible so building a system in-house makes a lot of sense. If what you need is something that is fairly common and you’re certain you can find exactly what you need then it makes sense to buy it.
Previous Post: « More on Test-Driven Development
Next Post: Rebuild or Refactor »