4 Questions a Software Developer Should Ask Each Day

This is my take on a lesson I was taught very early in my career.  It made sense to me right away, but after applying it for over a decade I’m convinced its one of the most important things I’ve ever learned.  I hope to do it justice in sharing it with all of you.  I’ve written this from my perspective as a custom software developer and consultant, but I believe it applies universally to software developers.  If you’re an in-house developer, just think of your clients as the folks you build software for (i.e. the users, your managers and the owners, etc).  Start by asking yourself:

Question #1: Is your client happy?

This should be the first thing on your mind at all times.  A happy client will come back for more. They’ll tell their friends about you.  They’ll promote your brand.  They’ll keep your pipeline full.  Clients are your lifeblood and keeping them happy is the only way to survive long-term.  I know… this is obvious, right?  Well, it’s not that easy to execute on all the time and a lot of developers don’t really understand what it means.  We’re not looking for short-term happiness brought on by just doing whatever they ask or by applying quick fixes in difficult situations. We’re after long-term, sustainable happiness.   How can we achieve that?

Manage Expectations:

This is huge.  You have to start managing your client’s expectations the moment you meet and continue doing so throughout the course of the relationship.  The moment you stop filling their heads with facts, they’ll start filling it with all types of other things.  Expected timelines will creep, visions of features will morph, old conversations will take on slightly skewed meaning in the light of new information that isn’t shared and wasn’t part of the original conversation. Expectation creep is not malicious… its human nature.  Small expectation gaps are like a crack in the foundation of your house.  With effort you can avoid them in the first place, but if allowed to form and grow they can be devastating to a relationship.  Communicate clearly, completely and often. And memorialize EVERYTHING in writing.

Honor your commitments:

Lots of promises are made at the beginning of the job.  Most of them will be recorded in a contract that commits you to honor them. However, not every intention, notion and promise will make it in there.  There will always be a new way to look at a deliverable later on and re-interpret its meaning. This tends to happen when the going gets rough. Maybe things are taking longer than anticipated. Maybe you’ve had staff or personal issues that distracted you from the project.  Stuff happens.  Renegotiate the terms if it’s reasonable to do so, but don’t, under any circumstances hide behind a nuance in the contract language or try to back away from the original spirit of the deal.  You know what you committed to. Honor it and get the job done. It will hurt at times, but your client’s happiness and your reputation depend on it.

Be a partner:

You’ve agreed to help your client solve a problem.  The best way to do that is to look at the issue as your own.  Do your best to see and feel the goals from your client’s perspective.  Own the problem.  Your client can tell the difference between this approach and that of the last firm who was just “doing their job”.

Be Available:

You should return calls/emails in a reasonable and consistent amount of time and you should answer the questions contained in them.  If you take long, random amounts of time to respond you’ll frustrate your clients. If your late response doesn’t answer the question, you’ll infuriate them.

Stick to your principles and do the right thing:

Your client hired you because they don’t have the time, or more likely the expertise to accomplish the task.  Even though you’ve been brought in as the expert, there will come a time where the client insists you to do something that you know will hurt them in the long-run.  It’s your duty to hold your ground in these situations. Take time to explain why this approach will be harmful. Give examples. Be steadfast. Ultimately it’s their decision, but you owe it to them to try and do the right thing.  I often liken this role to that of a personal trainer.  If your client came to the gym and told you they were tired and didn’t feel like working out, you could satisfy their short-term desires, buy them a muffin and a shake and plop them in front of the TV for a little Judge Judy, but that’s the easy way out and it won’t help them accomplish their long-term objectives. It’s your job to get them motivated and on the treadmill.  Don’t be a coward… do your job!

Be enjoyable to work with:

Make a connection with your clients on a personal level.  Ask them about their kids, their pets, their hobbies.  Be human and have a sense of humor.  Your client will like you if you help them solve their business problems.  They’ll love you if you help them have a good time doing it.

Be humble:

I’ve already stated that you’re here as an expert, but that’s probably only true for your specific role in the overall initiative.  Whether you’re building software or developing a social media strategy, you’re doing it for them.  Don’t come in acting like you’re the savior.  Do your part and do it well, but trust that they understand their business better than you do and they have the grand vision.  This is a learning opportunity for you and it’s probably the best part of being a consultant.  Listen intently, learn from them and make sure they know you’re doing it.

Question #2: Is your work correct?

If you’ve executed on the principals from #1, your client’s in a happy place.  Now it’s time to deliver and your solution better work.  It must accurately achieve the goals of the project in a meaningful and sustainable way.  It has to work today so that they can execute their business plans and begin to see some return on investment.  It has to be flexible enough that it can be modified as their business evolves.  It has to be scalable so that it will remain viable as their business grows.  Ultimately, this becomes an extension of #1.  Your product speaks for you when you aren’t around and it should continue the good work you did from the beginning.

Question #3: Is your work on time?

