A recent podcast episode reminded me that it's a good idea to examine things from different perspectives. Doing so can expose behaviors that appear purposeful as consequences of environmental factors. You won't succeed at fixing those behaviors unless you do something about the environment that encourages them.

Today the discussion is about Test engineering and organizational practices that tend to lower the quality of your deliverables.

When reading through, please keep in mind that we're emphasizing goals that are contrary to what you expect - lower quality and customer satisfaction. The suggestions may seem cynical and counter-intuitive, but that's the point of the exercise. So let's get started.

1. Make the Test teams solely responsible for quality

One of the best ways to lower quality is by shifting focus away from the product and towards internal politics.

You want to capitalize on default human behavioral responses that minimize reasoning and maximize conflict — what better way of doing so than encouraging tribalism.

Holding only one organization responsible for a goal (no matter what it is) will guarantee the divisive behavior you're trying to obtain.

That group will spend most of its time and resources proving their responsibilities were met, instead of facilitating product goals.

To maximize the impact of this principle, make sure that Test teams only own the quality objective. They should not be responsible for determining release content, that's the Marketing team. Nor should they be involved in setting release dates, that's a Sales function. They also don't determine which problems to fix, that's up to the Product team.

You want the Development team focused on delivering features by the time the Marketing and Sales orgs promised them. So avoid imposing any code commit or merge rules requested by Test, like requiring code reviews, passing linters, passing unit tests, and others. After all, quality is Test's responsibility, not Development's.

Breaking up objectives in this way, turns meeting agendas away from customer experience and towards the blame game. You know you're on the right track when you hear statements like:

• "Why didn't you find this bug sooner!"
• "The current tests failed, but we really need to merge this new feature so you can start testing it."
• "Why didn't Test find this customer issue?"
• "We promised the customer a release by this date, so let's defer all Test findings and give them a build today."
• "We found the issue that the customer reported, but you deferred it last month!"
• "I can't run tests because you gave me a broken build."

Spending time arguing about whose job it is to do the work is an excellent mechanism to reduce satisfaction with your product or service.

2. Require all tests to be automated before releasing

Another device for distracting from quality is requiring test automation for every feature. It guarantees that your Test organization spends most of its time doing software development instead of test engineering.

The goal should change from validating a product attribute, to counting how many automated tests ran to verify it.

Rather than thinking through the test breakdown that validates various code paths or fundamentals of a function, engineers will spend time and resources executing multiple iterations of the same test. It leads to higher counts.

It also promotes a fragile test infrastructure and increases maintenance costs.

Since there's no time to consider test strategy and abstractions, they're forced to write very specific - yet brittle - workflows. Whenever Development makes slight changes to the feature, the tests break.

The Test organization must focus on producing a large number of tests as fast as possible. Otherwise, they'll have time to push more value into the product with more meaningful tests.

Make sure to reward this behavior by promoting engineers that produce the highest number of automated tests that run frequently. But don't forget about those that save time by writing scripts that execute other scripts while hard-coding all the arguments so the user won't have to type them.

3. Require 100% code coverage

Since product quality and customer experience are only correlated to code coverage, forcing your Test and Dev teams to chase 100% coverage is another tactic.

Make sure you direct all execution conversations towards the coverage measurement and hold teams accountable for it. People will focus on building tests that call all code functions, regardless of their output.

A nice bonus is that measuring coverage tends to affect timing or performance. It makes it hard for anyone to understand the actual customer experience, thereby adding to your goal of decreased satisfaction.

Make sure that tool implementations are automated, and that every report includes the coverage numbers, so it's easy to bring up in conversations.

Avoid focusing on code branching coverage. It's essential to prove that you tested every function, not every code path in the function. After all, there's no point in planning for customers to hit failure cases. They only happen a small percentage of the time.

Just like the previous section, don't forget to reward the team for being as close as possible to the 100% coverage number. It goes a long way in showing your engineers the behavior that matters.

4. Isolate the Test organization from Development

One of the worst things in software development is when the Dev team is so in-sync with Test that they finish each other's sentences. It's a red flag! It means that you're on a path for producing a quality product or service.

Reduce all chances for collaboration, including physical proximity.

