Tag: maintaining software

  • Building a Code Review Culture

    Building a Code Review Culture

    I was recently in a conversation about software development and asked about my thoughts on doing a code review. The assumption was that a code review is a good thing. However, there was a question as to how they can be done properly. It may sound like a cliche, but that is an excellent question. There are billions of lines of code written each year, from scripts to full-featured languages. We need to be aware of how to write and produce better code. The review process helps us do that.

    What Is A Code Review?

    We should start with the goals of this practice. Of course, companies vary in their official objectives. Nevertheless, code reviews almost always have the same list of goals.

    • Reduce bugs
    • Improve Quality
    • Verify Adherence to Standards
    • Cross-training/Leverage Expertise

    There are nuances and details to each of these items. However, a process that addresses these is off to an excellent start. We should not do anything simply to be busy or conform to a norm. We want to have concrete value in our work, and the above items give us that.

    Developer peers typically do a code review. There can be any number of participants, and it may be direct and in-person or performed off-line. There are tools to assist in a review, or “paper and pencil” approaches might be used. The highest level description of a code review is a person (or persons) walking through source code with an eye for improvement or errors. We can look to the above objectives to help us flesh out this process to make it more effective.

    Reduce Bugs

    It is frustrating to developers, but many bugs are easy to detect. There are typos and simple logic flaws we miss while cranking out code. The second set of eyes can often help us quickly spot these issues and address them. A code review that aims to assess logic and scan for inconstancies can help us squash bugs sooner and faster. This is not a process without cost. It takes an investment of time to review code and provide feedback. However, it is worth the effort. We gain in quality but also productivity as we work together to implement solutions that are peer-reviewed. The things I am most attuned to are not the same as your experience. That means a few minutes of your time may easily determine bugs that take me hours to track down. Minutes for hours is always a worthwhile trade.

    Improve Quality

    Quality and bugs are related but not the same. You can write low-quality code that is bug-free. Yes, I mean that. There is a lot that goes into quality. It has to be correct, maintainable, scalable, stable, and more. A code review helps bring the team to the same page. The programming standards can be reviewed and feedback given on specific code rather than just functionality. That leads to better developers, tighter code, and a consistent style throughout the application that makes it much easier to maintain. You get a reward today and in the future for going through this process.

    Adherence To Standards

    Every organization needs a standards cop. There is value in everyone on the team rowing in the same direction. This objective is partially addressed by standards. While there are automation tools that enforce these rules, not everything can be reduced to a rule. The code review process allows the team to go over processes and standards with an eye towards to enforcing and improving them. It is easy to take a short cut in a rush to solve a problem or forget to “clean up” a quick code snippet. That is where this process comes in. The author has someone to follow behind and provide accountability for the work before it is committed up the chain.

    Cross Training

    Another benefit of going through this effort is cross-training. Team members are at least exposed to areas they may otherwise never see. There is always a cost to cross-training in terms of time. However, a code review adds value immediately while still moving forward the breadth of experience in the team. Members that are completely ignorant of a section of the solution can gain insight and even familiarity through this process. They not only see code, they are brought into the discussion as features are created, bugs found, and decisions made. They also have a context to work with in terms of code that has been reviewed in the past.

    A Worthy Investment

    My goal through all of this is to show that there is value in doing code reviews. However, it is not something you can magically start and immediately do fully. There is an art to being able to walk through code and provide insight. That takes time and experience. Therefore, the best time to start this process was last year, but the second best time is now. Get out there and bring the team into your coding.

  • Managing Upgrades and Software Versions

    Managing Upgrades and Software Versions

    Managing upgrades is something we all face. That. is true whether you are running your software in your house, at a small business, or for an enterprise. There are versions released regularly as often as quarterly, and sometimes we get the new version “free,” sometimes not. There are many things to consider when crafting a version roadmap for your software. Here are some things to help with that. These suggestions and warnings come from a broad experience with software and highlight some paths that can make your life easier.

    Managing Upgrades Through Major Versions

    The “old school” approach to managing upgrades was often made via major versions. Software companies would release a major version every year or so. Then you would take the time to get up to date. That approach quickly morphed into a leapfrog approach for many companies. The disruption of performing upgrades and costs of installs were enough that the benefits were often not worth the effort. There were also licensing constraints that made an “every other version” approach much more effective in time and cost.

    That approach is an excellent model for planning a version roadmap. There is always a cost to embracing/installing a new version. Often it works better for us to take on more changes less frequently rather than smaller changes more frequently. This approach also gives plenty of time for changes to “bake in” to the organization. Thus, allowing processes to evolve to embrace new features.

    Managing Upgrades Through Features

    Software used to promise needed features with every release. However, we have moved to a world where features are driven more by internal needs than marketing bullet points. Many organizations are content with staying on a version for years. These organizations prefer stability, and an upgrade tends to be large and feature-rich. That sometimes includes a push to move off of a version that is no longer supported.

    The risk with the above approach is running out of time before a release is unsupported. Likewise, the resources and upgrade paths can be limited. Less frequent upgrades can lead to much more complex paths and can put data at risk. Some applications go through “watershed” upgrades that require a significant data migration effort. Those typically require the users to be on a specific version before the migration is done rather than skipping through multiple versions.

    Obstacles and Road Signs

    The approaches listed are both valid, and either may be a perfect fit for your organization. We have already touched on some things to look out for. However, it is good to have a list to walk through in planning out your approach.

    • Be aware of watershed releases – When you have a release that will effectively be incompatible with prior versions, that can often be a “need to upgrade” marker.
    • Store Version media or packages – There are combinations of software required for a version that can become difficult to replace. Vendors move forward or may even cease to exist. Thus, it can be critical to access prior versions of software and even operating system tools when you delay your upgrades.
    • Know Your Features – I have found that it is rarely a good idea to take an upgrade just because it is available. While there is risk involved, there is also the factor of utilization. It is important to know what your software can do, and blindly upgrading can miss out on valuable features. Invest the time for reviewing release notes and training updates when available. This investment can pay for itself quickly and inform you of whether future upgrades are valuable or not for your needs.

    The Cloud Factor

    Software as a service and the Cloud can make these types of issues seem a thing of the past. However, even SAAS products have versions and upgrades. You might be in a situation where you can hold off on a version upgrade for a while, but that is rare. Even in those cases where you have a “choice,” it often is presented as a preview you can embrace sooner rather than later. While you lack choice, there are still actions you can take (and should) as part of your upgrade strategy.

    • Take advantage of backup options where possible.
    • Use and verify export options where possible. It is your data, make sure you have access to it outside of the SAAS product.
    • Keep current on planned upgrades, enhancements, and outages.
    • Plan for some time to test and verify updates.
    • Embrace the latest features as suitable to your needs.
    • Avoid company critical periods of work that coincide with a maintenance period or upgrade.

    The good and bad part of a SAAS product is that you are not responsible for the workings of that product. A lot of the management and administration tasks are taken out of your hands. Nevertheless, the steps above can help you mitigate risk at the cost of taking some of that management back on yourself. It is worth that trade-off. You will be happy to have a way to take your data elsewhere when a product becomes unusable, or a provider closes shop.

  • Addressing Technical Debt With Minimal Cost

    Addressing Technical Debt With Minimal Cost

    Organizations small and large move forward at an increasing pace. That makes it easy for things to be lost in the activity required to maintain our focus. These lesser tasks often include important deliverables that we say we will “get done later.” That is also known as technical debt. Put simply; these are the items left to do if we were to complete a project. When they are left undone, we are not able to claim a project or task is complete. This situation may seem easy to solve (just do the work), but it is not that simple. We have projects that are “good enough” that are super-ceded by higher priority projects. Here are some ways to address that technical debt without having to sacrifice those high priority projects.

    Research And Improvement Hours

    Many years ago, Google had a benefit for its staff that was shrewd in its approach. They set aside Fridays for personal projects for all the staff. These could be running with ideas for a side hustle or improving parts of the company or product. The organization sacrificed some time, but it ended up increasing the overall productivity of their workers. People will put in extra effort for things they enjoy. This benefit also made employees feel more ownership over the projects they worked on.

    There are many ways to adopt this approach to your situation. The easiest is to set aside a few hours each week for employees to work on whatever they desire. It could be training, chasing down a side project, or improving something they currently are working on. Those options may seem too open-ended. However, many employees will be willing to use that time to eliminate technical debt to feel better about the work they have done. There is also a morale boost that projects like this give to staff. The change in work focus allows them to do something different, which appeals to them more. They sometimes even find that there are parts of their job that they enjoy.

    Fill In The Gaps

    Many productivity suggestions include finding ways to tackle little things among the larger tasks. In our modern world of waiting for people to show up for a meeting, reply to an email, or waiting on vendor responses, there are many times we have “downtime.” These events could have us sitting and waiting without being productive while our path forward is blocked. When we have a list of little tasks available, those can be used to make use of that time. Fortunately, many technical debt items are a perfect fit for this.

    For example, documentation is often some portion of technical debt. In many cases, we can pick up and put down documentation projects fairly quickly. They have little intellectual requirements, and a rough draft of notes can quickly be captured. When these small tasks are made available to staff (or pointed out to them), there are opportunities to chip away at the debt list. Just a few minutes a day on these tasks can add up quickly over time.

    Technical Debt Side Projects

    It was mentioned earlier that a change in focus could be refreshing. Many of the technical debt items require a small project to address the need. This need can be in the form of data migration, simple automation, or data entry. All of these can be side projects assigned out to staff or for staff to choose. These side projects are typically one-offs where there is a lot of freedom to choose how they are done and the technologies involved. That can be a win-win for an organization. The staff member can use a side project to learn a new skill while the organization gets a needed item completed. In some cases, these side projects can lead to ideas for commercial products and other game-changing solutions.