So you’ve got a happy client and a solution that works.  Next, you need to ensure that everything is delivered on-time.  Every project you take on becomes part of some larger business plan.  Once you commit to timelines, your client begins to plan their next steps.  Let’s say they’re planning a major product launch to coincide with the release of the new web site and online catalog you’re building for them.

They’ve got billboards going up, commercials ready to air and an army of trainees preparing to handle the expected influx of business…. and it all hinges on that end of year delivery your promised.  Now imagine its mid-December and you tell them you won’t be hitting your date.  It’s a client happiness catastrophe!  Months of planning is coming unraveled, your client cancels holiday bonuses for their staff because they need to conserve cash to pay the army of trainees with no corresponding revenue offset, they can’t cancel the billboards and commercials and they’re going to look like fools when they don’t deliver the product their hawking; oh… and your client is really starting to worry because they have a family vacation planned for the month after the project was set to be done and now that’s in jeopardy.  This may be an extreme example, but rest assured that your missed deadline will cause problems for you client that you may never even know about.  All you’ll know is that despite “everything you’ve done for them” your competitor wins the next job.

Question #4: Is your work on budget?

I bet you didn’t think it’d take this long to talk money.  Don’t get me wrong… budgets are important, but less so than client happiness, quality and timelines when it comes to your long-term success.  Simply put, you must never sacrifice #’s 1-3 to keep your budget in line.  That’s short-term thinking and it’ll eventually lead to a crippling pile of problems that will crush your business and reputation.  In a recent post titled Keeping Projects on Budget, I explained how an end-to-end project management effort is required to walk this line.  You’ll need to develop a process that works for you and execute it flawlessly.

One key topic to keep in mind along the way: Don’t do Out of Scope work for free!  I mean it… never ever ever ever. Not even small stuff.  Given the flexible nature of software, it’s easy to throw in this tweak or that additional feature.  It seems harmless at the time, but it always leads to problems.  First off, you’re mismanaging expectations.  You’ll be more likely to agree to something extra at the beginning of the project when you have lots of budget then you’ll be at the end when the budget’s winding down.  When you say yes, yes, yes then no, your client starts to feel cheated.  Why are you tightening the reigns now?  This leads to unspoken animosity where the developers think their earlier “generosity” is not appreciated and the client thinks this new strictness means the development team isn’t willing to see their “promises” through to the end. Everyone’s right and everyone’s wrong. It’s a bad situation and it damages relationships.  Secondly, now you’ll have to finish the scoped items with less than the necessary budget. You’re faced with sacrificing quality or sacrificing your profits.  That sucks.  See #2 for advice on what to do.

Summary

Software development can be a tricky business.  Most developers can handle the technology, but many struggle with managing the overall process.  Ask yourself these questions daily and align your efforts with satisfying them in priority order.   It takes time and effort, but if you persistently follow this list you’ll build great relationships, feel good about the work you do and eventually… you’ll make some money too.

I’m always looking for new tips and techniques for keeping my clients happy.  What’s worked for you?

Recommended read: While researching for this post I came across an article I liked so much I had to share.  A short, but important read: Mastering Account Management: 5 Tips for Keeping Clients Happy

Self-Help and What It Means to the Future of Customer Service

Self-help–it’s the sort of thing that everyone wants to be able to do in order to be the most efficient they can be without having to bug someone else or take more time out of their already busy day to track down assistance.  Self-help is becoming the norm in everyday customer service, across many different technology platforms.  But, the question that has yet to be answered is, will the general public accept the self help model of service?  The answer is, if implemented correctly, yes, because it will increase productivity and make customers feel empowered–able to assist themselves without having to ask anyone else for guidance and without having to wait around for answers or instructions.

I can’t tell you how many times I have heard people complain about having to speak to a Help Desk representative because they often sound like they’re just reading from a script, giving no real advice and providing no real insight. Experiences like these offer very little to instill confidence in a customer about the level of service they’re receive.  By giving customers the option of self-help, we’re putting them in the driver’s seat. They can resolve issues for themselves and feel the pride that’s inherent in fixing something on their own.

Support professionals need to be creative in identifying and creating opportunities for customers to embrace the self-help style of customer service, though, in order to encourage the mainstream adoption of the model. Successful self-help relies on detailed and well-informed knowledge base articles, how-to videos, and tutorials. Compiling lists of frequently asked questions is a great place to start–

If we approach development projects with consideration for where we can build self-help options into the software we’re building, we can make it easier for our customers to use and experience the benefits of our solutions. Finding opportunities to place a link or a button that provides immediate access to knowledge base articles that offer step-by-step procedures on how to fix issues are a great example: tutorials and how-to videos make it much easier for users to “see” the application in use, instead of having to read through steps which might be confusing to some. Identifying ways to incorporate both options, like the use of new “multiscreen” software built into many new Samsung phones and tablets, is fantastic because it gives the user the ability to view the help documentation while walking through the necessary steps in the app at the same time.

