Refactoring and technical debt
Codebases tend to accumulate junk over time. This comes in the form of disorganized code, "temporary" fixes that have become permanent when no one was paying attention, things that work but could use performance tweaks, and modules included in the codebase that are no longer used.
Previous update cycles allowed messes to pile up in a closet somewhere. When the migration or replatforming occurred, everything in that closet could safely be taken out and set on fire. Easy cleaning.
With an alternative model, you can't afford to keep pushing things around. Over time, that closet will have to be so big that it will take up the entire house.
Start taking inventory of things that need to be cleaned and start adding them as tasks for your team. Maybe your goal is to complete two technical debt tickets per month. Maybe it starts to smell gross and needs an entire sprint dedicated to a refactor. Perhaps a new feature will be easier to implement if some other code is reorganized, so add that task as a prerequisite.
However you do it, do it with intention and planning. That closet isn't going to clean itself.
With an iterative model, you can't afford to keep pushing things.
Allocate development resources
You have planned the release cycle. You have a constantly growing list of new feature requests thanks to your increased communication with stakeholders. And you have identified good targets for refactoring.
Now what?
Prioritize and assign. This, of course, depends on the size of your team and the number of stakeholders involved in the work. Your project managers have their work cut out for them because they also have to worry about appropriately assigning within the shifting tides of priorities.
You can give each stakeholder a team that they work with exclusively. This helps people feel comfortable working together and builds rapport. You're less likely to need project kick-offs every time you start something.
You can also rotate developers and teams so everyone has experience doing a little bit of everything. That way, there is some overlap in case of emergencies or rotation. It also keeps things fresh and can help prevent burnout. Let the developers talk and tell you what they are thinking and, if possible, cater to their preferences.
It can be helpful to have the same person in charge of the publishing schedule day after day, month after month. But does anyone really want that job on a day-to-day basis? Maybe they do. But you need to be sure.
For smaller teams, you may need to break things down by month or quarter. Maybe November and December are the months when everyone focuses on technical debt. Perhaps the first quarter of the year is reserved for new design initiatives and higher priority feature rollouts.
But don't let security and software updates get lost in the shuffle. Don't get lost in the weeds of overzealous refactoring. Don't ignore the needs of your stakeholders. This may seem like a juggling act, but your organization must master it to keep your website secure, relevant, and successful.
Celebrate
No more “big reveal” and launch of a new website. Hopefully the ups and downs, wins and stresses will flatten out to more manageable peaks and valleys. However, that doesn't mean you can't celebrate the conclusion of smaller initiatives. You absolutely should. Announce them, treat them as major milestones, make your hand hurt from so many high fives and pats on the back.
This can be done in many ways:
- Public recognition in internal meetings and newsletters.
- Demos and learning sessions where those responsible for the work show what they have done and learned.
- Small parties that occur immediately after lunch.
Whatever fits your culture, do it.
Since each initiative and function stands more on its own, it is not drowned in the excitement of a “big reveal” where the glitz of so many new features can blind people from seeing certain parts of the work that has been done.
Iterative releases allow a greater focus. And they give more opportunities for congratulations. Take advantage of them.
Reviewing site architecture and content
Historically, many organizations have used major Drupal release migrations as a cadence for reviewing information architecture. In part, this is because content migrations in major releases have not always been 1:1 migrations, so organizations have had to do information architecture (IA) work to decide what to migrate and where it should go.
The other aspect of this is that, in more complex migrations, it might have been faster to remove old content and obsolete content types than to spend time migrating them, especially in the case of a custom migration.
The advantage of migrating from Drupal 8 to Drupal 9 and beyond is that there is no content migration. The disadvantage is that organizations now need another pace to undertake information architecture and strategy projects. This is similar to creating a new web development work pattern, and many of the development tips apply here as well.
In fact, architecture and strategy should drive most new development work. Get into the habit of conducting regular IA and content audits . Every year or every six months. Whatever makes sense for your organization. It's part of having a well-kept house.
Some sample questions you might start asking:
- Does the historical content still meet your needs? Can it be updated, moved to another content type, or archived?
- Does the site contain single-use fields that should be obsolete?
- Do content types need to be trimmed?
- Have the site's navigation needs changed?
- Does our taxonomy structure still meet our needs and goals?
- Have we added new departments or consolidated older ones, and are they represented correctly?
- Has our audience changed, and have we started targeting new audiences?
- How has our business changed? Have new competitors forced us to think about different approaches and goals?
Sometimes, your IA may require a major change, and that change must occur on a website that must remain operational. For example, consolidating two types of content into one new type of content.
The good news is that the robust, well-tested migration tools that would have helped you during a full upgrade are there to help you accomplish a smaller change. Drupal's migration tools are great for importing content and dumping that content into different structures. Take advantage of it, even if it may seem like overkill at first.
Architecture and strategy should drive the majority of new development work.
Bringing in outside help
Major upgrades and migration efforts demanded expertise and more developer hours, but without this traditional demand, is there still room to hire outside help?
Yes, there is. It can make a lot of sense, depending on your situation. In many circumstances, establishing a longer-term relationship with a provider can generate even more gains, as the external team is not alone for six months to a year, and then move on to the next thing. Trust has time to grow. Communication settles into familiar rhythms. Everyone involved feels more comfortable with each other.
There are many ways you can use outside expertise beyond the crisis of a large project. Keep in mind that the lines between the following categories are confusing, but they are good places to start when trying to determine if you want to hire an outside provider.
Support and maintenance
If you want your own team to focus on new features or work that you consider to be of greater value, using outside help to support and maintain your existing infrastructure can provide a level of coherency that allows you to move forward.
Put a dedicated team in charge of managing your launch cycle. They manage software updates and work within your schedule.
A skilled support team can also help manage bug fixes. This frees up your developers' time, so they're not bouncing between tasks, losing a little productivity each time. Help them avoid concentration whiplash.
How do you know you might need help with support?
- Assigning responsibility for the launch cycle is like a game of hot potato. No developer really wants it.
- The accumulation of “urgent” bugs grows month after month instead of shrinking. Stakeholder complaints start to grow.
- Your software is continuously out of date for months and requires everyone's attention to correct the situation.
Filling experience gaps
Even if you have a large and diverse development team, you probably have some experience gaps. Technology is complicated. It's hard for a team to keep up with everything that's going on all the time, and it can be helpful to have some specialists.
Security audits. Accessibility audits. Performance audits. These are good opportunities for someone to come in, give you some practical items and get into the sunset. Each round of these also helps educate your staff. Depending on the scale of your site, it might make sense to grow your team with this type of experience for long-term engagement rather than periodic audits.
DevOps and continuous integration is also something that can benefit from a dedicated resource. A good expert in this area can help your entire team be more productive. They can set up and maintain automated code deployment and testing, manage local development configurations, and help enforce best practices.
Strategy and content design are areas that can benefit from outside perspectives. Good talent in these areas can help make your internal projects more successful by forcing you to clarify priorities.
Increase the speed of development
Sometimes you simply don't have the resources you need to achieve your goals. Too many initiatives with too many people demanding their pound of flesh. All of these requests and requirements could be channeled through the marketing department, or maybe your company has several departments, each of which owns a section of the website.
Either way, you need more help, and you need that help to start up and run. A team of experts can be integrated in several ways.
- They can increase the current team without changes to the structure. With this model, they become additional team members for your use, whether they are project managers, content strategists, designers or developers. The goal is to increase the overall speed of their development work.
- They can come in with a more focused purpose as a discrete team. They are assigned to a specific stakeholder or initiative, so important work can move forward without interrupting your normal development workflow.
- A mix of both paradigms. There are no hard and fast lines to draw, and being flexible has its advantages. For example, after a team has completed a specific initiative, they move on to another, or the team splits up and disperses to other internal teams so that domain knowledge can be spread. Or perhaps they move into a support role.
Brave new world
Despite not having a major replatforming effort on the horizon, web development in a Drupal 9 world still requires planning, thought, and intention. Release cycles need to be managed. New work needs to be planned and developed. Stakeholders need to be kept happy.
Drupal 9 makes it easier to take advantage of new features while keeping your site secure, successful, and relevant, but you can't move on anymore. No more waiting for the big migration to get rid of technical debt or rework your information architecture.
New habits need to be formed. New cadences need to be implemented. Exciting times are ahead as we juggle this new reality.
By: Matt Robinson