It is no secret that the Linux community keeps a close watch on Microsoft. Even though the once-mighty OS giant from Redmond isn’t the force that it used to be, many still like to keep an eye out for Microsoft not “eating its own dog food” and using its tools and Windows operating system for its own business needs.
After all, Microsoft’s tool suites and platforms have overwhelmingly been geared toward the B2B market, and so they should be ideal for the company’s own needs, right? However, as long as there has been Linux/Windows feuding, stories such as this, from 2003, that points out that Microsoft used Akamai’s Linux-based site acceleration service, typically generate waves in the tech blogosphere. Of course, the purpose of mentioning this is not to rip on Microsoft, but to demonstrate that it can be a source of embarrassment when a company does not trust its own tools, and even opts to use the tools of its competitor even when it is considered the leader in the problem domain. Not only does expressing the willingness to use a product internally build high confidence in it with the public, it also has other advantages: Historical Pattern of Successful Technologies
One interesting trait of technologies that have succeeded with the larger public, such as programming languages, is that often they were developed for the use of their creators to solve internal problems.
A good example is C, developed in-house use at Bell Labs as a programming environment for Unix, as opposed to Ada, which was developed for a general market and never flourished as a language.
Lean Approach to Testing Testing is an expensive but necessary practice, and it often results in some duplicated effort and communication headaches. However, say that you are a VoIP telecommunications provider with large network and a globally distributed workforce. If you use that VoIP platform to connect your employees, you are essentially having your personnel double as field testers with no added costs to either the employees or the company. For a lean startup, dedicated test teams are often out of scope and budget, and therefore this approach can work as an alternative. On top of this, a startup that continues to use an internal technology even after it grows implicitely demonstrates the product's scalability.
