By Eric Sollenberger:
Are you on the verge of a mutiny?

For my Mom's birthday I decided it would be nice if I bought her a computer. (Moms are funny; she had purchased three PCs for my brother and me before we were out of the house, but she never had the desire to learn to use one herself.)

We went out to the electronics store one day to pick out the one that she wanted. Her two biggest requirements were that she needed to access washingtonpost.com, and she wanted to learn to play Scrabble online. We ended up picking out a pretty generic machine with a decent amount of memory and some antivirus software for all of the "free iPod" ads I was sure she would click on.

This was six years ago, and she was happy as she could be. I was too, albeit completely unprepared for how good she would get at Scrabble. Then I had to go and screw it all up.

I stopped by the house a couple of months ago and brought with me a copy of Windows 7. I figured she hadn't upgraded in six years, and she'd be cool with me installing it. Not the case. After I left I got a phone call from a very angry Mom. She sounded like I did after I installed Vista.

• "I can't find my pictures. I wanted to put my pictures from New Zealand on Facebook."
• "Everything's different."
• "Can you come over and change it back?"

Looking back, it was a sneaky move on my part. I should have asked before I acted, but I thought I was doing her a favor. As a more technically experienced person, I was projecting my own values on to her. I knew Windows 7 was better than her seven year-old XP, but I didn't stop to think if she would think so too.

A lot of times people ask me about the best way to transition their employees to a new piece of software. I always ask them, "Why do you want to change? Does your team also see a problem?" Of course you shouldn't make your decision on whether to change software based solely on what your employees think about the current system. However, it's important to anticipate the feedback from the people who will be learning the new product as well as those who will be measuring its success. Do they see the reason for the change? What is your plan to train them on the new technology? How much user error can you absorb after the change is made? Getting them invested in the reasons for the switch as well as the plan for transition is the key to avoiding a mutiny.

By Eric Sollenberger:
The BCS formula has determined that Auburn and Oregon will square off in the BCS National Championship Game. What does this have to do with your company's legacy system? More than you might think.

One: It sounded like a good idea at the time.

As strange as it may sound, the BCS system was created to solve a problem. The old way of crowning a national champion failed for the first time in 1992. Mark Brunell's Washington Huskies had won their bowl game and finished the season undefeated. In most seasons this would have been enough to secure the national championship, but this year was different. The University of Miami (featuring Dwayne "The Rock" Johnson) had likewise finished the regular season undefeated and pummeled Nebraska in the Orange Bowl. Although The Rock would go on to claim to be "The People's Champion," the national title was declared a tie. Everyone threw a big fit because there were two national champions, and America doesn't do ties. Something had to be done—and the solution was to be the Bowl Championship Series. The BCS ranking formula would include the opinions of people who talk about sports on TV, coaches who are allowed to vote for their own teams, and six computers that would calculate secret algorithms. What could possibly go wrong?

Like college football, businesses grow and change over time. Systems evolve naturally around activities and tasks that are of higher value to the bottom line. Back in the day, it was easy to tweak the system. Putting a file in a different inbox, or firing the guy with messy handwriting was how things got done. Then businesses grew and grew and grew, until they could produce no more without bringing in an IT expert to automate everything. To quote the slick talking software-salesman: "Using this great new system of expensive software that only a couple of people understand, your business will be free to expand, and the system probably won't have to ever be changed! Even if some minor adjustments have to be made, I'm sure it would be no problem to find someone who can do it right, and every employee will have no problem at all adjusting to the new features. What could possibly go wrong?"

Two: It usually works. But even when it does, it freaks you out right up to the end.

For the most part, the BCS rankings put together the two best teams in the country. It provides us with an entertaining game and a great excuse for some New Year's Day laziness. With the exceptions of 2003 (LSU/USC), and 2004 (USC/Auburn) there haven't been co-national champions since the BCS formula was implemented. Surely a system that works 85% of the time can't be bad.

Although it usually works, there's the potential for disaster every time. Every November, there is a possibility that 3, 4, or sometimes 5 teams would have a legitimate claim to play in the looming national title game. Fan bases get all worked up, and Lou Holtz gets so flustered he can't speak.

