Blog

  • Upgrades vs Stability for Production Solutions

    Upgrades vs Stability for Production Solutions

    One of the pervasive properties of software is change.  Whether this change comes from regular enhancements or environmental updates, it is one that should be considered strategically for production software.  Thus, the balance of upgrades vs. stability needs to be considered as your solution ages.

    Easy Upgrades

    Modern software environments provide features that make upgrades easier than in the past.  A great example of this is WordPress and other “plugins supported” solutions.  The goal is to make administration of these sites easy and quick.  Thus, you often can upgrade a plugin or even the core software to the latest version with the click of a button.

    This ease extends to core environments as well.  There are a lot of automated update tools available to keep all of your software up to date.  The most well known of these is the windows update tool provided in many recent Windows OS versions.

    Impacts to Stability

    This ease of administration is excellent.  However, it is also hazardous.  An upgrade may break your entire site and lose sales.  As scary as that sounds, even worse side effects can happen.  Data may get corrupted, backups can become invalid, and fulfillment can be sent to the wrong address.  These worst-case scenarios are not exactly typical, but they can happen.  Upgrading your system can turn a steady running and reliable system into a nightmare.

    These concrete impacts are just one facet of the considerations.  Updates may change the user experience.  Something as trivial as moving a menu item can cause user headaches and negative backlash.  For some great examples of this, look at some of the Facebook changes over the years that caused a massive outcry from their user base.

    Managing Upgrades vs. Stability

    It may seem that these risks point to leaving your software in its original state as long as possible.  Fewer changes should lead to higher stability.  This is only partially true.  A stable system is more accessible to hack and may be steadily approaching a point of no return.  In the latter case, this can be a point where the system lacks the resources to support the user base or amounts of data within the system.

    There are also license considerations and support.  Older software may not be supported by vendors entirely or at all.  Thus, we need to find that balance.  Here are some high-level steps that can be taken to keep your solution up to date while minimizing risk.

    Scheduled or Periodic Updates

    Vendors do not release updates on the same schedule.  However, you can set a timetable for when you will apply updates so you can keep those updates on a plan suitable to your business.  I recommend updates on a frequency of two to four times a year.

    Test, Test, Test

    It is recommended that you have multiple environments during implementation.  This is even more important once you “go live.”  The value of these other environments is that they allow you to create an identical version of your production system for testing.  Thus, nearly all of the risk can be assumed by a “test” environment instead of production.  This is not a silver bullet, but it is pretty darn close.

    Backup, Backup, Backup

    Before any update is made, make sure the whole system is backed up.  This will allow for roll-back in case an update is not viable.

    Avoid Bleeding Edge

    When you follow the suggestions above, it should help you buy some time before implementing an update.  This should be embraced and used to allow you to pass the risk on to other customers.  They can perform the update, and their feedback will help you avoid problems and reduce risk.  In effect, waiting on an update allows others to be your guinea pig.

    The Bottom Line

    These are general suggestions, but embracing them can be very useful.  There is always going to be a challenge in finding the balance of upgrades vs. stability, but when you reduce risk, it makes success more likely.  Following the steps noted here can provide a win-win situation where you have current software and a stable experience for your customers.

  • Improving Quality through Testing as part of Implementation

    Improving Quality through Testing as part of Implementation

    I do not want to shock you, but software often has bugs.  We may call these “features” or “known issues,” but in the end they are bugs.  These defects are just part of being human and trying to craft large and complex solutions.  Sometimes we make mistakes.  The challenge with these errors is finding and eradicating them whenever possible.  Thus, improving quality.  That is where testing comes in.

    Not a Popular Focus

    It is hard to argue that QA and testing are treated with proper respect.  These tasks that are critical for good software are often dealt with as a “nice-to-have.”  Whether the focus is unit, system, or acceptance testing the needed time is rarely allotted.

    Software development has advanced and embraced the design and deployment steps along with implementation.  However, testing is still lagging in how we approach it.

    Embrace All Testing Types

    These are sweeping statements so your experience may be very different.  However, most projects are starting to embrace the value of testing, just in baby steps.  Development tools have been instrumental in this progress.  The ability to create and run unit tests along with implementation has made it almost an automatic step.  Unfortunately, this does not extend to the system and acceptance testing.  Even worse, that is where most bugs get through to a customer.

    Unit testing is great, but just the first step.  A good strategy will include system testing to make sure the pieces fit together and work properly.  Once that is accomplished, a solid acceptance plan is needed to ensure that requirements have been met. These testing types may have different names in your company, but they boil down to three areas.  Test the code modules and components by themselves.  Then verify that the modules work together properly.  Finally, check that the solution matches the original requirements.  Much like a game of telephone, it is not hard to confuse the original goals by the time we get to the end of the project.

    Improving Quality Requires Testing Throughout Implementation

    The problems with making testing a step at the end of coding are cost, effectiveness, and perception.  Cost is a function of fixing issues that arise.  There are several articles written about how the cost of fixing a bug increases as you move along the life cycle.  Thus, we will take that as a given.  The sooner a bug is found, the less the cost of fixing it.  Therefore, finding bugs early in development leave us more resources to create better quality software and deliver it on schedule.

    The impact of timing on the effectiveness of testing is not often discussed.  However, it becomes evident when we look at the situation.  A unit test or similar testing early on in the life cycle will have limited inputs and outputs to validate.  The permutations of data inputs and output are going to be small when compared to larger systems.  Once you start putting together those “units” the complexity increases exponentially.  Thus, testing the system increase in complexity as well.  Likewise, the likelihood of 100% test coverage starts to decrease dramatically.  When we include proper testing earlier in the life cycle, we can implement it before the software complexity gets out of hand.

    The Perception of Testing

    Finally, we need to look at how timing can impact the perception of testing.  When it is included throughout the implementation portion, it becomes just a part of development.  It works hand-in-hand with creating software, just like writing, compiling, and commenting code.  However, when testing comes at the end of the implementation phase, it can be seen as a blocker.  The software project was chugging along fine until the testing team stopped progress and forced the developers to go back and fix bugs.  This approach puts QA staff in the position of being the guardians of a release and the ones that bear the burden of saying whether it can proceed.  Thus, we put QA staff in the awkward position of doing their job right or letting us “ship” the product.

    Baby Steps

    I am a big fan of steady growth and improvement.  The issues listed above can be significant and even overwhelming to address in one shot. Instead, look for ways to make improvements with each release.  Start from simple tasks like good unit tests, get comfortable with them and then move forward.  Find the means to document, reproduce, and then automate as much as possible.  Once testing becomes automated and part of your daily development you will see dramatic improvements in software quality.  It is time for us to move software creation out of the realm of dark arts and into the light of reproducible high-quality processes.

  • Using Milestones For Project Communication and Success

    Using Milestones For Project Communication and Success

    One of the important parts of tracking project progress is defining milestones.  These are points during the project where the required tasks and the goals for time meet.  It only makes sense that the definition of milestones and how they are treated are an important part of project success.

    Defining Milestones Simplified

    Although these steps in the definition process are necessary, that does not mean they have to be complex.  Every project is different, but I have found these guidelines useful.  In fact, I use them every time we need to craft milestones.

    1. Milestones must have a deliverable

    Defining a deliverable for a milestone is rarely a problem.  However, I have seen vague descriptions like “complete the application UI” as the total of the objective.  This description is a start, but not truly definable.  Nor is there a deliverable mentioned.  We have to be able to say a milestone is complete (or not) without ambiguity.  This example is improved by including a UI demo to be delivered as part of the objective.

    2. The deliverable must be visible to the customer

    This point is often an issue during a project.  There will be a step that includes securing the site or building a backend database.  Unfortunately, the implementation does not have a visible result. That is not okay.  Find a way to craft the deliverable so that the customer can see that progress has been made.  The progress may be a login screen tied to an ACL or the result of some select statements to show default data in a database.  When in doubt, modify the milestones, so the “invisible” work is part of visible steps.

    3. Provide a Method For Feedback

    Milestones are more than just getting work done.  They are also an opportunity to gather customer feedback.  Use the milestone deliverables as a way to verify the implementation is still on track with the vision and goals of the client.  This option helps deliver a successful project instead of just delivering a project.

    Defining Milestones For Success

    We have already alluded to milestones being about more than progress.  They can also be designed to improve the chances of a successful project.  As mentioned earlier, the first step is to ensure that customer feedback is part of delivering any milestone.  This goal can be achieved through regular demos and review sessions that coincide with milestone deliverables.  I find that presenting milestone deliverables in some way is useful for drawing out feedback as well as a sort of test of the deliverables.  That extra look over the deliverable can be a sanity check well also revealing gaps.

    Scheduling the milestones in a way to reduce risk is recommended.  When the milestones that have the most risk are tackled early in a project, it allows for the less risky steps to be used to make up time.  Of course, that is not always possible.  In most cases, the work on challenging items early in a project is a way to bring up estimation issues and slippage sooner.

    Defining Milestones in a Vacuum

    We are not always a part of the project definition.  Thus, we run into those projects that are ill-defined and yet, we want to be successful.  In these cases, I find it is best to break the work you control (or are assigned) into milestones.  Your position in the team may not allow for customer feedback as part of milestone delivery.  However, you can usually find someone to which the deliverable can be presented.  Every little bit helps.

    Even the largest projects can be broken down into smaller “sub-projects.”  This step is where milestones come into play.  Thus, an over-whelming or “impossible” task becomes more manageable.  Since there are so many ways projects can go wrong we need to use tools like milestones to improve our chances for success wherever possible.