Posts By Wes Dollar

No More Excuses: The Power of Code Review

Over the years, I’ve done a lot of experimenting trying to figure out how to help my projects and teams run smoothly and efficiently. The resulting bag of tricks gives me a strong arsenal from which I can pull, but not every trick in my bag is applicable to every organization, team, or project – except for one. The code review. I’ve been invited into dozens of teams, but more often than not I’ve found a lack of commitment to the code review process, whether it was treated as a pointless formality or forsaken altogether. While it’s always disappointing to see, as a consultant, it’s low-hanging fruit that makes me salivate because I immediately know I’m going to be able to earn my keep and radically transform this team and project.That’s a powerful statement, and it might lead you to wonder, “If it’s that powerful, why doesn’t everyone do it?” There seem to be a few common “excuses” amongst the teams that don’t put any effort into code reviews:There’s not enough timeThe conversations become contentiousNo one participatesThey don’t add any valueIf you’re reading this, perhaps you, someone on your team, or both have used or subscribed to one of these excuses. Let’s break each of them down and dispel the negative narrative so we can banish these for good.Excuse One: There’s Not Enough TimeTeams always need more velocity, and it seems most teams tend to underestimate the effort required to complete large projects. Tossing a production bug into the mix is a bit like throwing a grenade right into the middle of the scrum board. So we end up burning the midnight oil while praying for an 11th hour miracle so we can release on time. There’s no time for this pesky code review I speak of, right? Code reviews make every member of the team better, stronger, more skilled developers through the knowledge share and coaching that happens as part of the process. The overall velocity of the team trends upward over time because your less experienced developers are getting feedback on every line of code they write, while your more seasoned developers are getting to see different approaches to solving complex problems, and being exposed to parts of the codebase they otherwise wouldn’t have any knowledge of. Sizing the tasks becomes a lot easier and more accurate because of this knowledge sharing that organically happens during the code review process. We’ve now effectively created a cycle in which the developer is getting better and has more exposure to the codebase on a daily basis. The result is a better codebase and better developers. It’s a win-win!Excuse Two: The Conversations Become ContentiousWe software engineers can be prideful, opinionated individuals. The most important thing to recognize and preach is that there’s no room for ego in the code review process. Everyone, no matter their tenure and skill level, can learn something from engaging in the process. This simple rule ends up cascading throughout the team culture and fosters a supportive environment that helps each member of the team grow on a daily basis.Excuse Three: No One ParticipatesThere’s nothing more frustrating than seeing a pull request sit there for days on end, which can ultimately lead to some pretty frustrating merge conflicts, or worse, the subsequent creation of functionality that doesn’t play nicely with that in the pull request. The bad news is that this comes down to team culture. The good news is that it’s easy to fix. Sit down with your team, explain the benefits and goals, outline the expectations and roles each team member plays as part of the process, and commit to the process as a team. The burden of holding the team accountable to the process doesn’t fall on any one person. It’s the responsibility of the entire team to facilitate this process. Excuse Four: Code Reviews Don’t Add Any ValueTime for some tough love. If this is the stance you or your team takes, you’re doing it wrong. It’s that simple. We’d be here all day if I tried to list all the ways teams get the code review process wrong. Instead, I’m going to give you some quick tips that you can take and put into action with your team today. (And look for deep dives into some of these topics in upcoming articles.)No egos, no arguing, be helpful, learn and help others learnTech leads should be on every code review, and their signature should be required to merge all pull requestsA total of two signatures should be required on every pull requestPost the link to pull requests into a common chat channelEveryone on the team should participateNo one is ever “too deep in the code” to take a few minutes to look over a pull requestKeep pull requests small, which can be facilitated through better task managementCreate a “code review playbook” that includes a list of things to keep an eye out for and that clearly documents your team or organizations code style rules (be sure to couple this with lint rules and auto-formatting)Newton’s first law of motion says, objects in motion tend to stay in motion. Sometimes the hardest part of the process is simply getting started. Make the effort to get a solid code review process in place, and the rest tends to take care of itself. I’ve had so many developers come back to me months later with a completely different attitude toward the code review process, even the worst of skeptics.If you want to see a dynamic and quick shift in the culture and velocity of your team, this is the easiest and most fruitful first step to radically transforming your team and creating an environment that fosters growth. The best time to plant a tree is 20 years ago. The second-best time is today. WATCH TECH IN 2: THE POWER OF CODE REVIEWAbout the Author:Wes Dollar is a full-stack engineer with 21 years of experience in website & web-based software development. He has served as a business analyst & tech lead for clients ranging from startups to Fortune 500 companies. He has a passion for providing solutions to complex problems in a manner that is intuitive and easy for the end-user to use & understand. Most of his career has been spent on the open-stack side of the fence, where he has made many contributions to the Laravel (PHP) ecosystem. He is an HTML5/CSS3/JavaScript expert with strict compliance to W3C standards & 508 accessibility. He specializes in ecommerce & conversion rate optimization through UX design and also specializes in developing business systems, processes, and integrations.