Make sure to separate the teams, so it takes physical effort for a Test engineer to walk over to a Developer and ask questions. Human nature will take hold and solve the rest of the problem for you.

When both of these organizations actively collaborate, they tend to help each other considerably. You'll find the Developer gives the Tester a heads-up about new changes. Alternatively, the opposite could happen, where a Developer will know about a bug before it's reported. Not only does this break tribalism, but it sidetracks well-defined responsibilities.

Collaboration leads to less process:

• In some cases, issues are just fixed instead of reported.
• Internal documentation and knowledge transfers receive less time and attention.
• Test engineers become more knowledgeable about the product.
• Release schedules start to reflect reality during planning.

All of these lead to higher quality and better customer satisfaction! The direct opposite of your goals.

Enforcing more process is a great way of discouraging this behavior. It helps highlight the requirements that an engineer doesn't meet when directly engaging with other teams. It can come in the form of extra checkpoints and meetings, but preferably, more documentation.

Another excellent tool for increasing isolation is access controls. Make sure that Test does not have access to source code and that Dev cannot see the procedures of a test case.

I find that separating tests from code is a must! If you have both in the same repository, then Developers will know ahead of time when they break a test. A process shortcut that leads to the very efficiencies we don't want.

5. Measure the success of the process, not the product

I can't tell you how many conversations I've had with coworkers that keep asking impertinent questions about customer adoption.

Things like: How many customers are using that feature? What's the potential impact to our install base? How many steps must the user go through to use this feature? What's the attach rate? How big is our potential customer pool for that requirement? How many users asked for this function?

These folks don't get it. It's imperative to discourage this behavior as it happens. It tends to spread to other team members, and pretty soon, you'll have an organization that only cares about quality.

The best thing to do is redirect that energy by asking questions about the process instead. The items below are some stats that help accomplish this.

Number of open issues and who opened them

It helps prove how well the Test team is doing and how much work they're putting in.

Don't forget to encourage the employees that opened the highest number of issues. Bring it up in meetings often, so the rest of the folks are not surprised during performance reviews.

Some will try to argue that too many open issues lead to significant overhead in managing them. Again, that's the whole point.

Refocus team effort away from quality and towards process. Plus, if there are too few issues, then the Test org looks like their not working.

Amount of time an issue spent waiting for Test response

It's trickier to measure, but when you can pull it off, it's a great way to show how well the Test org is doing when compared to Development. It encourages behaviors that help maximize the active issue count.

To help the situation, try to tie issue status changes to process requirements that enforce particular field values for specific situations.

It reduces the time an issue spends on the Test side whenever parameters don't match because the engineer will have to ask for the correction.

Development is usually too busy to care about this stuff. So it also leads to lots of political discussions in project management meetings and encourages more tribalism.

Percentage of issues in a closed state

Before a release, you want to encourage the team to close all issues. It's best to base the performance review of Development engineers on how many issues were open against their code at release time.

It guarantees fewer defects opened by the Development team - further boosting your Test performance. It also discourages communication with the Test organization and increases friction.

Percentage of tests executed compared to an execution plan

Don't forget to make an execution curve telling the team how to spend their time throughout the test cycle. Be careful not to base it on history, or you may find that the org meets the numbers and improves quality.

Check the graph in every status meeting and ask for progress regardless of the state of the product. It forces the inclusion of tests meant to always complete just to pad the numbers and meet expectations.

Discourage anyone that beats projections. Doing so makes it look like the Test org has free time.

Measure the pass rate

You'll want to track the percent of test execution that's passing vs. failing for all the tests put together.

Make sure you explain to the team the required pass rate to reach a release stage. It reminds them to design suites with enough tests that always pass so that you can meet process requirements.

6. Require granular projections from engineers

Getting a schedule from Dev is hard. Many times they try to throw reality at the problem as if complexity mattered. The truth is you'll release by the date designated by the Sales organization regardless, but Dev never seems to understand that.

Whenever discussing code completion dates, make sure to ask for the day, not the week or the month when they'll complete. If you disagree with that date, bring it up in a public forum of all their peers so they can argue it.

Doing so accomplishes several essential points in lowering quality:

• Developers fight among themselves, reducing communication.
• They stop thinking they have a say in how to spend their days or do their jobs, which increases turnover.
• It makes it unlikely that they meet their deadlines, which lowers their performance review and also increases turnover.

Achieving high turnover is like the holy grail of lowering quality. It helps reduce the bottom line with fewer raises and promotions. It increases disinformation, emphasizing individualism. Finally, it removes any ownership that might build up in the team over time.

7. Reward quick patching instead of solving

Given enough time, engineers can solve almost every problem. But when you do the opposite, an interesting phenomenon occurs: instead of resolving the root issue, they fix the symptoms, sometimes ignoring the problem completely.

Here are some of the benefits you'll see when using this technique:

• Development gets praise for being quick.
• The base problem isn't solved, so there's a bunch of opportunities for writing future bugs, making the Test team and the process look better.
• The customer will keep running into the same issues, which translates to lower satisfaction.
• The patches for each symptom develop a spiderweb of dependencies, making future work harder and more brittle, which translates to lower quality.
• You'll gain issues for everyone you fix at a viral pace. The more problems to fix, the more process you need to track the ones left behind. Win-win!

Rewards are fundamental here as well. Make sure to incentivize this type of work with awards, and broadcast them to the team so everyone is aware of the behavior you want.

8. Plan for today instead of tomorrow

There's always someone trying to foresee what tomorrow brings. These days some engineers will do statistical analysis or machine learning. Formulating an algorithm that explains how well execution is going, which issues are important, how much time is actually needed, the number of resources required to test, etc.

Then there are the folks that have been around long enough and keep bringing up past mistakes or wasted efforts you should avoid.

Ignore that advice and always plan for the best case today. It doesn't matter if technical debt is high, if the 3rd party vendor has low quality, or if everyone planned a vacation on the same day during the next release.

Deal with problems when they occur, not before. Otherwise, efficiency will increase.

9. Conclusions

While there are many more points to cover, it seems our fictional Sales team decided to ship before completing the article!

On a more serious note, test engineering and product validation gets exponentially harder with complex systems and large organizations. It's important to incentivize the right type of behaviors in order to succeed. However, those aren't always obvious and in some cases, they're even counter-intuitive.

I do hope the article helped you observe the test world from a different perspective. One that provides some helpful insight. I find this practice of aiming for bad outcomes quite illuminating sometimes. At the very least, it's loads of fun to think through.

If you liked the article and want to read more about development best practices from Cristian Medina and others, please visit tryexceptpass.org. Stay informed with their latest content by subscribing to the mailing list.

I’ve written about how to design for the modern web before, way back in 2018. But the web moves forward quickly so those guidelines are already obsolete and outdated, as more modern conventions have become mainstream.

Let's break down and go through the most important design principles of designing for the modern web in 2019.

Let Users Know You Have A Mobile Application

This one remains the most important principle and it’s not without reason. Well paid focus groups have shown that the very first thing a user wants to do when visiting your web site in their web browser is to install a mobile application.

The best way to achieve this is to show a modal dialog that prompts them to install it.

As an optional step, you may add a button or hyperlink to close said dialog. But it's important to use some cryptic text, preferably worded to shame the user to comply.

Tip: If you don’t have an actual mobile application, you can just get an intern to package your website in a webview with security disabled and ship that!

Implement a Do Not Track Policy

Many modern browsers these days support a HTTP header called DNT which stands for Do Not Track. This header is meant to signal that a user does not want to be tracked. Unfortunately this is enabled by default in some browsers like Brave (An open source ad-blocking browser made by the creator of JavaScript Brendan Eich).

However, don’t worry as all is not lost! We’ve found that most users will remove this header when prompted to do so so. In order to handle this, we recommend that you serve a guide on how to disable it when the header is present.

Tip: Don’t serve the prompt to disable DNT on the guide that shows the users how to disable it, as the conversion rate ends up being rather poor.

Implement a Cookie Policy

Cookie consent is confusing. While it's not required in most cases, with reasonable cookie use it’s better to prompt the user for consent so we can track everything without fear of repercussions.

