While the world of marketing is full of \u201cbest practices\u201d and universal truisms, engineers tend to think in terms of trade offs. That is, this approach creates these problems and that approach creates those problems, and I value this over that, so I have made my choice. The\u00a0Agile Manifesto<\/a>\u00a0may be one of the best examples of speaking in this language of tradeoffs, and it changed the way the world does software.<\/p>\n Today, I\u2019d like to briefly introduce another one, the New Jersey School versus the MIT school of software design, as described in Richard Gabriel\u2019s\u00a0Worse is Better<\/a>, and go on to explain how that relates to the debate of our time \u2013 the Adaptive Tools Vs. The West Coast approach to software testing.<\/p>\n A real debate about software design should include both sides, represented accurately. In\u00a0Worse is Better<\/a>, Richard Gabriel presented the MIT approach as \u201cbetter,\u201d and his approach, the \u201cNew Jersey Approach,\u201d as \u201cworse.\u201d The MIT approach is to build feature-complete software that can handle its own errors, while the New Jersey approach is to make good enough software that gets into the hands of the users quickly. Of course that is a vast oversimplification, please, go read the original essay. Today I will cut to Gabriel\u2019s conclusion:<\/p>\n The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing.<\/em><\/strong><\/p>\n Imagine if we could talk about testing this way. Not in terms of the \u201cright\u201d approach, but which one will be easier to adopt and, once adopted, easier to grow and improve.<\/p>\n The results of that might shock you.<\/p>\n Getting testing closer to development has been a consistent trend I have seen, dating back to when the Manifesto was created in 2001. This makes sense. Development moved from desktop to web to mobile, and along with that came the ability to \u201cpush\u201d new code to production at any time. With physical disks in boxes, it might make sense to have a \u201cgolden master\u201d that was tested extensively. Today, new changes can push in minutes, and with the right infrastructure, be rolled back in minutes as well. That means a three-month test\/release cycle just isn\u2019t feasible. Today, I see testers embedded in the teams, taking the new features built by the programmers in the morning and testing in the afternoon. In some cases, the developer and tester work side-by-side on a project.<\/p>\n The extreme end of this is to eliminate the tester entirely, and simply have the programmer do the testing. In this world, testing is always \u201ccaught up\u201d with programming, as the two happen within the same feedback loop. Programmers typically write test code inside the same version control system, so everything is versioned together. Features are done when they have\u00a0running tested features<\/a>, and testing includes automation. This school is emphasized in Silicon Valley, where development managers are typically programmers, and the organization typically exists in order to ship software. At Facebook, Google, Twitter, and Microsoft, the software is the product. In this world, testers look a lot like a cost center. Any executive that can eliminate a large department is likely to see quite the bonus. When Yahoo\u00a0eliminated testing and QA<\/a>\u00a0five years ago, people took notice.<\/p>\n Then there are the companies that do not produce software for a living, that have customers that pay real money for physical objects, where the store is only one component of the business. Insurance companies, banks, brick and mortar retailers, manufacturers who need to ship inventory and put it on a shelf are a lot more cautious. Having Facebook, a product you do not pay for, down for a bit is considerably different than sending a truck with\u00a0the wrong product to the wrong location<\/a>. These companies see a difference between the builder job of programmer, and the breaker\/evaluator job of testing.\u00a0They typically see the tester as customer advocate and expert breaker.<\/em><\/strong>\u00a0This person is unlikely to be a programmer. If test artifacts exist, they would like them to be understandable by a wider group, not a more narrow one. This group sees code written that produces more code as a jumble of confusion, lacking any visualization of coverage or accountability. The automation tools that visualize the flow, that can be read by a \u201cmere mortal\u201d are appealing. These tools allow for a more classic tester\/subject matter expert role to continue to exist, while speeding testing up. This group of people values their ability to do independent assessment and actually want to do testing, as opposed to programmers, who, well, don\u2019t.<\/p>\n The folks pursuing end-to-end, adaptive tools might be doing the \u201cwrong thing\u201d according to certain standards of computer science. But their outcomes are better. For them, as Gabriel said so well, \u201cWorse is better.\u201d<\/p>\n There are other ways to think about testing. If all of your software consists of small, independent elements that can be tested and released separately, then you might\u00a0not need automation at all<\/a>.<\/p>\n The West Coast approach seems to be working \u2026 on the West Coast \u2026 for certain sets of technology companies. Will it work for you?<\/p>\nWorse is Better<\/h3>\n
West Coast Style Vs. Adaptive Tools<\/h3>\n
Tomorrow<\/h3>\n