As developers and support representatives, we need to keep in mind that, the more we can successfully integrate self-help features into the software we build, the more value we’ll provide to the customers using our solutions and the easier it will be for our customers to stay on task without getting waylaid or frustrated. In a society where time is money and instant gratification is expected, this value can’t be overlooked.

Keeping Projects on Budget

BudgetYou know the drill.  Some ridiculously high percentage of software projects go over budget… And you’ve heard stories to back it up. Or worse, you have your own tales of being hung upside down by your ankles while the developers shake you down for every last cent.  Yet, here you are.  You’ve got a problem and it seems the only solution is custom software.  You’re doomed, right?  You might as well get ready to grin and bear it as you’re no doubt about to head down a path of endless pain and misery.  How did it ever come to this?

It doesn’t have to be this way!
I know… suspend disbelief for just a minute.  It’s going to take a lot of planning, coordination and hard work, but a well-executed software project can stay on budget AND deliver you a solution that satisfies your objectives in an effective and lasting way.  Here’s how we’ll help you do it:

Initial Sales Meetings and Preliminary Requirements Gathering
We start every engagement with an open mind. It’s important to fully understand all of the issues and goals before committing to any particular solution or technology.  Our initial meetings are designed to learn about your business and the issues you face.  What are the specific problems you are trying to solve and what are your goals?  Essentially, we start by helping you to define what success looks like for your project.  With that understanding our team will draft preliminary recommendations and deliver those with ballpark estimates.  At this point, we still won’t have all of the knowledge required to solve your problems, but we definitely have enough to determine if we are in the same ballpark… that is, determine whether or not we should continue before you spend any money.  If we are, the next steps will be to propose a formal Requirements Analysis process.

Requirements Analysis (RA) Phase
In this phase you’ll formally define what we are going to build.  We’ll schedule a number of meetings (preferably face-to-face) where our staff will spend time with your team to define the nitty-gritty details of the project. We’ll ask questions… I mean A LOT of questions.  We‘ll gain an understanding of your workflows, your staff, your business cycles, etc. so that we can clearly identify all of your needs.  With this deep understanding, we’ll produce several outputs that will help you effectively solve your issues within a predictable budget:

  • Business Requirements Document (BRD) – This is a comprehensive, plain-English, easy to understand definition of what you’re asking us to build. It can be read and understood by anyone on the project team, regardless of technical ability. The BRD is the cornerstone of the project and plays a fundamental role in sending you down a path where a predictable outcome and budget is possible.
  • Screen Mockups/Wireframes – These will provide a roughed-out visual representation of the system. They will help you to gain a better understanding of how the system will look, flow and feel.
  • Flowcharts – These are a visual representation of the workflow and business rules for the more complicated sections of the system.  They will help to further iron out the finer details of the project and identify “holes” early on.
  • Fixed fee for implementation – Once we know exactly “what” we’re building, we can very accurately predict how long it will take and how much it will cost.  That allows us to provide you with a fixed fee proposal for implementation.

In addition to these outputs, we will provide you with guidance on infrastructure needs, licensing for 3rd party components, and requirements for any 3rd party vendors, plus details on what your team will need to do to keep everything on track and make the project a success. Getting all of these issues on the table early and working together on a plan for dealing with them is the most important step towards a path that allows for a predictable budget.

The outputs from RA are yours to keep and are designed in such a way that any development shop with the appropriate technical abilities could implement them for you.  We certainly hope that you’ll choose to continue working with us, but at this point you are free and clear to move on if that’s what ‘s best for your organization.  And the best part… you’ve likely gotten here in less than 20% of your overall project budget.

Implementation
Once you agree to our fixed-fee proposal we’ll begin to implement your solution.  As far as the agreed upon scope is concerned, you won’t have anything to worry about in terms of budget.  We’ll produce the agreed upon output for thee agreed upon fee.  However, there may still be other costs that need to be managed.

Out of Scope (OOS)
We’ll continue to spend a lot of time with you during the implementation phase.  In particular, we’ll have regularly scheduled demos and walkthroughs that will allow you to see, feel and tweak the system throughout the process.  Minor adjustments to layout, appearance, terminology, etc. are expected and this is taken into account within your fixed fee.  However, you will inevitably identify additional opportunities for enhancements/changes that were not thought of during the RA phase.  Many of these items will be relegated to a future phase, but some may represent such a benefit to your solution that you choose to implement them now.  We’ll tap our vast project experience to help you classify the items and advise on how to best fit in those “must haves” with minimal impact to your timeline and budget.

Third Party Vendors
Very often you’ll have additional vendors that play roles in your solutions (i.e. your IT staff, your hosting company, the firm that supports the application you have asked us to integrate with, etc.).  This can create pressure on timelines and that can have an impact on your true costs (even if just by requiring additional time investment by your staff).  We’re very experienced in dealing with these situations and will advise you on how to get commitments from these parties and hold them accountable to meeting them.

Adoption
Once your software is complete, you need to get your users to use it.  This involves training, planning cut-overs, etc. and these things can definitely impact your true costs for the project. Having deployed hundreds of systems into organizations of all sizes under a wide array of circumstances, we’re able to advise you on a roll-out strategy that will help this all happen predictably (and on budget).

