For my Mom's birthday I decided it would be nice if I bought her a computer. 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.

While intensive training is hugely helpful for advancing knowledge, it can also be overwhelming. As a developer myself, I often found that often when I'd go to conferences or shorter trainings, it was hard to take in everything at once. The sheer volume that was covered was just too much for me to take it all back to have my team ramp up on it and apply it. In fact, it would've been a great disservice to my teams to share everything I was exposed to and expect application all at once. It hasn't been uncommon for me to go back to a conference a year later and sit through a session again and think, "Oh yeah, I meant to do those things with my team, and I just ran out of time."

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.

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.

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.

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.

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, and outsourcing things that otherwise distract your most important people.

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.

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.

How do you communicate what you 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 a code review are. As mentioned in our prior posting 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.