The Buy approach simply means buying suitable "packaged" software "off the shelf". The challenge is in determining what is suitable for your needs. Vendors tend to oversell what the actual features are, and you really don't know until you're committed, sometimes with less than satisfying results.
The benefits of this approach include:
- You know the fixed costs up front.
- Upgrades are done for you under a contract that includes variable monthly costs in the form of a maintenance contract.
- You don't need to employ in-house technical expertise.
The risks of this approach include:
- You are locked into a commitment, from which it can be very hard to migrate away.
- Much of the software may be 'bloatware' that you pay for, but don't really need.
- You don't control the development path of the vendors upgrades. They may not make the enhancement that you require.
- As needs grow, you inevitably reach a scale of needs that the current software will no longer support ... and you must "throw away" and migrate.
- The code is proprietary. There is no way to see inside of it or to really "own" it.
The Make approach means you build a custom software platform "from scratch" that perfectly fits your needs.
The benefits of this approach include:
- You get as close to what you want as is possible.
- You have complete control over the enhancement upgrade path.
- There are virtually no limits to scalable growth. You may rewrite, but with a good starting design, you never "throw away".
- You have your own contracted or in-house expertise, so you don't have to depend on external support.
- You "own" your code. Well written standard code is readable by any expert. The risks of losing "star" programmers should be minimal.
The risks of this approach include:
- Development cycle takes longer for the initial design.
- Managing design quality is critical. Undisciplined and unsystematic growth can quickly turn what was a good initial design into "spaghetti".
- There is a dependency on technical software expertise.
In the Web Development software environment, we're encountering more "off-the-shelf" toolsets, that are often free, and that allow non-technical users to develop websites to their own specifications with a minimal (but not insignificant) amount of training. They tend to wrap code 'generation' with a Content Management System (CMS) to hook in the data and include popular names like WordPress, Joomla, and Drupal.
The benefits of this approach include:
- Non-technical users can create usable content.
- The user can update virtually all content on the website without technical support.
The risks of this approach include:
- The resulting code tends not to be standard, clean code. Over many iterations of updates, it gets littered with inefficient code fragments.
- Complexity scale limits can be reached.
- Being locked into a proprietary platform with limits of support.
In general, these tools are perfect for many environments, but only up to a certain scale of need. There is more often than not a point at which this approach reaches a constraint similar to the "buy" software development approach described above. The needed functionality exceeds the complexity supported by the platform. Migration to a capable platform becomes necessary.
The bottom line to this is that we specialize in the "make" approach of developing custom web sites, using clean,high quality,standard coding practices that any programming expert can support. The word "custom" is sometimes misconstrued by its association with "proprietary", "home-grown", or "hacked". To me, "custom" means "free of bounds", "open", and "adaptable".
We only use Open Source programming platforms. Specifically we use Apache for the web-server, PHP for the back-end (Server) scripting, JavaScript for front-end (Client) scripting, pure HTML, and MySQL for the database. For many years, corporations were warned against exposing themselves to the risks of "Open Source" programming tools because of the lack of technical support. I've been in the corporate world where we paid many thousands of dollars each month for proprietary support because of this belief. While this belief may have been true years ago, it is true no longer. We find there is more than ample support for all open source tools supplied by thousands of programmers out there just trying to solve problems for the greater good.
One of the main questions that arises with our approach how it supports the user's ability to dynamically edit content without technical support. We've developed our own Content Management System (CMS). Yes, it is custom. But this means we can fine tune it to allow the user to directly edit any piece of content (text or images) on any page. We design a CMS targeted to their exact needs without any extra 'fluff' that they need to learn - getting in the way. This approach is easily expandable and adaptable.
Comments or questions?