Quality Assurance (QA)
Your project has been in QA since the RA phase. Our QA team is tasked with reviewing and approving your Business Requirements before implementation can begin.  Then, the QA process continues through implementation with Code Reviews and internal screen reviews. Finally, the resulting software is put through a rigorous final QA pass that verifies all of your business rules and may include load tests, security scans, etc.  How does this impact the budget?  It’s all included in the fixed fee, but the value goes beyond that.  By ensuring a quality product goes out the door, we’re really enabling you to predict the long-term operating costs of the solution.  That will keep you “on-budget” for the long haul.

Ongoing Support
Depending on your specific situation, there’s a very good chance you’ll need or desire some level of support from our staff post-go-live.  With a full-time help desk and available 24x7x365 support solutions, we are equipped to provide you with a long-term support arrangement that meets your budget and business needs.

Deployment
Once everything is done, we still need to launch your software before you can start using it.  Delays of any kind will likely impact your total costs (i.e. think costs associated with preparing your staff for a launch that doesn’t happen, then doing it all over again a week later). Our development process takes a structured approach to this as well.  With thorough checklists in hand, our staff will be able to launch your software on schedule and will be less likely to run into last second “surprises”.

Summary
Our development process has been defined and tuned over the past 15 years through the experiences gained in thousands of engagements.  Our comprehensive approach, combined with the vast experience of our staff, allows us to identify and address hurdles early on and helps to eliminate the big “surprises” that plague so many software projects.  This allows predictability… And predictability saves budgets.

Finding The Best Technology Solution Shouldn’t Feel Like Herding Cats

The Value of Requirements Analysis

Sometimes it’s hard to remember that “problem” isn’t a dirty word. Your business solves problems every day; that’s why your customers come to you. Let’s start thinking of problems, not as bad things, but as opportunities.

Imagine that you’re considering a new line of business or you’ve found a process that causes a lot of friction, so you decide to change. You’re probably anxious and we can understand that; there are lots of ways to get off course when you charge a team with change:

  • Each team member goes after a different problem, so the solutions don’t converge. How do we get everyone back on the right page? What is the right page?
  • The project keeps growing and growing. As the team starts solving the problem, you find people adding new features to the solution. The team keeps looping back to revise the plan and each time you do, your budget grows. Nobody saw this coming. How do you stop it?
  • The team implements a solution. A few months go by; you analyze the data and find that the problem is still there. What happened?
  • The team proposes a solution. Senior decision makers hesitate because of budget, lack of in-house talent, or other priorities. Without buy-in, decision makers cancel the project. Does this mean you have to start over?
  • The team recommends a product to fix the problem. But once the product is in place, you find out there are some critical gaps in the solution. How can you bridge these gaps?

Here at Algonquin Studios, we have a process that prevents deviations like these. We call it “Requirements Analysis.” We begin by defining the core problem. We dig deep. We’ll humbly challenge your team by asking “Why?” and we won’t let you down by accepting the first answer as gospel. If there’s more than one problem, that’s OK; we’ll prioritize them. Working together, we’ll define exactly what your problems are and ask your whole team to commit to working on them.

Next, let’s propose solutions — lots of solutions. Don’t limit yourself to technology; you could change people, processes, and policies, too. After brainstorming, we’ll cull ideas together and judge our good ideas by doggedly adhering to the problem definition. A vision should surface — a vision of what your firm looks like operating the solution. You’ll feel good about committing to this vision and we’ll return to it again and again to overcome anticipated barriers and engage your team.

Now you’ve got a defined problem that’s simple to communicate and a vision for its solution. Algonquin Studios finds that these two key ingredients give you clarity, keep your team focused and gaining ground, and can nearly eliminate re-work costs from here on out.

After working through the initial Requirements Analysis (RA) phase detailed above you may determine that you need a new process, and some tools to operate it. By applying our detailed RA process at this stage, we can capture all of the business rules, inputs, outputs and processes to build or adapt those tools while honoring your decisions about scope, phases, and value trade-offs. We’ll start at a high level and break apart complicated processes until we reach simple, atomic ones. A solid detailed RA document becomes the foundation for planning, designing, building, deploying, and training for a good solution.

You might be surprised to find that a policy change is all that’s needed to solve the problem, so there’s nothing to build. And that’s a fine outcome!

We know this sounds potentially uncomfortable and like a lot of work. As a decision maker, you’re already living and breathing your problems every day and are hoping for a vendor to simply roll out the solution you’ve already got in mind. But what if there was a better way? A way to help make sure your solution is an unprecedented one that can grow your business like never before. That’s what we believe the RA process is, and it’s why we’re so committed to it here at Algonquin Studios.

Supporting New Software? No Problem.

