Navigating a front end development upgrade can be tricky—especially if it’s the second iteration of your technology stack. In the coming months, our tech stack at Clearlink will receive a significant upgrade, and the team has been working around the clock to make sure it is efficient and effective.
As we work to update our own dev environment, we wanted to share a few tips to keep in mind for a successful transition.
1. Confront Legacy Infrastructure
Like many teams working in the rapidly developing space of web technology, the team at Clearlink inherited systems and workflows that we weren’t responsible for creating—but we are being asked to make the infrastructure more accessible, maintainable, and efficient.
When confronting legacy infrastructure, there are three things you need to do before anything else:
- Take inventory of existing assets.
- Consider what you would do differently if you could do it all over again.
- Based on that list, determine what you can actually achieve now
Being reflective of what dictates your current workflow is a critical philosophy you must embrace in the world of development. You can’t move forward without recognizing where you’ve been and why. As you examine your current infrastructure, highlight its successes and acknowledge its faults so that you can use both to move forward consciously and more effectively.
2. Spend Time Conceptualizing
The very essence of development is identifying and testing complex concepts. The real work lies here, not in the labor of creating the actual system. Over half our time working on a project is spent thinking—and no tool we create can do that for us.
You need to be comfortable spending considerable time discussing, planning, and debating all aspects of the potential outcome, long before a single line of code gets committed.
To keep discussions meaningful, focus on identifying the building blocks of your system and then spend time zooming in on each. During this stage it’s important to keep these things in mind:
- Identify current solutions in the wild that might provide a quick win.
- Don’t spend too long fleshing out a specific piece.
- Remember that changing one system module often has a collateral effect.
- Consider integration points for each aspect of your system and how they work together.
- Measure the level of effort required for each component’s implementation.
- Account for maintenance and long-term support.
Even after considering these things, you also need to be comfortable with discarding pilot work and systems that you have worked hard on. Go into the process knowing that you will likely need to create several pilot systems before one eventually takes flight. Easier said than done with timelines and milestones, I know, but it’s imperative you realize and embrace the value gained here and take your time conceptualizing your new system.
When we spend time conceptualizing, we help pinpoint the essence of the product we’re creating. Why is this important?
- You’re forced to think about the system in rudimentary terms when you scaffold something that was once just an idea. This raw work helps you recognize and label all of the necessary core elements to make sure it aligns with the project requirements.
- Knowing these elements allows you to compile a catalog of any possible solution for each; there are often many different development approaches and tools you can use to accomplish any singular task.
- Creating these systems allows you to build and test each proposed solution in your solution catalog and check them for their efficacy, ultimately arriving at the best answer through trial and error.
Any project plan that comes to life before a conceptual system has been built is likely doomed to fail. It’s only through documentation and experimentation that we can conceive what a development project plan really looks like. Anything before that is premature. You need to acknowledge the complexity of your project by first attempting a rough form of it, then you’ll have the proper information needed to create your blueprint.
The onus is on us as developers to relate the value in this step to stakeholders as we address weaknesses and focus on specific, efficient improvements. Explain that conceptualizing allows you to find the best possible solution for your needs, notice and plug holes in your thinking, and provides a rough estimate to the complexity and time that will be involved when bringing the project to life.
3. Address—and Debate—Weaknesses
A key part of conceptualizing your new system is addressing the current weaknesses. At Clearlink, fragmentation is one of the core problems we’re attempting to resolve with our update. Aside from essential aspects like hosting and server environments, our system lacks shareable technologies and processes across projects.
Each facet of development is doing its own thing, with its own set of proprietary tools created by individuals out of pure necessity to get their job done. This breaks a paradigm we attempt to adhere to in all areas of development: complex work needs to be reusable, maintainable, and scalable—equally and respectively.
Fragmentation and isolation are common problems for front end development teams. Here are a few other key weaknesses that are often part of first-generation dev systems that you may want to look for in your own:
- Disjointed workflow.
- Fragmented enterprise data/facts.
- Code/logic that isn’t modular or extendable.
- Lack of ability to share work across teams.
- Inefficient code release cycles.
- Unreasonable timelines.
- Poor communication, leading to disengaged product owners and team members.
- Inaccessible staging and testing environments.
Make a list of all the weaknesses in your system. Go back to the drawing board (remember to embrace the conceptual system!) and debate the efficacy of each proposed solution to the weaknesses you’ve discovered. Talk to members of your team and anyone else that interfaces with your team or its systems. What pain points do they experience that you weren’t aware of?
4. Avoid the Second System Effect
A tempting path to take during this process is one that tries to solve all your problems at once. The second iteration of a system is often the most dangerous system a developer will ever design, especially if it is being designed by the same developer responsible for the first system.
Everything stored in people’s minds for “next time” is now on the table, and the thought buffet can quickly grow to an unmanageable scale.
Developers routinely opt to over-engineer the next system with the altruistic intent of removing all the friction points from previous incarnations, a tendency referred to as the “Second System Effect” by iconic software architect Frederick Brooks. We often attempt to incorporate all of the ideas that were sidetracked the first time, with little regard to impact or experience.
Discipline is key to your approach. Our focus at Clearlink is on identifying a minimum viable product that meets a baseline of needs for all product owners. To do this, we need to be content with trimming initial frills now in favor of later iterations.
To avoid the second system effect, we are focusing on three main solutions:
- Continuous integration workflow with minimal impact on the developer.
- Shareable components and project boilerplates.
- Disciplined iterations that focus on features offering the most substantial gains for our teams and business.
As we examine the current strengths and weaknesses of our system, we come back to our three main solutions and decide whether or not our proposed ideas meet those criteria. It has helped us keep our second system manageable and effective.
5. Determine Next Steps
Over the first quarter of 2018, we’ll be migrating our legacy systems into our new system. As part of that process, we’ll be aggressively documenting and soliciting discussions on how we can continually improve. Anyone who’s ever been a part of a process like this knows this can be a turbulent and stressful time for all involved parties.
Mitigating these areas of concern will be essential for determining and achieving next steps. Once you’ve conceptualized your system, addressed weaknesses, and planned for the second system effect, here are five main focuses for determining next steps:
- Recognize and that the first system design is rarely the right one—don’t get too attached to any specific iteration.Proactively communicate to team members that they will have work that gets tossed.
- Remember that core system changes are almost always a guarantee, and stay agile to keep on top of them.
- Document decisions—both steps taken and steps you chose not to take—and the reasons behind those decisions.
- Keep communication open throughout the entire process and implement feedback where necessary.
Developers need to anticipate and embrace changes, whatever they look like. Having the agility to adjust is paramount, and knowing you’ll need to be agile will make those moments of decision-making less reactive.
From decreased development workflow difficulties to increased feature deliverability, we’re confident that our new system will improve the daily lives of developers and content creators alike while universally increasing the value and quality of our products. Which, ultimately, makes the process of upgrading your front-end development stack one worth doing right.
If you’re at the precipice of taking this leap, hopefully the lessons we learned will save you time and frustration on your way through the twists and turns of the journey.