Making the Business Case for Best Practices

What Is a "Best Practice," Anyway?
Hi, this is Erik Dietrich presenting on behalf of Pluralsight. Welcome to this course entitled Making the Business Case for Best Practices. This first module briefly addresses the idea of a best practice by defining it and talking about ambiguity that surrounds the term. In the first module I'm going to introduce you to a concept with which you already may be acquainted: the best practice. But I'm going to offer three different classes, and in a way three different definitions of best practice, and then explain how those form a line from least- to most-rigorous. Then in this light I'll talk about some examples of best practices in the software industry and what it means that these are considered to be best practices. I'll then wrap up by using this context to elaborate on the aim of this course.

And What Is a Business Case?
Hi, this is Erik Dietrich presenting on behalf of Pluralsight. Welcome to this course entitled Making the Business Case for Best Practices. This second module will address what it actually means to make a so-called business case before we move on to actually making business cases in subsequent modules. The material for this course will fall into three basic categories. The first category is business and business case basics, and there I'll cover the topics of defining a business case simply, the purpose of a business, revenue and expense, expense types, payback period, opportunity cost, and finally return on investment. The next category is more advanced topics about business cases such as odds and expected value, estimating costs and benefits, using external resources, and the psychological advantage to speaking the same language as management types. In the third category I will briefly describe what the presentation format for the remainder of the course will be.

Justifying Code Inspection Practices
Hi, this is Erik Dietrich presenting on behalf of Pluralsight. Welcome to this course entitled Making the Business Case for Best Practices. This fourth module will cover making the business case for adopting various code inspection practices. Code inspection is the idea that more goes on in your group than simply writing code, checking it in, and delivering it. Someone, or something examines code for correctness, maintainability, compliance with some kind of standard, etc. The goal is to cut down on errors and issues, and keep the code as clean and maintainable as possible. First I'll talk about the practice of code reviews. Code review is a practice where team members systematically review one another's source code, looking to notice mistakes, and make suggestions for improvement. The actual logistics of this can vary fairly widely, but the common thread is human review of code by someone other than the original author. Next I'll talk about pair programming. Pair programming is the practice where two developers sit and work together on the same bit of code rather than each working individually. This is accomplished by one called the driver, operating the keyboard, while the other called the navigator looks on and offers live feedback. Finally I'll talk about the idea of automated gatekeeper code inspection. This is a practice whereby code is subjected to automated inspection generally prior to a check in. This practice allows for enforcement of certain rules and policies without the need for human intervention.

Justifying Testing Practices
Hi, this is Erik Dietrich presenting on behalf of Pluralsight. Welcome to this course entitled Making the Business Case for Best Practices. This fifth module will address making the business case for adding different types and styles of automated testing to your group's work product. Testing of the software work product for a company comes in all sorts of shapes and sizes, but I'm going to focus here on making the case for various forms of automated testing with which developers would be involved. First up is automated unit testing. These are tests that software developers write against individual classes or modules, and they are pretty fine-grained, they do not test things like the GUI, databases and files, external web services or anything else that's a bit more monolithic or end to end. Next I'll take you through making the case for writing automated GUI tests and/or integration tests. The things not covered by unit tests will be covered here. This includes tests that exercise your software more or less as a whole. Examples of GUI testing might include tools like Selenium or Cucumber, and automated integration tests might include a tool like FitNesse, or even just code that you write that exercises large parts of your application in conjunction with its external dependencies. Finally I'll discuss the Test Driven Development methodology, frequently abbreviated TDD. This is a method for developing software that results not only in a bi-product of expressive unit tests, but many would argue in better designs and more modular code in production.

Justifying Meta-Coding Practices
Hi, this is Erik Dietrich presenting on behalf of Pluralsight. Welcome to this course entitled Making the Business Case for Best Practices. This sixth module is going to cover how to make the business case for what I'm calling meta-coding practices. By this, I mean processes that analyze the nature of generating code, as opposed to the process of actually generating code. This concept is related to code inspection, but inspection is the act of checking code whereas the meta practices define the standards against which the inspections are measured. Most of us have probably experienced and conform to coding standards at some point or another. Coding standards are a set of rules or guidelines for how code should be written and look, and are generally intended to encourage standardization across groups and good practices in general. Most commonly the standards include comparably superficial things that are easy to check by simple inspection of the code, such as naming conventions. Static analysis is a deeper dive into analyzing the nature of code. Whereas coding standards trend toward the more cosmetic, static analysis trends toward providing data on the architecture and design of the application. It will answer questions like how many overly complex methods are there on average per module. Static analysis differs from the previously covered gatekeeper inspection in the sense that the analysis us usually not intended to automatically bounce code back to developers, but rather as a facilitator of broader discussions and initiatives. So the case for static analysis becomes one of not only implementing it, but also of letting its results guide ongoing code-related action items. For example, in the aforementioned case of how many overly complex methods are there, the policy goal might become, we want to reduce that number by 3% per iteration.

The Politics of Change
Hi, this is Erik Dietrich presenting on behalf of Pluralsight. Welcome to this course entitled Making the Business Case for Best Practices. This seventh and final module will focus on navigating organizational politics when making your pitch for adopting software development practices. In this course so far, we've taken an extensive look at how to go about making business cases for things that you want in terms of how to gather data, which data to gather, and how to interpret the results. In this final module, we'll take a look at the politics of making a business case, meaning that I'm going to cover the subject of who to approach, how, and when. First, I'll make the case that politics do in fact matter. In this line of work it's often easy to dismiss this consideration and say that it isn't something you should concern yourself with. The problem with that is making business cases is largely a matter of persuasion, and politics play a prominent role in effective persuasion. Next I'll cover some topics related to preparing for your pitch. This includes considerations such as thinking about why what you're proposing hasn't already been adopted, and mulling over who to include in your pitch and who not to. And finally, I'll talk about how to be successful in making the pitch and how to be in good shape even when you're through making your case.