Legacy systems are the same way. If you've survived a few screw-ups before, you'll survive them again. As long as the orders go through the same way each time eventually you'll get your funding/paycheck, and there's probably not a reason to change anything. We know a lot of people who've been dealing with the uncertainty of a faulty system for years. At crunch time, they bite their nails and prepare for the worst. Then at the last second, everything usually comes together—the system that's held up with duct tape comes through yet again. But hey, they're no worse for the wear.

Three: The guys who designed it spend more time counting their money than fixing the problems.

It's almost cliché to skewer the NCAA and money-hungry college Presidents. Yes, they make loot hand-over-foot while the masses demand a playoff. But give them credit—they designed a system that usually delivers what consumers want and supplies enormous profits for their schools. After all, boosting revenue for the universities and conferences is one of the most important parts of their jobs. Without this revenue, schools would be forced to slash research budgets, cut programs, and generally lose their ability to equip young men and women with the tools needed to succeed in the world. Sure, they'll listen to important boosters and the bully pulpit that is the NCAA, but they're not going to rush to change anything unless it's worth their while.

As opposed to the NCAA, the software team you selected usually builds exactly what you tell them to. That might be the problem. Chances are your vendor is not going to know your business as well as you do. The development team should understand the "who, what, when, and where," and most importantly the "why." This involves some up-front commitment in time, and a little bit of back and forth between the two of you to ensure that they get it. Ideally, the vendor that you choose should be able to listen to your requirements, but also be able to make suggestions about something that might work better in the long run.

Four: It's the only game in town.

Every year people discuss boycotting the national championship game. There's always the guy at the bar who says, "I love college football, but I'm not going to watch the BCS games until they put in a playoff."

That guy is a liar. He is going to cave in and watch the sport he loves, played at the highest level for the last time until September. People have the option to watch the FCS Playoffs, but I doubt 50 million TVs will tune in to watch football games that are apparently being played at Roland Garros.

The flaws in a legacy system are similarly well known. There's generally a sense of resignation that you have to make due with what you have. You can't just stop using it; after all, business would grind to a halt. Your other option would be to update it, and most people don't even know where to begin with a project like that. You use it and learn to tolerate it, because you don't have any other recourse. Sometimes the devil you know is preferable to watching Eastern Washington vs. Delaware.

Five: It's only going to be fixed when the problem becomes more costly than the solution.

Great news NCAA football fans! ESPN has a deal with the BCS that will guarantee the rights to air all of the BCS games through 2014. For all that's broken with the BCS, they're still being paid $125 million per year just for the rights to broadcast the games. Like it or not, the BCS is nothing if not profitable. That's not going to change until there's a run of consecutive co-champions, or a viable alternative with a smooth transition is offered. Mark Cuban, the ball is in your court.

People ask, "When should I do something about our legacy system?"

It's simple math really.

How many orders/grants/contracts has the system cost you? How much time do you spend worrying about, fixing, or paying others to handle issues with the current system? What is your hourly rate? Add those numbers together and you get an idea of how much the legacy system is costing you. From there it's pretty simple to figure out what your budget should be and when you will recognize a return on that investment. Maybe it makes sense to keep using the current one in spite of all its flaws. Maybe there's a place in this world for somewhat serviceable broken-down systems that used to be fast. After all, Mark Brunell still has a job.

If you have run the numbers and realize it is time to invest in a way out of your legacy system, Headspring would like to speak with you and we hope you will contact us. Helping enterprises out of legacy systems is what we do best. If you select another vendor, please do due diligence and choose well. You will be frustrated if the "solution" is a brand new legacy system. Example: BCS

By Dustin Wells, Jeffrey Palermo:
We see a lot of clients that wish to try to commercialize the applications that they've built and to try to get some additional revenue from them or to create a spin-off business offering the product to other industry competitors. While they're offering their competitive advantage to others that might compete with them, they are always ahead of the curve because they are the ones producing the software and they are the ones innovating it. They are the ones that are continuing to make it better.

Software commercialization is one area some clients see as a strategic advantage in the long-term, either as a spin-off company or in the name of building a product to help them garner possibilities for an "exit situation" in which a company is sold because it has a proprietary system that allows it to run more efficiently than others.

