Tag: maintaining software

  • The Agile Manifesto – A Practical Look

    The Agile Manifesto – A Practical Look

    The Agile manifesto started an entire industry. It has even been the focus of numerous “religious” debates and arguments. However, it has a lot of wisdom within it that is often overlooked. The main ideas are as relevant today as they were when it was first crafted. Therefore, it is worth our time to review some of these wise nuggets and consider applying them throughout our software development efforts.

    The Manifesto Is Not The Agile Methodology

    We need to start by clarifying that the Agile Manifesto is not the same as the Agile Methodology for building software. The manifesto was used to create the methodology. However, they are not one and the same. Think of the methodology as an attempt to turn the manifesto ideas into reality. It is easy to see where many agile or extreme programming techniques got their start in the manifesto. Nevertheless, your opinion (and experience) of one may be noticeably different from the other.

    The manifesto came out of a desire to create better software. The first point drives that concept home. The highest priority is to satisfy the customer. This statement should be the “why” of any application and cannot be turned into a process. The Agile methodology provides a lot of ways to assist in this goal but does not guarantee it. Looking at it that way, we can easily see where a team could use Agile methodology precisely as described and still fail to deliver a successful project.

    Work As A Realist, Focused on Delivery

    There are twelve points the Agile Manifesto lays out.  These emphasize producing a solution the customer wants while acknowledging the realities of software development.  The most important of these practicalities, to me, is delivering results along the way to the final solution.  This process recognizes that customers often change their minds, communication problems exist, and showing is better than explaining.

    We all know there is often a disconnect between business representatives and technical resources.  The language does not always translate and skilled liaisons are in short supply.  Thus, we can lower the bar by deciding to be flexible from the start.  This approach is not a way to ignore requirements gathering, design, or other due diligence.  Instead, it assumes we will need to revisit those steps.

    The Manifesto Points

    Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

    Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

    Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

    Business people and developers must work together daily throughout the project.

    Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

    The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

    Working software is the primary measure of progress.

    Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

    Continuous attention to technical excellence and good design enhances agility.

    Simplicity–the art of maximizing the amount of work not done–is essential.

    The best architectures, requirements, and designs emerge from self-organizing teams.

    At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

    The Agile Manifesto

    Work Together For A Common Goal

     There are numerous rules of software development built into this manifesto that are needed for a successful product.  We already stated a focus on making the customer happy.  This statement is not arguable.  A product that does not please the customer is a failure by definition.  Another important concept that is woven throughout the manifesto is the Pareto Principle.  This rule says that 80% of our effort is spent in the last 20% of the product.  That means we can get “mostly there” relatively quickly. This focus on getting most of the way to the solution is highly valuable.  

    Let’s think about that a bit.  When you are almost done, you likely have a lot of the core functionality covered.  The “happy path” is complete and functional.  That is an essential factor in getting feedback.  You have a use for the product the customer can see and experience.  They have something concrete to assess and a solid basis for requesting changes.  

    Gaps In Knowledge

    It is not very different from taking a vehicle for a test drive.  You can get a feel for it and might even see some weaknesses.  This last factor is critical to the success of a product.  Customers should not be required to know edge cases and outliers in building a solution.  That is up to the developers.  However, these are issues that often fall into the “you do not know what you do not know” category.  When you provide a demo or partially complete solution, you give the customer a straw man to work with.  That is far more concrete and relatable than describing functionality or showing them a flow chart.

    Keep It Simple Somehow

    The focus on delivering regularly and the underlying Pareto principle ideas lead us to opportunities for the KISS approach.  It is amazing how often customers will scope out requirements to get working software in their hands sooner.  This carrot is dangled in front of them during regular demos and releases.  Yes, there are gaps.  However, a good relationship with a customer can lead to a shorter path to something they want and consider “done.”  Who would argue against that?

    Remain Flexible

    The last central theme I want to point out is the focus on change. When we create software, it is crucial to think about flexibility. We are not building a system to solve a specific problem and situation. Instead, we are trying to provide a solution that is useful in a broad range of configurations. The world is also constantly changing. Therefore, even though we can be assured of a need for new versions of our software, we need to be smart about it. A sound system is built with growth and change assumed. That means we need to prepare for it from the architecture through to each step of implementation.

    The Agile Manifesto has been around for many years. Nevertheless, it still is needed to remind software developers and teams of what is important. When we embrace these core concepts it reduces risk and improves our chances for success.

  • Exploring Your Tool and Application Options

    Exploring Your Tool and Application Options

    In the last few years, I have often found myself researching application options and tools a customer is interested in.  This usually starts with a suggested tool or two that they like (or have a few specific dislikes).  Then I am asked to see what is available that is similar but better.  The fruits of those little projects are a good start for this article and will likely surprise you.

    A Target-Rich Environment

    The first thing that jumps out at me when I start these projects is the number of application options that can be found with a search or two.  Even “niche” applications like visitor recording, B2B e-commerce, and database development tools will return several options.  Better yet, most of the alternatives I come across have at least a free trial period of a few weeks while often providing an unlimited free option.  Cost is rarely an issue.  The tools available these days are regularly priced in a way that allows customers to start simple and inexpensive or go all-out for a high-end solution.

    Worth the Investment

    I mentioned a trial period available for most solutions.  When you combine some of the training material often provided with the ability to “play” with these applications the time requirements can become overwhelming.  However, an hour or two will typically be more than enough to evaluate the usefulness of these tools.  At times, you will be able to eliminate options in fifteen minutes or less.

    This time spent perusing your options is well worth the investment.  Your initial list of a few possibilities can grow to several.  Then they can be pared back down to a short list.  At this point,  each solution is likely a good fit (or better) for your needs.

    Evaluating The Options

    The number of viable application options makes the selection process easy to overlook.  When you feel you cannot wrong with any of the available choices, then it is logical to keep your investment small and avoid going deep into the evaluation.  At this point, it is worth looking at the reasons that started the search process.  Some requirements were not being met by the original solution.  They should be verified in the short list of options.  The search process will also provide new elements that are desired in the solution.  That is just the nature of reviewing solutions in any vertical.  Your comfort with a prior solution can keep you from considering what new advances and features can do for your productivity and company.

    Make sure your list of requirements is kept up-to-date with what the research has taught you.  In my case, I am often in a position where I cannot make the call on that list of requirements.  Instead, I make a note of features and enhancements listed by some of the solutions that may appeal to my client.  As part of the review deliverables, I always include these features as an addendum to the requirements list or as “other things to consider.”

    The More The Merrier

    Many tools have a way to invite others into a demo period.  Take advantage of this and find some other people that can give you feedback on the product.  They do not need to spend much time at all in the product.  Instead, they can quickly provide their initial reactions to the features and interface.  This is a great way to avoid making decisions in a vacuum while also sending a form of a trial balloon to determine how open others are to this change.

    I hope these brief suggestions spark you to re-consider your current tools and evaluate how the landscape has changed.  A considerable productivity boost might be just around the corner for you and your team.  Of course, I also am happy to help you in evaluating your options and finding the best tool currently available.  I would love to discuss your specific requirements and how to find the best solution.

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