One of the first stages of the software development life cycle is the roll-out of brand new software and with it comes that awkward honeymoon phase – it’s anyone’s guess as to what problems might arise during the first few weeks of use. With this comes a sense of uncertainty, but it doesn’t have to be all that scary! Since I’ve started working at Algonquin Studios, I’ve seen many old and grizzled systems scrapped in favor of bright and shiny new ones and I’ve learned a lot about piecing together a support process for when you aren’t totally familiar with the new software. Here are a few important things to keep in mind when venturing into uncharted territory:

There will be bugs. Probably more of them than you expected.

Even if you have the most fantastic software developers imaginable (like we do here at Algonquin), there are going to be unforeseen issues that pop up, so expect a sizable workload increase in the first couple months after releasing a brand new system. This leads to my next point…

Stay organized and consistent with bug tracking.

With an increase in bug reporting, it’s vital that the support team is clearly documenting all bugs reported and all team members tasked speaking with end users are kept up-to date on issues as they develop. Being diligent about your tracking will ensure that when it comes time to fixing those nasty bugs, everyone has as smooth a ride as possible.

Make sure you manage customer expectations.

As with all customer support issues, it’s important to manage expectations about bug fixes and requests for new features (Hey, I actually wrote a whole post about that here!). If there’s an issue or request that a user is anxious about seeing to resolution, let them know that you’ll be documenting the issue to be reviewed, but make no promise of when it will be completed. Not everything can be fixed or added at the same time and it’s best not to give false expectations.

Create and update a Knowledge Base from the get-go.

If you’re not keeping an updated Knowledge Base for your support team, you need to start… And you need to start yesterday. A centralized location for in-house use is crucial to being able to provide consistent answers on issues as they arise. Are you receiving the same questions on how to do a specific task in your software? Create a step-by-step “how-to” that you can send to customers quickly and easily, saving everyone a whole lot of time and confusion.

Have a simple way to escalate issues on a regular basis.

Whether it’s a weekly meeting or a regularly-sent report, there needs to be a way to let upper-level management know what’s going on. It’s ultimately not up to the front-line team to decide what gets fixed and when, but it is their responsibility to make sure the higher-ups are able to hear about the most dire issues. If there’s no process in place to communicate this, make sure you create one so the development life cycle can progress naturally.

Remember, as bleak as handling support may seem at the launch of new software, it will always get easier as time goes on. Implementing a brand new system is a learning process for both end users and support teams, so treat it as such! Look at it as an opportunity to grow your own skills and knowledge and reassure everyone involved that the process will all be worth it in the end. Every company will handle the launch of new software differently; what are some examples of procedures that your team utilizes when implementing a new system? Leave a comment and let us know!

Know Your Requirements!

Often times at Algonquin Studios, clients ask us to improve on their current software solution. The existing solution is either out of date or it simply isn’t giving the client what they need. For the user, changing systems can be a scary proposition. People grow comfortable with what they are accustomed to however, following a routine that you’ve done for years is the safe route. For this reason, it’s very important to sit back and think about what the system needs to accomplish. We want to make sure we maintain the output they are expecting from the software they use on a day to day basis, but keep an open mind on how to get there. In order to ensure this outcome, we spend a considerable amount of time conducting requirements analysis.

During the requirements analysis phase, one of the most important parts of a project, we determine what exactly the client needs are and how we will provide that solution. Time and again we run into the same obstacle of getting the client to see the difference between “what your users have today” and “what do you need the software to accomplish.” Clients often want everything they have today, in addition to the improvements we will provide with our software. Unfortunately, this could cause unnecessary features to be included in the software and add additional costs into the project going forward (training, support, system complexity … etc.). Costs that could be used elsewhere, either for the company or to build out additional features that are needed in the new system.

So, when coming into these requirements meetings it’s best to come prepared. To be better prepared it’s most important to know what is needed, as opposed to going screen by screen showing us everything they have today. There are many other ways to be prepared for these meetings, here are a couple:

Question your users

As a client, when was the last time you asked your user base about the program they use on a day to day basis? Requirements and business needs are always changing over time. Depending on the size of the user base, and the software being used, these questions could vary (and there are many). In the end, the client should find a way to determine:

  1. Which features are being used the most?
  2. Which features are rarely (if at all) used and aren’t needed?
  3. Is there anything you need the system to do that it doesn’t do today?
  4. Does the system provide repeatable work that the software doesn’t handle, costing people time every day?
  5. Are there current features that need to be revised to accommodate current needs?

There are many ways to gather this data.

Is this software internal, used by only a handful of people in your office? Have a meeting to review the software and gather the information firsthand from the users. Come prepared to ask about features that work and those that don’t. Are there any that have lost value over the years?

Do you have thousands of users using the software across the United States? Setup online user groups and invite people to provide valuable feedback on the software. Depending on the capabilities of your software, you can limit the groups to certain sections of the software and provide questionnaires about those sections. This should help you gather all the necessary information to bring to your developers, so we can make sure we build you an efficient, quality application that suits all your needs.

Clearly Define the Inputs/Outputs