The Top 4 Reasons to Build Your Next Application in React

React and Angular are arguably the two most popular tools available for front-end development today, and while I do look forward to discussing Angular, I’m not-so-secretly excited to be starting with React. I work in it every day, and since it’s the only tool I use for my pet projects, it wouldn’t exactly be a stretch to say that it’s my favorite. However, before I go any further with my (slightly) biased opinions about it, the unbiased consultant in me must share this caveat: only when you consider your team, future goals, and project (in that order) will you know which tool is best for your organization. With that in mind, take a look at my favorite features of React.Facilitates Component-Driven ArchitectureThe history of software has taught us that small, reusable chunks of code give us faster development, easier maintenance, and fewer bugs. The innovation of the frontend has brought the necessity to follow good design patterns and principles that we previously only saw on the backend. Components have become the vessel by which we can accomplish this on the frontend. We create, for example, a button component that looks and responds to user actions the way we want, and we use that component all throughout the codebase. This means we never have to think about how our button looks and responds ever again unless to make a purposeful change. When we do decide to change the look and feel of our buttons, we have one single component to update, and those changes are then reflected throughout the entire app. React provides a fast and solid foundation from which to build our component-driven architecture. It offers few opinions about how it should be done, leaving those decisions up to your team, goals, and demands of the project. Robust EcosystemReact has one of the best ecosystems around, without question. I always take the ecosystem into account when I’m considering a technology. Technology with a vast and energetic ecosystem tends to have great momentum. With that momentum comes continued innovation and support. It also helps to ensure support is available if I ever hit some weird edge-case that greatly hinders my application in some way. The React ecosystem plays a huge role in the success and growth of developers, too. Information on how to be a better React developer is plentiful. Discussion boards are thriving with best practices, new ideas, and better ways to make the best use of React. All of these things make it easy to adopt and learn React, priming your project for success. Deliberate Decisions from the React TeamReact is an open-source project, which means anyone can contribute to its core codebase, and therefore, directly affect the websites or web applications of millions of people worldwide. This is a tremendous responsibility and one that the React team takes very, very seriously. It is the primary reason I trust building applications on top of React. I know that the React team is going to be thorough and thoughtful in their decision-making process to ensure that they add value without introducing breaking changes and bugs. I’ve been burned by many other open-source projects who recklessly accept pull requests, make breaking changes, or just completely abandon the project altogether.I’ve seen the React team take six months or more to thoroughly discuss and evaluate suggested features or changes to ensure that they’re making the best possible decision. No haste or fluff, just thoughtful, deliberate discussions to ensure the right decision is made. It’s a huge commitment when we choose to build our application on top of someone else’s work. We’re at their mercy, and breaking from them would likely require a full rewrite of the application. It gives me so much peace of mind and confidence every time I see how deliberate the React team is about introducing new features and/or changes.Great Experience for Users and DevelopersWe all know user experience is important, and React gives us the foundation we need to facilitate a great interaction with our users. Pretty much every project these days talks about user experience during the planning phase, but I rarely hear the developer experience discussed.A solid developer experience primes your project for success, increases velocity, and ensures consistent delivery of bug-free code that can respond to the business’s and users’ changing needs. React, and its ecosystem, certainly sets a great example and provides a solid foundation for a seamless developer experience. Ample documentation on how to easily set up supporting tools and best practices ensures your developers can work as efficiently as possible.When I work in React, I know what I’m in for:  a reliable tool that provides developers with a robust, dependable experience that still gives us the flexibility for customization. Curious about how React stacks up against the other Goliath in the application platform space? Check back in June to learn all about Angular.   About the Author:Wes Dollar is a full-stack engineer with 21 years of experience in website & web-based software development. He has served as a business analyst & tech lead for clients ranging from startups to Fortune 500 companies. He has a passion for providing solutions to complex problems in a manner that is intuitive and easy for the end-user to use & understand. Most of his career has been spent on the open-stack side of the fence, where he has made many contributions to the Laravel (PHP) ecosystem. He is an HTML5/CSS3/JavaScript expert with strict compliance to W3C standards & 508 accessibility. He specializes in ecommerce & conversion rate optimization through UX design and also specializes in developing business systems, processes, and integrations.

