Blog

  • Sticking To The Plan – Completing A Project

    Sticking To The Plan – Completing A Project

    One of the most frustrating situations in software development is when one side decides to “change the rules.” There have been examples on both sides of the equation that I have seen ultimately derail a project right before completing a project. We even do it to ourselves at times. I hope that listing a few common mistakes will help you identify and avoid them in the future. It may bring world peace a step closer.

    The Nickel And Dime

    There is nothing I can think of that destroys trust between customers and vendors than either side chipping away at the other. A vendor does this with a steady stream of little change request charges. Instead of working together with clear deliverables and a plan, they get stuck in the weeds. A client does this by trying to get tasks turned into “non-billable” and drags the team into unnecessary detail. The thing about software development is that it is complicated in most situations. There is enough to worry about without nitpicking the details late in the game. Do not read this as the “details” being unimportant. They are critical in completing a project successfully. It is just that those need to be hashed out early on and not when the end is nigh. When you do this, you will avoid a feeling of death by a thousand cuts.

    Just A Little More

    This particular anti-pattern may be the one I relate to most. There are two conflicting traits many of us see as we approach the end of a project. However, they can combine to spin us off into oblivion. The first trait is what I call the “90% high”. This situation occurs when we “know” we are almost through with a project and have a burst of energy to get across that finish line. Think of it as a runner sprinting that last one hundred yards of a marathon.

    The other trait is one we will call “just a little more.” This situation arises when we feel we are close to the end and can squeeze in a few more features or finishing touches. When we have that extra energy to drive to the end and a desire to keep adding a little scope, we can rapidly go off course. It is almost like we do not want to get across that finish line and instead want to stay “in the zone” as long as possible.

    Perfection Over Reality

    Sometimes completing a project is hindered by quality assurance and testing results. The application is almost complete except there are some bugs to fix. While some bugs must be addressed to provide a useful product, some others do not. For example, I have seen projects wallow in testing cycles as minor things like pixel-perfect displays, wording for labels, and fonts or sizes are “fixed.” These might be issues that impact the usability and correctness of a product. However, that is rarely the case.

    These sort of nit-picking details can drag out the testing cycle beyond reason. Keep an option for “known bugs” that can be addressed in a future version. Users may not wait forever while you perfect that current release. Even worse, I have seen situations where wording (copy) is minutely engineered only to find out that it ends up negatively impacting users. Yes, even copy can be over-engineered.

    Agile To Infinity

    One of the strengths of an Agile approach is that releases should be common and regular. However, that does not stop some groups from dragging out a production release. This situation is similar to the “just a lttle more” pattern. However, in this case, production releases are pushed off for “just one more sprint” instead of tightening things up and pushing it to users. Instead of a litttle item here or there, this pattern becomes a few more features, bug fixes, or performance improvements. Sometimes there has to be a person the team that can make the “fish or cut bait” call and drag the project across the finish line.

    These are just a few of the ways to avoid completing a project. You can find anti-patterns all over the web. Nevertheless, I find these to be highly common and often easy to avoid. Of course, it all starts with a plan, and then the team needs to keep working towards that plan. Changing mid-course can turn you right into an anti-pattern.

  • Ask And You Can Find The Tool

    Ask And You Can Find The Tool

    A recent discussion with an associate reminded me how often we ignore some great solutions for our problems. The Internet provides us with an easy way to evaluate literally dozens of options for many of our common problems. It is worth the investment to find the tool that suits our needs. Even better, we can learn that our problems are more common than we think. Even a niche problem will often have a number of potential solutions a good search away. While we can all stumble around and find some great gems, sometimes a plan is helpful.

    Avoid Distractions

    Apple showed that less can be more. Likewise, there is a lot of research related to having a large number of options. That makes sense. We can all relate to analysis paralysis, but it does occasionally sneak up anyway. A problem we want to be solved seems to make us even more susceptible to this problem. It creates a sort of “kind in a candy store” situation. We focus on a problem, find some solutions and suddenly we can be almost giddy. If you doubt it, then take a look at search results for any passion of yours. Maybe check out some new cars, beach homes, or enticing coffee flavors. When we get what we want we are more than happy to enjoy the shopping experience and getting lost in what-ifs. The Internet provides us too many options so we need to reduce that list quickly.

    Have A Plan

    One of the essential reasons for an RFP is to define what an organization needs. We see this in problem-solving all the time. A well-defined problem is easier to solve than one that is vague. Take similar steps to start your search to find the tool desired. Think about what you want and create a list of priority features along with some nice-to-haves. You can do this in a matter of minutes, and it does not need to be complete. Start your search focused on solutions that provide the requirements you listed. It is not uncommon to learn about features that most providers include or new options you did not know you required. Feel free to adjust your list as needed.

    Be Heartless In Reducing Options

    The final goal is to get your list to five options or less. That five number is on the outside. Most lists should be down to three at this point, if possible. That may seem like a difficult task. However, I have found in most situations you can find the products available and reduce the scope of “viable options” to a few within a few days at most. Also, it only takes days when there are dozens of options and they are complex solutions. Most applications whether a task tracking solution, an e-commerce platform, or a coding utility, can be swept through in a matter of hours. You can often find what you need to know with surface reviews and related searches. They will either meet your requirements or not. Price alone can often reduce your list quickly.

    Due Diligence

    The final step is to evaluate your shortlist of options. This step is time-consuming and essential in making the best decision. It often includes installing a trial version or using a demo period to get to see the solution in action. You might even watch vendor presentations and spend time discussing how a solution is the best for your needs. The process may seem like something that requires too much time. Nevertheless, spending time to find the tool or effective solution can often save you hours, days, or even months in the long run.

  • User Experience Should Always Be High Priority

    User Experience Should Always Be High Priority

    The User Experience aspect of applications is often on my mind. I am not a designer, but even the most simple solutions can be rendered unusable when one ignores UX.  A recent experience with a front-end to a web app. Reminded me of how bad it can be for a user.  My frustration ran high, and I would have walked away never to view the application again if I had the chance.  Likewise, I will complain to anyone who will listen about the experience and may sour others on it.  That is the last thing anyone wants for any application.

    The Intro – How I Got There

    Allow me to set the stage for this little drama.  I recently took a certification exam from the comfort of my home.  It has its annoyances but does save me a drive back and forth to a testing center.  There is a validation step to prep and ensure your environment meets the requirements as well as checks to avoid cheating.  Once you are validated, a proctor connects via text, does a few last-minute checks, and then your machine is sent the test.

    Overall, this is a good system, I think, and probably does a good job stopping people from cheating.  This solution is a good one in this case.  However, the experience I had leads me to think I will never try that again.

    A Bad User Experience

    The steps before the exam are where I had all my frustration. The exam process and experience was exactly what I expected.  We will start with the preparation step.  When you start into the prep process, you are given a nine-digit id to link uploads to the system.  You are sent a link on your phone, so you can take pictures and send them to the site.  The photos include the front and back of your picture ID (driver’s license) and then four to cover the front, back, left, and right view of your work area.  So far, so good.
    The upload process tells you what picture to take, flips to your camera app, then you click a button to submit.  The user experience gets bad quickly at this point.  There is no explanation about the pictures other than what I listed above.  I have no idea if you have to take a specific layout or from a certain distance.  It gets worse.  If there is a problem with the photo upload, you are taken back to the screen to enter the nine-digit ID and forced to walk through the screens again.  There is no error message or indication of what went wrong.  It does save pictures previously loaded, so at least once you get a successful upload, you do not have to re-enter that picture.

    A Painful Design

    The preparation process I listed above gets repeated precisely the same way when you log in to take a test.  You have to send an ID again and all of the pictures of the environment.  A bad UX is doubled down on.  This becomes more frustrating when the proctor has access to your machine camera and will likely ask you to pan it around your work area.  Thus, confirming a third time that you have a valid environment (no notes on the desk or anything like that).
    The same message-free process is used again, so in my case, I spent around forty-five minutes retaking those twelve pictures.  I lost count of how many times I took each, but I think I attempted each one at least three times.  It is more frustrating because it was not an Internet connection on my end.  I had stable and reliable high-speed connections throughout that time.

    A Moral To The Story

    I mentioned that this solution as a whole is awesome.  It is also one that was critically needed in a time of social distancing and stay-at-home orders.  It allowed me to get a certification test done much sooner than I would have otherwise.  I appreciate that.  However, a user experience that has a user in limbo for over a half-hour is far from good.  I think all of us would be happy to walk away from that experience.
    In this case, that validation process was a small part of the overall solution.  You may have seen features like this that are a registration, login, or even close account solution.  These are small parts of the overall solution and often seen as not integral to it.  For example, I often work on MVP solutions that ignore some of these “minor” features and even downplay the overall UX.  That is a dangerous approach to take.  Consider how much damage this bad experience for me will translate into bad feedback spread to others.  That should make you think twice before lowering the priority of the UX for your solution.