Investing in Your Team & Tools Early: How to Ensure Drupal Project Success
"It is not enough to do your best; you must know what to do, and then do your best" —W. Edwards Deming
How Weill Cornell Medical College Built a Dream Distribution with Pantheon
At Weill Cornell Medical College, Dan Dickinson manages a 12-person Web Communications team that designs and develops organizational websites for medical education, research, and patient care. Read how his team is rescuing 100+ websites from design anarchy—by setting out to build the best Drupal distribution in higher education.
DIAGNOSIS? AN ADVANCED CASE OF DIGITAL SPRAWL
1. 100+ static websites running on various platforms.
How to Set Up and Configure Autopilot
In this post, we break down how to set up and configure Autopilot. Dive in to learn more.
Why every Pantheon user should learn Bash? - Part 4: Aliases and Scripting
Approximate Reading Time: 7 Minutes
How WebMD Ignite Built a Multimillion Dollar Business on Pantheon
This post was updated in January 2024.
Imagine you could build a site in hours instead of days. Now, imagine you could use Slack for that. WebMD Ignite, a division of WebMD and Internet Brands, has the future of SaaS healthcare at its fingertips.
How to Implement a UX Strategy That Works for You
Developing a customer-focused UX strategy is a critical step in providing visitors with a great website experience. Dive in to learn how to create the right UX strategy for your site.
How to Lose Your Site in 10 Ways
At Pantheon, we do our best to make building, launching and maintaining a Drupal or WordPress site as easy as possible. All sites on our platform get the same PHP and MySQL configurations tuned for their applications. Every site has Varnish sitting out front to provide speed and protection against surging traffic. Our Dev/Test/Live workflow helps ensure only quality code makes it to production. Multidev allows teams to work on new features in isolation. And database backups are very easy to move around between environments.
All Code is Debt
The way people use the phrase “technical debt” implies that good, tested code is debt free. If you are building a software service this is wrong; every line of custom code you maintain is debt.
To be competitive, software products must continually improve. All of the custom code you’ve written yesterday, rewritten today, and what you’ll write tomorrow -- you will be burdened with maintaining, forever. To build competitive software you must balance this cost when you decide what code gets written, and what gets integrated from upstream.