In building a custom application one might ask:

• Do I want to commercialize this later and possibly monetize it?
• Is this a strategic advantage that we can use when we're exiting the company or trying to sell the company?

How much to build...

Let's dive into what happens when you decide to make the build decision versus the buy decision. (The application is core to your business and there is not a package off the shelf that is going to meet your needs, hence you decide to build.) One approach is to build the whole thing, but that is rarely the correct choice because if you look at the overall scope of what you want to build and it has scope encompassing people, customers, and how your business operates, there are probably going to be:

• pieces for scheduling
• pieces that list contacts
• some sort of product and services list
• some tasking and workflow around how people do what they do

There are a lot of smaller packages to manage these items out in the wild. And you may utilize them as, while the entire system, as a whole, may be unique, you have made a decision to build a unique application, not an application of 100% unique scope. There is always a portion of a sizable system, and sometimes a significant portion, that may be comprised of a number of smaller packages integrated together so that perhaps only 50 to 70 percent of the overall scope need be custom built. Some of the other pieces may be small, targeted, off-the-shelf packages that are integrated into the overall solution.

There are really two different ways to approach a partially-built package:

1. One is buying a package and customizing it. That's not necessarily the best option a lot of times. These are hard to make successful in a lot of situations, because the package that one is to customize will often not have a great deal of ways to interface with it seamlessly.
2. The other is specifically building a custom application and then finding opportunities to buy components to plug into that custom framework. A good example of that might be reporting. We don't need to reinvent graphing, charting, and reporting, but we do have data to display and we need to be able to make it look a certain way. This is a great example of a situation in which one should pull something "off the shelf" to give very robust reporting functionality for a fraction of the cost that it would take to actually build the reporting. This approach helps get the cost of the build down and still gives a lot of functionality.

By Dustin Wells, Jeffrey Palermo:
Typically, if you buy something off the shelf, it will be a fraction of the cost of building it from scratch or something that's comparable. It will probably have much more functionality as well (most of which you will not need). Most packages have a lot of bells and whistles, and do a lot of things, but, typically, they also don't do a lot of things that you need.

SalesForce, is an example of a package we use in our organization for contact management and relationship management. It has a lot of features that we don't use. We probably don't use sixty percent of the features that are in SalesForce. While that's a lot, SalesForce is also more affordable for us to use than a custom app (something which we're clearly capable of building on our own) that we would have to pour man hours into developing. SalesForce meets our needs and it's at a fraction of the cost of building something comparable.

Looking at the investment that it takes to get a product to market when you build it, the long term stability of such a product, and thus the investment needed in the name of stability, it is fair to say that typically when you build something from scratch it has to be a core of and critical to your operations, and to your strategic competitive advantage. It can't be something like SalesForce that is not really specifically competitive to your organization.