Tip: Don’t serve pages without cookies enabled even when we don’t need them. It means we can track less personal information, thus we have less user information to sell.

Blocking Ad-Blockers

Ad-blockers are everywhere and can really hurt your margins, so the obvious precaution to take is to block ad-blockers.

Chrome is moving to block ad-blockers, so if the user is using a browser like Brave we’ll be able to just claim the user’s browser isn’t modern enough.

Tip: Don’t tell anyone about Brave, the open source Chromium based browser with built-in ad-blocking.

Blocking Non U.S Countries and Devices

Between Cupcake nations, GDPR, link taxes and the Huwaei ban which we haven’t been able to figure out at all, the best approach is just to block them all to avoid any and all liability.

Tip: You can …

Maximizing Your Layout

The days of 800 pixels wide layouts are gone. Modern displays tend to be widescreen so make sure to take advantage of the entire width in the layout.

Tip: Research has shown that modal dialogs that cannot be closed perform better.

Use Notifications

Modern browsers support notifications so enabling them is a must. But as a fallback, also automatically subscribe the user to to a newsletter, sms notifications and/or email notifications.

Tip: Use these notifications to tell users when you have a new version of the mobile application available.

Prompt The User

Sometimes users forget they can sign up. Be sure to prompt them regularly and feature a prominent sign up link or button.

Tip: Also prompt the user when they’re about to leave the website or their mouse cursor leaves the website.

Allow The User To Opt-Out

It’s very important that we are user friendly and aren’t intrusive. This means we have to let users opt out of our constant prompts and modal dialogs.

The best practice here is to put the opt-out settings in a place where the user will easily spot it — typically this is inside one of the “account preferences” pages.

Use JavaScript

It’s a known fact, all websites require JavaScript.

While you might think, “Oh it’s only plain text and a couple of modals.” But in the future? By then, it’ll be many many more modals, and I’ll promise you right now.

When that happens, you’ll regret not making your website an isomorphic application using the latest framework running on a serverless cloud.

Tip: Don’t render this page with JavaScript.

Not a web developer yet? Don’t worry about it - you're already qualified from reading this post.

Already a web developer? buy the C programming language book here and get out while you still can!

You are a hacker. Your home is the terminal. You know every key stroke is valuable. If something is less than 100% efficient, you will spend hours figuring out the right tool to save yourself seconds. Because it’s always worth it.