Frequently, a screen can be so overloaded that one loses focus on what exactly is needed. Determine all the inputs of the screen and make sure they are all required and are what you need. Next, identify inputs that are unnecessary or misused. Keep in mind that just because they exist today doesn’t mean they’re needed going forward. Additional inputs only cause more complexity.

As important as it is to define the inputs, it’s equally important to define the outputs. Outputs that are currently delivered may no longer be needed or efficient or may simply be delivered differently in the new software; Once again, this is often difficult for a client to understand. Asking a lot of questions in the requirements meetings about those features can help ease the process because in the end, the more inputs/outputs you have the more complex your system will be. Our team of consultants are really good at letting clients know if the value they’ll receive from a feature is worth the effort and, generally, we can determine this during the requirements meeting.

In the end, if the client does their part in determining what’s exactly needed out of a system in order to eliminate all the old, antiquated screens and logic, the better the software will be. This will ultimately save the client in the long run.

Problems Don’t Float

Software developers have access to helpful debugging tools that let us step through the logic of our code and discover lines of code that might be misbehaving or causing problems. If our code is generating an error, the debugger will tell us which line of code is at fault. If we know our data, we know what results to expect and we can work through the code to diagnose problems if we don’t get the expected results.

Diagnosing problems during software development is relatively easy. The real challenge comes when your software is in operation and the end user has an issue–users report the effects of a problem and we, as developers, have to diagnose the root of the problem from the user’s description.

In the health care industry, they often remind doctors to cure the disease, not the symptoms. The same should apply to software developers; it’s very easy to get mislead by symptoms. My favorite “explanation” from an end user is “It worked before and now it’s not working.” This vague statement always sends developers down a path of investigating what changed between when the software worked and when it didn’t. Often, this investigation turns out to be a waste of time.

Let me give you some real life examples of being led down the wrong path thanks to the wrong focus:

My friend, a staff engineer for Delphi, had to diagnose a problem with overheating vehicles. The company’s customer service staff analyzed all the issues reported and came to the conclusion that most of the cars reporting the overheating problem were yellow in color. The engineering department was misled down the path of studying whether paint color had an effect on the temperature of a vehicle’s engine. Later, they discovered that the overheating was caused when the vehicle’s engines idled for too many hours during the day. Many of the cars that reported the problem were cabs in New York City. Since most of the cabs spend a fair amount of time idling while waiting for passengers and most NYC cabs are yellow, the customer service team’s analysis of the situation was accurate (many cars with overheating issues were the same color) but it didn’t get to the root of the problem (idling time).

I once wrote an application for processing reversal of payment transactions. After the application was in use for a while I received complaints that it didn’t work when processing reversals that resulted from bounced checks. I knew I’d tested for this scenario, so I was upset to learn that something was going wrong in its “real life” use. I found out later that a new staff member had been assigned to process the bounced check reversals. This new employee wasn’t properly trained and was mistakenly entering check numbers in the account number column, and vice versa. The problem wasn’t with bounced checks; it was user error. But I wasted a lot of time researching the bounced check stuff before we discovered the real issue.

This leads me to a line one of my Operational Analysis professors used to use: “Problems don’t float, only their effects come to the surface.” Don’t get misled by how a problem is described to you, instead do your own investigation; build your own understanding. Don’t just skim the surface; you have to dive deep if you want to find the root cause of a problem.

Here are few basic steps I’ve always found helpful when diving deep:

1. Collect examples of where the application malfunctioned and make sure you don’t limit the examples based on how the problem was defined to you. Do some analysis of your own to see which data sets produced the wrong results.

2. Compare the data to the source document to eliminate any data entry issues. Don’t assume anything. I remember one application where data fields were mislabeled during a configuration step, causing the wrong data to appear in the wrong columns.

3. Make sure that business requirements haven’t changed. Try not to offend the user reporting the problem, but make sure the output they expected matches the business requirements you followed to build the application. I remember an instance where a payroll auditor held back hundreds of paychecks, declaring that salary calculations were wrong. Many hours were wasted verifying the software used to process the calculations, only to discover that the payroll auditor hadn’t been informed that pay raises had gone into effect.

4. Work through the application using the data from the examples you collected. Make sure each step of the way that the output matches the business requirements. Again don’t assume anything, work through each and every step. Not only will this help you diagnose the problem reported, you might discover some other malfunction that was overlooked during development time.

And finally, remember that once you do uncover the root of the problem, you congratulate the end user for discovering that special “hidden feature” in your application!

Maintain Your Software Like It’s Your Home

Are you interested in software that runs on a magic PC somewhere in “the cloud,” never has to be bothered with, and always works smoothly? Sure you are, but if you think such a thing sounds too good to be true, you’re right. Keeping an application performing well throughout its life is much like maintaining your own house–it’s necessary and valuable.

In an previous post, I discussed the Software Life Cycle and made some basic comparisons between the preparation needed to build a house and the preparation needed to build software. The parallels don’t end there; a lot of similarities can also be seen in the maintenance of, and care for, both a house and a software system. Unfortunately, once your new home or application is built, you don’t get a free pass to kick back with your feet up and a nice cold beverage in hand. Using the house/software comparison, below I’ve listed a few areas where maintenance is important in both places:

Regular care

Lawnmower

  • Regular care at your house will include mowing the lawn, raking the leaves, staining the deck, painting the fence, landscaping, etc. All those things we love to keep busy with! We do them for a reason–to keep our homes looking nice and increase it’s value.
  • Likewise, you should regularly be evaluating how to maintain an aesthetically pleasing and user-friendly experience to keep engagement with your software at its peak. In most cases losing engagement will mean losing value in some way. “Regular maintenance” here can mean generating fresh content regularly, updating the layout of your site, adding accessibility features, or implementing new software standards, where appropriate, to keep your application looking and feeling new.

Upgrades

Roofer

  • Eventually, and hopefully not before you’re good and ready, your house is going to need a new roof, a refinished driveway, an updated heating/air conditioning system, etc. These are bigger projects and occur less frequently than the weekly, monthly, or yearly tasks mentioned above but these can easily be considered even more important to the general upkeep and maintained value of your home.
  • Your software should be getting upgrades too, as regularly as possible. Regular maintenance times for things like hardware upgrades, software patching, and security updates are a must. Beyond that, you should consider moving your software to the latest versions of code frameworks and database management tools. Staying on old versions of these things, much like failing to replace an old roof, increases susceptibility to leaks. And the longer you wait, the more likely your path to upgrading will be even more painful, more stressful, and more costly.

Additions

Blueprint

  • You want to move your laundry room from your first floor into the basement and then remove a wall to expand your dining room? Great…Maybe. Any good contractor will tell you how these changes will affect your house (what if that dining room wall is a load-bearing wall?) and that you’ll need to take these changes into consideration when you think about continued upkeep for your home.
  • Most of your software will have additions after your initial launch, too. This isn’t a bad thing…Much like the laundry room situation above, you won’t always think of everything in your first go-round. How new additions will fit and interact with the rest of your software, and how to most effectively make these additions, should be an important part of maintaining your software. You’ll want to analyze whether new features will cause other parts of your system to have issues, much like how removing a wall from a house may affect its structural integrity. Once your software is live, always consider how system processes interact and what adding a new feature will mean for the people already productively using the software.

Clutter

Clutter

  • When you use your basement as a one big storage closet, continuously piling things down there without a periodic clean out, it leads to a huge mess. What happens when you have an emergency and a plumber or HVAC expert needs to get down there and fix something?
  • Even if you haven’t thought about it yet, at some point you’re going to have to clean up your software the same way you would your basement. Today, it’s a brand new system using bleeding-edge technology and state-of-the-art hardware. But as your amazing software ages, all of the data you’re compiling is going to, eventually, become difficult for the system to manage. Do you really need to hang on to a record set of 10,000 emails logged from 1995 anymore? Probably not… So maybe it’s time to archive anything that’s clutter, helping your application breath a little easier. This clean up will help troubleshooting and day-to-day activities go more smoothly, too.

I could keep making house/software upkeep comparisons all day but I think my point has been made: we frequently overlook the maintenance portion of software development but, much like ignoring home maintenance, it’s a bad idea. Take this to heart; regularly scheduled maintenance is incredibly valuable in keeping your software functioning at its best and understanding why and how you need to care for your software will make dealing with it easier in the long run.

K.I.S.S.

Nope, I’m not talking about extravagant costumes, black and white face paint, and fire breathing.

I’m here to discuss the old adage “Keep it simple, stupid” and how it applies to software development.

As a Project Manager, I spend a lot of time meeting with clients to review requirements for their software and work with them to turn those requirements into a full system. As I work with my clients to navigate the treacherous waters of system design, we inevitably end up with a “feature” that we all agree is on the borderline of “Necessary” and “Nice to have.” This is especially hard to determine in a business system that users will be working with every day.

This is when things get interesting! Let’s take a look at what questions to ask yourself:

Why do you want this feature?

You can tell a lot about how important this feature really is by the initial reaction of a client when you ask this question. If it takes a few minutes of fumbling to eek out a satisfactory answer, you can most likely scrap the feature.

Is it worth it?

To answer this one, we’ll ask a few follow up questions, too:

  • How often will this feature be used?
  • Is there a manual workaround that can be used instead of this feature?
  • Who will use this feature (and how many of these users are there)?
  • How much work will be created for a user is this feature is left off?

Now do a little quick math and, magically, we can determine if it’s financially worth adding this feature. Here is an example:

Add this monthly report that aggregates data for X, Y and Z. 
  • Feature will be used monthly
  • User can perform this process manually
  • 1 administrative user will use the report
  • If this feature isn’t implemented, the administrative user will need to run 3 reports and aggregate the data themselves. This process will take approx. 20 minutes.

Answer: If building the report adds 8 hours to the system build, it will pay for itself in 2 years.

Does this feature add complexity to other areas of the system?