Canned Solutions (they're not fresh)

If there is a product "off the shelf" that is applicable to your core business, then it's probably a business need to work on differentiating yourself just a little bit more.

The barrier to entry is so much higher when you build something that helps you gain a strategic advantage over a competitor when compared to buying something off the shelf that does everything, and yet if you can go buy a package that helps you run a car-wash business (for example) there is not much spirited incentive for you to go run that type of business, as if you can buy an off-the-shelf logistics package, then anyone can go buy it and start a business of that ilk and be pretty competitive with you. Alternatively, if you've got a strategic advantage and can build the software that would help raise the barrier of entry for competitors and make you more money while helping you keep a stronger hold on the market you're positioned in... you are golden.

If you are planning to build the app that will give you a strategic advantage over your competitors, Headspring is interested in speaking with you. Please contact us.

By Dustin Wells, Jeffrey Palermo:
With regards to packages that someone can use out of the box versus building something from scratch, a lot of clients call us for custom application development because they couldn't find something that met their needs out of the box.

SalesForcesque

A CRM system like SalesForce.com represents a non-core competency of most businesses and most businesses don't want to build their own CRM, and yet a CRM is critical to their operations. SalesForce probably meets about 80% of the needs of most, but that leaves about 20% of needs wherein SalesForce could stand to be tweaked. And so, in a scenario where you need SalesForce-only-different, you have to make the business decision on if it makes sense to build something either as an add-on or from scratch or to just make do with the 80% and take a sacrifice so that you're not investing a lot of capital dollars in custom development when you have a package that meets most of your needs.

A lot of clients appreciate the trade-off, reasoning: "I found a package. Why do I need to find exactly what I want?"

If the twenty percent that is missing from the package is critical to your business or your competitive advantage then you probably do need to build something versus buying it off of the shelf.

"I found a package.
Why didn't I find exactly what I want?"

By Dustin Wells, Jeffrey Palermo:
When do you make the assessment of build versus buy with a client? It all comes down to the core competency of the business at hand.

An Example: There are programmers within a software company that sells a software product, so the company in question may have the skills necessary to do all kinds of types of programming. In fact, the product is an off-the-shelf software package, and the company has made quite a bit of money with it. A consensus builds of "OK, we need to revamp our website, and put some interactive features within our website." Then a "solution" follows:

• "Obviously, we have programmers internally."
• "We possess the skills."
• "I'm just gonna go task some of my programmers with building our own website."

Now...

The company makes money in selling a software product. The company does not make money selling its website. The website is part of marketing and lead generation, and things like that. And so, the build versus buy decision would entail:

• estimating how much you would spend internally on the website versus how much you would have to invest if you were to both get a bid from a vendor and have that particular vendor charge you some money in exchange for developing the website
• a return on investment analysis with the internal cost juxtaposed against the outsourced cost

Conflicted? Look at the bottom line.

Most of the time, hiring a company that specializes in website development is probably going to be cheaper than multitasking some product software developers into doing a website.

• The salary alone for the time spent on the task is probably going to be more expensive for competent individuals generally versed in software (but not specifically practiced at web development) than for a vendor who does this day in and day out and can crank out the website in a few weeks and charge you a few thousand dollars.
• Beyond immediate costs lie opportunity costs. Your developers are not focusing on the product that you're selling if they are building your web site!
• There are a lot of factors that go into the build versus buy decision, but it all comes down to:
  • What do you make money at?
  • keeping your resources and your staff focused on that
  • outsourcing things that otherwise distract your most important people

By Jeffrey Palermo, Eric Anderson:
Headspring delivers training to help our clients produce better software and to give back to the software development community at large.

Headspring develops and delivers business software. Over the years, we have amassed a certain amount of competency in business software development. We have found that not only do our clients need business systems, but they need training in business software development as well. In 2008, Headspring began training with our Agile Boot Camp™ for .NET. We've since expanded our training offerings to include complementary monthly workshops held at Austin's Microsoft Office, and our popular ASP.NET MVC Boot Camp™.

In the process of developing software for our clients, we've identified some areas where developers have a lot of questions. Our trainings have blossomed as we have shared our established best practices for developing software systems--specifically line of business software systems.

Our clients have approached us with questions ranging from hardcore technical issues to general purpose project management. As we have identified common challenges and overcome them, we have used the lessons learned to drive our comprehensive training offerings.

By Jeffrey Palermo, Glenn Burnside:
This is never just a technical effort. This is never just a business effort. This is never just a coaching effort. This is a process of bringing all of these elements to bear in order to make targeted assessments and recommendations to achieve specific goals.

The ideal vendor should have a demonstrated history of being able to guide their customers through the improvement process and be someone who not only finds issues but who can also make recommendations and then can also take those recommendations and actually help you act on them to really achieve the goal you set out for in the first place.

You also have to look at the alignment that the vendor has to your way of doing business. Obviously, you would select a different vendor if you have a market cap of several billion dollars versus having a small company where you must make payroll for twenty folks.

Also the type of software matters because it takes a different type of person to assess a system that perhaps runs a high traffic ecommerce website with a backend order management system than it does an internal system for a local livestock show and rodeo. The two have very different characteristics, and few companies have as broad a range of consultants as is needed to be able to serve every end of the spectrum and all the different points in between. At Headspring, we certainly are not a good fit for everyone, and we certainly don't have the capability to evaluate every system that exists out in the wild.

The Screening Criteria

But when looking for a vendor, keep that in mind. Be able to describe the type of environment you are in, and, for some, ask for a description of their previous engagements and try to find out what similarities you have with their previous clients. Really drill down to see if there is a fit, because not every vendor will be a fit.

• For us, not every client is a fit. We recognize that, and we value our evaluation of clients just as much as we encourage the client's evaluation of us.
• After determining that there is a great fit, the likelihood of success is really great.

We would love to share with you some of the success stories we have had in code review. Perhaps we are a good match for each other. Contact Headspring today to see if we fit your need.

By Jeffrey Palermo, Glenn Burnside:
How do you communicate what you've found in a code review when you do not have a long established relationship with the owners of the system? The most important thing you have to do is establish a framework up front of what the expectations of the code review are. As mentioned in our prior posting ("What is a code review and why is it important?") the questions you're going be trying to answer and the areas of the system you're really interested in evaluating are going to vary depending on both who is asking the questions and why they are interested.

• You're going to need to know the kind of information you are looking for and how it manifests at a team level to determine if developers are working with best practices.
• You will need to review code in the small, immediate scope up to a more strategic evaluation of a whole asset, possibly for acquisition, to answer the question: Does this software asset have a viable lifetime to it in the future?
• Where your evaluations are going to strongly focus on architecture, you will need to know what standards you're aiming for so that you can deliver objective information that's valuable at the right level of clarity.

People

Personal relationships are very important, especially in this type of offering, and when inspecting someone's software system, where we're going to find things that are quite good and we are going to find things which need improvement. If a code review finds no room for improvement, then the assessors were simply not looking hard enough. A cornerstone of success is building a relationship and that starts with listening:

• In order to perform any assessment about a software system, we have to understand what it does. We have to understand the business model it serves and what part of the business it enables. This requires a lot of listening.
• It also requires recognition that the software system has undergone tremendous change within a successful business and that it has reacted to a changing business environment. Without an understanding of what business and architectural decisions have been made, we cannot form an accurate or complete understanding of the system in question.
• Only after listening and proving our understanding of the system in question can we expect to have relational credit with, and trust from, the client we're serving. Our ability to make and communicate an assessment about any software system depends on listening.

I'd like to tell you something. You'd better have a seat.

Now the next part is communicating what we found in the code review. That needs to stand on the shoulders of a solid relationship with the owners of the system.

To start with it's important to communicate the high level findings as it relates to the goals of the client. For instance if it is performance or if it is scaling or if it is load characteristics that are undesirable, we need to relate the findings back to how it is going to allow the business to either serve more customers, serve them faster, process more data, or be less costly to operate. If the review is a risk and health assessment, we need to communicate the types of risks that we often see and give a very good broad overview of what those are.

The code review is going to produce two kinds of artifacts:

1. an informational body of evidence
2. some prescriptive guidance

Some of the stakeholders and other parties involved are going to want to really be able to see for themselves all the documentation and possibly draw some of their own conclusions from it, but, beyond raw reports, we want to make sure we are able to communicate some prescriptive guidance in the service of a specific set of questions which have guided our analysis and which the clients have posed about their software assets. And yet, we want to make sure that we're providing not only those end recommendations but also the body of evidence, objectively acquired, that is causing us to bring those conclusions.

No code review is complete without offering recommendations. No one just asks for a code review. The questions behind the questions are:

1. Given what we have, where are we going?
2. What can you do to help us get there?
   

We're paid for recommendations, not criticism.

The recommendations really comprise the value that is behind a code review. Obviously, if there is a target problem in the data center like the system slowing down or not being able to serve all the users, then it's very concrete and obvious as to how we may improve the performance of the system. But, if the question is "How do we insure that our investment in this system is going to last 10 or 20 years and not expire in 4 or 5 years?," then it's really important that the recommendations are scoped accordingly. We've offered recommendations from performance and security improvements all the way to how to migrate from one version of a system to another and how to ensure that the structure of the system can last not only 20 years but can support indefinite upgrades without the risk of becoming stale, difficult to work with, and requiring a complete replacement.

Way too often we find systems designed with no thought to the future, and at some point they have to be completely rewritten, with the previous investment nearly invalidated because of some shortsighted business and architectural decisions. It may not be pleasant for a client to hear they are trending towards such a fate, but a client ultimately wants to know how to correct course.