_Source: [Twitter](https://www.pablostanley.com/" rel="noopener" target="_blank" title="">Pablo Stanley via <a href="https://twitter.com/pablostanley/status/963469081910296576" rel="noopener" target="blank" title=")

Does your constant search for newer and better ways to do things detract from actually doing things? Some may say yes, but you say nay. No work is worth doing unless you can lecture your coworkers on why you were able to do it so efficiently (setup time not included).

The following is a list of tools/features that every good hacker should know about.

Dislcaimer: This article is written with a heavy dose of satire. It’s a twist on the “Me, an Intellectual” meme. While the suggestions are sincere (and by no means complete), the references to being a “hacker” are just for fun.

Shell (zsh)

Average developer: A shell is a shell. It doesn’t really matter which one I use. They all suck anyway.

You, a Hacker: The shell is the lifeblood of my work. My passion for efficiency and features knows no bounds. My shell must be one worthy of a true hacker.

You live in the terminal, and that’s why you want to use a great shell. That’s why you use zsh.

It comes with a whole slew of features:

• Auto-correct of misspelled commands
• Easy drop-in replacement of bash
• Better cd completion using <tab>
• Path expansion: cd /u/c/c/j + <tab> =cd /user/caleb/code/jarvis
• Much more

It also comes with a great framework for managing your zsh configuration: Oh My Zsh. It includes 200+ plugins and 140+ themes to add all sorts of awesome features to your terminal. A small sample:

• git - tons of aliases and useful functions for git
• tmux - alias and settings for integrating zsh with tmux
• node - adds node-docs command for opening website docs
• osx - several utilities for working with OSX
• web-search - initialize web searches from command line
• auto-suggestions - fast, unobtrusive suggestions as you type based on history

You can find the full list of plugins here.

Session Management (tmux)

Average developer: Okay I’ve got my files open for lame_project_1. But I also need to do work in boring_project_2. I also need to ssh into a server and look at the logs. I guess I’ll just create a huge mess in my terminal that has files/tabs from multiple projects open in a way that I’ll eventually lose control of and be forced to close and start over.

You, a Hacker: I work on several projects at once, so I need a tool to help me keep it organized. It should work across multiple platforms, and allow me to create organized work spaces and have a lot of other features that help with productivity.

You know that development can get messy. Sometimes, you have to work on several projects at once. That’s why you use tmux.

It allows you to create sessions. Each session can be customized to the exact layout you need. You can name sessions for easy switching, and even save and restore sessions if your terminal is closed. Plus, it has its own customizable status line that will allow you display things like time, date, CPU usage, and more. And if you don’t know your CPU usage at any given moment, are you even a hacker?

Organize your terminal with sessions and use fzf for fuzzy create/finding/deleting of sessions

It even has a plugin manager and a whole slew of awesome plugins & features that will take your hacking to the next level.

Super-Pro Hacker Tip:
Use tmux with fzf via some awesome scripts to quickly create/delete/navigate to push your hacker level to over 9000.

Search (ripgrep)

Average developer: Where did I define that constant at? I know it’s somewhere in here. I’ll try to grep for it. What are the arguments again? Let me google that. Ah crap, now it’s searching my node_modules folder. This is the worst.

You, a Hacker: When I search for something, it should be blazing fast. Also, it should use sensible default settings, like ignoring binaries or hidden files.

You know that searching your project is a common task. It should be fast, and it should not waste your time. This means things like ignoring anything that your .gitignore file ignores, and skipping binaries and hidden files. That’s why you use ripgrep. It’s like grep on steroids.

ripgrep in action

In the words of its creator: “Use ripgrep if you like speed, filtering by default, fewer bugs and Unicode support.”

Fuzzy Finding (fzf)

Average developer: It’s sure hard to remember the exact location of so many files within my project. I guess I’ll stumble around until I find the right one.

You, a Hacker: I should be able to fuzzy-find files. I can type the file name, or some of the path, or all of it, and quickly find the file I’m looking for.

You know you shouldn’t have to type any more than you need to. So you use fzf, a general-purpose command-line fuzzy finder. It can also do much more than fuzzy-find files. It can used with any list: “files, command history, processes, hostnames, bookmarks, git commits, etc”.

Super-Pro Hacker Tip: You know that aliases are a great way to make shortcuts to take advantage of fzf’s features. For example, if you wanted to fuzzy-find a file, and then open up the selection in your default editor, you can add this to your zsh config:

Now you can run “fo” fuzzy-find and open a file

Many more examples can be found on the fzf wiki.

Terminal Prompt (Spaceship)

Average developer: Who cares what my terminal prompt looks like? There’s no way it could possibly give me any useful information. I’ll just leave it as the default.

You, a Hacker: I want my prompt to be amazing. It should be context-aware. It should give me useful info and be configurable. Also, it would be sweet if it was related to space.

Welcome to the future… but actually the present. Hackers/astronauts only.

You know a prompt should be simple, clean, and provide only relevant information. It should also blow people’s minds when they see its beauty. That’s why you use spaceship-prompt. It provides git/mercurial integration, battery level indicator, clever host name and user data, version numbers for a variety of libraries, gorgeous icons, and much more.

Changing directories (z)

Average developer: I need to change my directory to my “hacker” project, which is inside of my cool folder, which is inside of my personal folder, which is inside of my code folder, which is in my home directory.

cd ~/code/personal/cool/hacker

You, a Hacker: I need to change my directory to my “hacker” project.

z hacker

Typing out full file paths is what average developers do. You are a hacker. You rely on z. Once installed, it will start learning which directories you visit. Then, you can give it a regex (or simple folder name) to hop to the most likely candidate.

Bonus Hacker Tools

The following tools are additional ways to truly elevate your hacking game.

1. wttr.in — There’s only one right way to check the weather.

2. Star Wars — Cool people like Star Wars. Hackers watch it in the terminal.

telnet towel.blinkenlights.nl

Pro Tip: Watch star wars in another tmux pane while working. No one will question you.

3. haxor-news - Are you even a hacker if you don’t read Hacker News?

4. Spotify - Using shpotify, you can play music from the terminal (OSX only… Hey, stop booing! Put that chair down! Who threw that tomato!?), or mopidy for something that’s cross-platform.

God bless the commands in the terminal

That about wraps it up. This is by no means a comprehensive list. Do you have any other amazing hacker tools? Leave a comment and let me know.

If you are interested in seeing more of these tools in action, checkout out my dotfiles that I use for development. As a bonus, here’s a screenshot of the glorious terminal in action:

There are two things every person has in common: knees. Your friends have knees. Your coworkers have knees. So does your Aunt Sally. And your Uncle Aloysius.

You. Me. Left knee. Right knee.

Yet, despite this common bond, people continue to argue, fight and hurt one another. There is conflict everywhere, both online and in the real world. But what if it were possible, after centuries of squabbling, to bring peace and harmony to all mankind through our shared identity. Well, that day has finally come.

Introducing Deez Knees, the first and only social network for sharing photos of knees — only knees.

Why knees?

I created Deez Knees to unify humanity. Some of us are taller than others. Some of us have dark hair and others have light hair. But when it comes to knees, there is little variety. A knee has only two parts: an interior component (the knee bone) and an exterior component (the knee skin). This is true for my knees, your knees, his knees and her knees. By sharing pictures of knees, we remind ourselves that deep down, beneath the knee skin, we are all basically the same.

Deez Knees promotes unity

You know what else Deez Knees promotes? Diversity. “Hey, hold on a second mister,” you might be thinking. “You just said all knees are the same, so how can your amazing new creation promote both unity and diversity?”

That, my friend, is the power of Deez Knees.

Scalable, configurable, technologicable

The core technology behind Deez Knees is a sophisticated knee-recognition algorithm. You can try to post a photo of something else, but it won’t work. Upload a picture of your elbow? No dice. Share a pic of your butt? Try Instagram.

Deez Knees is fully integrateable across all digital platforms — vertical, horizontal and diagonal. The user interface is intuitive, responsive and gratuitive. Your personal information will remain secure. We use triple-bypass, hexagonalical encryption with cross-key hashtags. All data on Deez Knees are stored not only in the cloud, but also in the mist and the yawn.

Do we use blockchain? Yes, indeed — 27 blockchains, to be precise. Users can also select the cryptocurrency of their choice: Bitcoin, CyberDime or WebDough. Our network is lightening fast. Images load quickly thanks to our middle-out compression algorithm, which is based on science and math. Deez Knees is also chocked full of nanotechnology and artificial intelligence.

Digital, Advanced Tech, The Future — Deez Knees

Making the world a better place

Most tech entrepreneurs care only about money and fame. They want to be the next high-profile billionaire, grace the covers of magazines, hobnob with celebrities. Not me. I created Deez Knees for you. For you and your knees.

Will there be advertising on Deez Knees? That goes without saying. Will I give your personal information to marketing companies? Yes, of course, but not for free. Will I sell Deez Knees to Facebook the first chance I get? You betcha.

But don’t let these minor business details distract you. Deez Knees was created for a higher purpose. There is too much bad in the world. Let’s inject a little bit of good. Actually, make that a whole lot of good.

I don’t know about you, but I think this world of ours is worth saving. Enough with the crime and the wars. Enough with the nasty YouTube comments and the silly Twitter beefs. Why so hostile? Friend, you have only one life. One life and two knees. Use them well.

That’s where Deez Knees comes in. Instead of clapping back at that internet troll, share a photo of your knees. You’ll both soon realize you aren’t so different after all. Instead of bashing Republicans, or Democrats or Saskatchewanians, scroll through your Deez Knees feed and reflect on how we are all diverse yet the same, different yet not so different, unequal in some ways yet — really, when you think about it, really think about it— always equal in all the ways that count.

Deez Knees turns nasty into nicety

It’s time, my friend. Time to make this world a better place. Time to bring light into darkness. Time to turn conflict into proflict. All we need is you, me and Deez Knees. We can do it. Two knees at a time.