Tag: developer

  • 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.

  • Coding While Impaired – A Reason For Project Failure Rates

    Coding While Impaired – A Reason For Project Failure Rates

    Every so often you will come across a comparison of drunk driving to trying the same action while sleep deprived.  This usually is surprising to spectators when the lack of sleep is shown to be as bad as consuming a lot of alcohol.  Although developers tend to be comfortable drinking and drinking alcohol, they are far more known for long hours and lack of sleep.  Maybe this correlation can also be extended to the larger than average project failure rates.

    The Caffeine Culture

    I have met very few developers over the years that are not proud of their caffeine consumption.  It is a badge of honor to walk into a late night session with six packs of energy drinks.  This becomes their standard approach to the long hours regularly required of those that chose to code as a career.  The problem is that the long hours are inflicted as much as they are elected.  I have experienced a countless number of projects where the approach to hitting target dates is to cancel time off and extend hours to seventy or more per week.

    The typical attitude is to grab some energy drinks and pour more hours into a project to get it on track.  I have no problem with this approach.  However, I do question those that are surprised by lower quality after these pushes.  You can design and test all you want.  However, a team that is comprised primarily of sleep-deprived members is roughly the equivalent of those same people after an evening of adult beverages.

    Mental Work

    When you consider how much more mental coding is (as compared to driving) the problems become apparent.  You have people that are not at their best mentally doing tasks that require concentration and complex thinking.  Once I started down this road, it seemed evident that these projects would have high amounts of errors and thus failure rates.  The worst part of all this is that those increased errors cause more time to be needed to get tasks done.  That leads to less rest and sleep, which leads to more errors.  Thus, a death march is born.

    The amusing thing is that many companies have policies that go as far as terminating those that show up for work inebriated.  Yet, they have no problem demanding the long hours that can lead to the same mental state.

    A Different Path

    There are some instances where the long hours come from poor planning or management.  Unfortunately, many of the situations arise from heavy competition, low budgets, and the related tight deadlines.  You may argue that means that team leaders are left with no choice.  I would say otherwise.

    When you look at productivity curves for the average human, you see a drop off as the day gets “too long.” Studies show the length of a comfortable (and productive) workday varies from worker to worker.  Nevertheless, we can work with averages and observation.

    I recommend that adding hours and pushing for longer work weeks be done in an incremental way.  Ease your way into it earlier in a project if it looks like it will be needed.  You can then closely observe the developers and bug rates to see how things deteriorate.  At some point, there will be a diminishing return that makes long hours not only useless but detrimental.  Once you have that hard limit, you are better served to add resources or accepting slipped dates.

    Developers may like to be “edgy” by embracing sleep loss and long hours.  However, this is not a productive approach to software.  Maybe treating them as imperfect humans will help improve project failure rates.

     

  • Making the Most of The Implementation Phase

    Making the Most of The Implementation Phase

    The amount of time spent on each step of the software development life cycle varies from project to project.  However, the implementation phase is always the most significant portion.  That means this is the area where projects can fail or succeed.  We can ace all of the other steps in the life cycle, and a mediocre implementation will wipe out all that good work.

    Balance The Effort

    In my experience, the most impact during implementation is to try for a balanced effort from start to finish.  Avoid a slow start and then hectic finish to hit deadlines.  Particularly for longer stretches of implementation and big projects.  This is a killer of productivity and quality.  I have seen project after project that burns out team members with a hard push at the end that could have been avoided.  The way to accomplish this is to set proper milestones and goals that balance the effort throughout the phase.  When you keep the goals in sight, it is easier to keep everyone focused and avoid the lazy drift big projects see at the start.

    Regular Sanity Checks

    Another essential trait of a successful implementation phase is regular checkups.  These are not progress focused as much as they are about requirements.  There are a variety of ways to do this, but the result should be a review of what is being implemented to ensure it is still in line with the requirements.  This includes reducing feature creep as well as correcting design drift.  Short projects will not suffer from this too much.  However, long-term or large projects can see dramatic implementation problems and slipped dates from adding features or skewed solutions to requirements.

    The good news is that this task does not need to be done by the implementation team.  Team members from other phases (or QA staff) can perform sanity checks of features.  They can measure against requirements and then meet with the implementation team to correct problems.

    Frequent Code Commits

    This may seem minor, but regular code commits are critical.  I have come across numerous projects that tank because of impossible code merge needs, or a team member disappears along with their source.  Ideally, this is built into the daily regimen of the implementation team.  Regular merge and build steps are a big help as well.  Much like the sanity checks above, regularly testing that you have all you need for a successful build helps keep from drift.  This factor is a solid argument for best practices like continuous integration and regular builds.

    Test Early

    Testing has gotten better but still is too often left to the end of the project.  This is when the cost to correct errors is at the highest level.  It has been established over the years that the earlier a bug is detected, the easier it is to fix.  There is a bit of a challenge in early testing as (by definition) the implementation is not yet complete and ready for full testing.  This timing also means that there will be more time spent testing than when it is held until the end.  That is entirely ok.  The more testing that can get done, the more likely bugs will be found and squashed.

    When you combine early testing with regular builds and commits you get feedback early, and quality is built in from the start.  This approach even makes the testing process better.  The test scripts and tools can be used and refined during the implementation phase to improve coverage and confidence in the results.

    Note that none of these improvements are substantial on their own.  These can be implemented as part of the process and pay worthwhile dividends when the project completes.  All of these can also be tried out to see how they work for you.  When in doubt, give it a shot and verify for yourself whether these are good for your team.