Since the dawn of software, more or less, companies wrote their software in a process that went something like this: Product defines the specifications. Architecture designs it. Engineering/R&D builds it. Quality Assurance (QA) tests it. If it passes, it is scheduled for release; if not, goto #3. The jobs of QA teams historically have been procedure-oriented. Whereas engineers tend to be more creative and inventive, QA teams provide the process and constraints (remember the term "

In the last week, I have had several discussions with some really smart technologists, partially focused on what makes technology companies nimble and fast and, therefore, great. In the last article, we discussed hiring 10x people, and especially the way many great employees compound together to create up to 2 orders of magnitude faster companies. However, hiring really smart employees is necessary, but it is not sufficient. What these employees need is independence.

A few weeks ago, "Lies, Damned Lies and Performance Tests," gave us a great example of how even a good performance test can be ruined through a few (seemingly) small mistakes. Today, let's revisit performance tests with an example of performance tests that I constructed on behalf of a client, as an example of how to do them correctly. Even good performance tests suffer from a paradox. On the one hand, you really want to understand how the product will perform in the real world, with all of its environmental conditions.

Mark Twain attributed the phrase "Lies, Damned Lies and Statistics" to British Prime Minister Benjamin Disraeli, which suits the Prime Minister's known wit, although its provenance has been questioned. If Twain or Disraeli had lived in the days of computers and software, he probably would have coined the phrase as "Lies, Damned Lies and Performance Tests." Perhaps Twain's great novel of Americans touring the desolate Holy Land of the late 19th century might have been called, "

When do you buy? When do you build? This question of "buy vs. build" is at the heart of many a debate in companies, not only inside engineering teams, but between engineering, product management and executives. Fact #1: Engineering is Hard Engineering is very hard. Despite the enormous advances over the years, and the number of system tools and development frameworks and languages, every one of which is touted as a "