I’ll let you in on a little secret, the answer to this question is always YES.

No mater how much you want this fancy new feature, it will make your system more complex. We often try to convince ourselves that a feature is so simple that it won’t add complexity, but there are a couple of points that always hold true:

  • This feature will need to be tested after every update.
  • The users of this feature will need training.
  • This feature will need to be documented in the help system (and maintained).
  • This feature will need to be discussed when future changes to the system are designed/implemented.

So, let’s return to our seemingly simple example report and apply these issues to the “complexity” question:

  • Will this report need to be tested? Yes
  • Will the users need training? Yes
  • Will we need to add help documentation? Yes
  • Will this report need to be updated if we make changes to report X, Y or Z? Yes

There’s no doubt about it–every time you want to add a feature, you’re choosing to make the system more complex.

Before you commit to a feature, ask yourself if it’s a system requirement and make sure you really understand, and accept, the increase in time, complexity, and cost that including the feature will entail. If the answer is “yes,” then let’s build it. But if there’s any doubt, remember, it’s never a bad idea to K.I.S.S.

Microsoft SQL Server 2012 – AlwaysOn

Microsoft SQL Server 2012 – Always On

As technology advances, so does the need (and want) for instantaneous information. The goal is always “How can we get information as quickly as possible?” The same is the standard for disaster recovery. How quickly can we recover in the event of failure? The answer in many cases is seconds. One of the newest options for High Availability is Microsoft SQL Server’s AlwaysOn technology. The name is self-explanatory–AlwaysOn is designed to have data and information always available, even in the event of disaster. Disaster Recovery time is minimized with SQL’s AlwaysOn ability to sync multiple databases across multiple database servers.

I had the recent experience of using SQL’s AlwaysOn technology to set up a redundant application environment. The purpose of this blog post is to summarize my experience with the technology. By no means is this a start-to-finish coverage of the technology.

Overall, the perception of AlwaysOn amongst users has been very positive (simply Google “SQL Always On” and you’ll see other posts stating its benefits). I, too, was impressed with its simple setup and configuration and how well it handles failover scenarios (verified during our pre-launch testing). With all technology, there were some downsides, but I felt that the positives of AlwaysOn far out-weigh its drawbacks.

Availability Groups

  • Replication in AlwaysOn is no longer thought of as individual databases to individual servers. Complex systems can be replicated as a group, not as individual databases, minimizing setup and configuration time for replication. The one downside is that the replicas are limited to four sets, so one group can only be replicated to 4 different locations.
  • Synchronous and Asynchronous Setup
    • Synchronous Replication – Transactions are not completed until committed to all databases in the Synchronous Availability Group
      • The first thought I had when hearing this process was that it may be performance impacting since SQL will need to commit the transaction to multiple databases on multiple servers.
      • We tested this process to ensure synchronous replication to multiple databases would not cause performances degradation.
      • We used SQL’s query performance statistics to ensure that the performance of data read/writes were as efficient with the new environment as they were in the old environment.
      • As a side note, there were other factors that affected query performance times (for the better – new environment, new OS), so our test wasn’t a true comparison of SQL performance with and without AlwaysOn replication. For the purpose of our test, we needed to ensure that the AlwaysOn replication was not a detriment to application performance.
    • Asynchronous – Transactions are queued and committed to this Availability Group at a later time. Transaction completion is not dependent on committing to this database group. This is similar to Database Log Shipping in older versions of SQL Server.
      • In previous versions of SQL Server, Log Shipping would require the database to be inaccessible during restoration of the transaction logs. With AlwaysOn, the database is always online and accessible.
      • This allowed us to use the Asynchronous process for other purposes, in this case Read-Only reporting. We took long-running reporting queries and calculations and removed that processing need from the transactional database and server altogether, providing an indirect performance benefit from AlwaysOn.

Automatic Synching

  • One of the most frustrating aspects of SQL Log Shipping is when the process gets out of sync and the transactions are not being properly applied to the replicated database. This would generally result in manually copying and restoring a database to the replication server and restarting the transfer process
  • This headache is alleviated with the Asynchronous Replication of AlwaysOn. AlwaysOn polices itself for the data replication, automatically re-synching the database if a network connectivity loss or other event disrupts the replication process

Licensing

  • Unfortunately, AlwaysOn is only available with the Enterprise Edition of the SQL 2012 License, so you’ll need justification to spend the extra money for the Enterprise license. This may not be the best DR solution for smaller applications.
  • However, licensing is setup to use Active vs. Passive server. This means that you don’t need an additional license for your replication servers if it is only being used in a failover scenario, which allows you to limit the number of licenses you will need.

Again, this was just an overview of my experience with Microsoft SQL Server’s Always On functionality. In the event that you are in the process of setting up a new environment using Microsoft SQL Server, I highly suggest considering AlwaysOn to handle the High Availability/Disaster Recovery requirements. See Microsoft’s overview of AlwaysOn here: http://msdn.microsoft.com/en-us/library/ff877884.aspx