Five Practical Tips for Replatforming and Sunsetting of a Legacy Application

Replatforming can be a huge and somewhat intimidating undertaking, but it doesn’t have to be. By using a realistic timeline, creating a thorough project blueprint, and having a bit of flexibility, you’ll be reaping the benefits of your new application before you know it. Here are five practical tips for your replatforming efforts:Have a planDon’t laugh… it may seem obvious, but far too often, I’ve seen teams jump into a replatforming effort, and completely skip the planning phase. (I’ve done it myself, if I’m being honest.) It’s easy to fall into this trap in order to try and save some time. However, if we were to step back from the “ease” of the situation and assess the “why” of our goals, we’d quickly identify the inefficiencies, existing struggles, bad ideas, and bad practices that all lead to extra development time, which is most likely why we’re contemplating a replatforming to begin with. When we approach the replatforming effort with this mindset, it becomes crystal clear that we don’t know everything that we need inside and outside of our replatforming effort. I begin every replatforming by answering several key questions: 1. Why are we doing this, and what problems are we trying to solve? (The real reasons, not the industry buzzword reasons.) 2. What are my goals and desired results? 3. How will success be measured? 4. How will this effort impact existing users? 5. How will this impact existing dev team(s)? 6. How will we respect the business and existing user needs during this process?In other words, I know I’ll still have to get bug fixes and hot items to production in the legacy stack while managing the efforts of replatforming. Once my questions are answered, I approach the problem the same way I approach a brand-new set of requirements. After all, this project is just like any other that I’ve done before. There’s a start, there’s a destination, and my number one job is to formulate a complete plan so I can give my team the exact directions they need to get to our destination, with no wrong turns, no detours, and no roadside emergency calls to AAA.Manage scope creepI really enjoy legacy replatforming efforts, because I’m usually armed with user insight that I wouldn’t have if I were developing a brand-new product. Odds are, I’ve received an earful from users, developers, and the client alike regarding the pain points of the existing application. Because of this, I tend to know exactly what I’m getting myself into.There’s a catch, though. Once the project begins, the requirements are locked in – solid – with zero exceptions. This is the second largest trap I’ve seen so many teams fall into over the years (the first being overall lack of planning). We get a quarter of the way through, someone points out a pain point we didn’t know about – often because of poor planning – and we take it upon ourselves to remedy this pain point during the replatforming effort. First of all, had we planned accordingly, we’d already know about this pain point, and it’d be accounted for. Secondly, by taking on this initiative mid-flight, I’d be willing to bet this month’s paycheck that this “easy fix” wasn’t planned properly and will take two, three, or even four times as long as expected. Anytime you hear a developer say, “oh, that’ll be easy – sure, no problem,” don’t listen. We all know that person. I’ve been that guy. More than once. I have the t-shirt, and the scars. They don’t know the effort yet, so don’t trust them when they say, “it’s easy.” You’ll be let down more often than not. Scope creep will kill a replatforming effort quicker than video killed the radio star. Because we’ve planned accordingly (hint, hint), we’ve locked our requirements in, we know the plan, and we’re going to protect the plan – and say no to new requirements – until we’re done. I make my developers and stakeholders all agree to this upfront, and I remind them of this agreement every step of the way. This replatforming effort is going to net us the architecture we need to respond more quickly to business demands and add new features quicker with lower effort; we can worry about all the “wish list” items when we’re done. Do it in phasesPart of the planning process should include a clear strategy on how we can release our new, shiny efforts into production as we complete them. This means breaking down the project into chunks, and addressing any architectural needs and concerns that will allow both the legacy app and new app to coexist.  You don’t want to replatform in isolation, waiting until we’re “completely done” to release it all in one big ceremony. By releasing updates continuously everyone stays engaged, especially key stakeholders.This won’t be an easy task, but we as engineers are creative problem solvers – we make the seemingly impossible possible. It’s a big ask, but I’ve never met a situation where my team and I weren't able to find a way to make it happen. I’ve made React live with Angular, .NET play with Java, Python feed Ruby on Rails – you get the point. Where there’s a will, there’s a way – it just requires creativity.Learn from past mistakesWe’ve all heard the quote “insanity is repeating the same mistakes and expecting different results.” One could argue that the exact same thing could be said about replatforming. Remember back in our planning where we identified the “why” – why is this needed, why are we doing this, why is what we have currently not working for us? We need to clearly identify the pain points of our existing application and use these discoveries as an opportunity to grow from our past mistakes. These pain points, of course, stem from poor decisions, poor architecture, deep coupling, poor naming conventions, and other bad practices that might have crept into our existing code base. I’ve found, if nothing else, past decisions tell me what not to do this time around. To be clear, I’m more focused on developer experience here. If there are any low hanging user experience pain points I can remedy without affecting my effort or deliverable, sure, why not. But, my main focus is, and will always be, developer experience as part of this process. If I can use the replatforming to improve developer experience, new features get developed quicker, bugs get resolved faster, more code gets to production, and my team has more fun along the way. By taking inventory of the existing pain points in areas such as our current architecture and infrastructure, I have a clear starting point of all the roads I definitely don’t want to travel down. Examining the “why” behind each point will help to guide my decision-making process moving forward to ensure we choose the right technologies and solutions to the problems at hand.Don’t rush itI often meet with stakeholders who are hesitant to invest in replatforming because they have a hard time seeing the value in redeveloping something that is currently making money and “works just fine”. After all, they don’t know what it’s like to work in the legacy application day to day – they’re not the engineers, but once the engineering side of the house finally persuades the business side of the house to give permission for the replatforming, the stakeholders often concede by saying, “fine, but you have until [too short of a timeline] to get it done.” The project is already sunk before it’s started. Corners will be cut and poor decisions will be made, not on purpose, but because there won’t be plans in place to manage the needs of the existing product while replatforming in tandem, and your development team will end up overworked, burned out, and software entropy will start creeping in.When planning your replatforming engagement, stakeholders and engineers alike should be realistic about the timeframe, and leave time for the unknowns, surprise production bugs, proper tooling up of new technologies, and life in general. The best way to protect any project is to keep your developers engaged, and give them enough time to set the company up for success. Only then will they be able to deliver a codebase that will support the company for years to come, engineered with continual growth in mind. About the Author:Wes Dollar is a full-stack engineer with 21 years of experience in website & web-based software development. He has served as a business analyst & tech lead for clients ranging from startups to Fortune 500 companies. He has a passion for providing solutions to complex problems in a manner that is intuitive and easy for the end-user to use & understand. Most of his career has been spent on the open-stack side of the fence, where he has made many contributions to the Laravel (PHP) ecosystem. He is an HTML5/CSS3/JavaScript expert with strict compliance to W3C standards & 508 accessibility. He specializes in ecommerce & conversion rate optimization through UX design and also specializes in developing business systems, processes, and integrations.NEED HELP REPLATFORMING? LET'S TALK.