When building software you need to constantly make and question assumptions. You make assumptions since you can’t operate with perfect information and waiting for that perfect information would take an infinite amount of time. These assumptions can lead to falsehoods.

Akin’s 33rd law of spacecraft design: A good plan violently executed now is better than a perfect plan next week. But why? Perfect isn’t an achievable state. The necessary number of iterations is one more than the number you have currently done and this is true at any point in the process.

So how do you go about questions assumptions: It’s like Leo McGary would say on the West Wing: Don’t accept the premise of the question.

ANNABETH
Press is here for the Q&A. Now remember, you control the conversation. You don't like what the ask, don't accept the premise of the question.

LEO
That's my line, you know. You're quoting me.

ANNABETH
I thought it was Toby.

LEO
Where do you think he got it? I've been rejecting the premises of questions since the Hoover Administration.

---

Assumptions on the web

The internet abounds with “Falsehoods Programmers believe about X” with Time and Names being two of the most common. It’s easy to look at a list of requirements and think that things are true, but we need to question the assumptions we are making in the process or to paraphrase Leo, “Reject the premise of the requirements”. So let’s reject the premise and look at some of the Falsehoods WordPress Developers Believe.

Falsehoods WordPress Developers Believe

1. WordPress roles are static across sites.
2. WordPress Roles are at least static during each request.
3. A WordPress user can only have one role
4. Two Users with the same role will have the same capabilities.
5. If a user has a capability earlier in a request, they will still have it later in the request.
6. WordPress roles are hierarchical.

WordPress’s Users, Roles, and Capabilities system is incredibly powerful and also incredibly easy to screw up. While role information is stored in the database, it’s possible to add/remove a capability from a user both in the DB and at run time. This is why current_user_can needs to be checked every time you are taking a privileged action. Through meta capabilities and the powerful hooks inside WordPress, it’s possible to do things such as making it so only specific users can add a specific category. While this talk is nearly 10 years old, Nacin’s “Current User Can Watch This Talk” will give you a good idea of just how powerful the API behind the roles and capabilities system is.

I am a big fan of using the multiple roles plugin to make it so that giving a user additional roles has an easy UI and then setting up roles that are hyper-focused. For example, if there is an intranet and internet component to a site, you might want to allow posting on the intranet but not the internet or vice versa.

7. Taxonomies can only be applied to posts
8. Taxonomies can only be applied to things that go in the posts table
9. Taxonomies can’t be shared between different object types
10. A site that has been updated past 4.3 has had terms split

Taxonomies can be a great way to extend WordPress. It’s also easy to think that just because WordPress core only uses them in one way out of the box you can’t use them for more. You can use taxonomies for users or create a taxonomy of comments.

11. Popular WordPress Plugins never have bugs
12. You can’t trust plugins with few users
13. Big Plugins are always better
14. You should always wait to update your plugins

Selecting WordPress plugins can be a challenge, but it’s important to remember that size of the company/team behind a plugin and the number of users of a plugin are only indicators. There are great small plugins, great big plugins, and great plugins that sort of appear abandoned. The best way to know if a plugin is good is to test it yourself and audit the code and also look at how the makers respond to feedback and support requests.

15. WordPress Cron will always fire on time
16. WordPress Cron slows down your site
17. WordPress Cron can’t be trusted

The default implementation of WordPress cron will have events run after the page is delivered to the user in what is known as a loopback request. This requires people to visit sites and there are many sites that don’t get many visits. So if an event such as publishing a post should happen at 10am and no one visits the site until 10:15am? The post will remain unpublished. Thankfully there are tools like Cavalcade and Cron Control for really big sites, using system cron along with DISABLE_WP_CRON for others and 3rd party monitoring services that will hit your site and thus trigger cron for the smallest of sites.

18. WordPress is losing popularity.
19. WordPress is dying.
20. WordPress doesn’t work for big sites.

There has never been a better time to be working with WordPress. From Rolling Stone to The White House (two sites I have worked on), there are many large WordPress sites launching all the time along with many thousands of smaller ones.