Providing software products that meet your customer’s needs usually results in happy customers and good earnings.  If the product is an an easy-to-use app that helps your customer make money, then you’ll do well especially if the app is backed up by top-notch customer support.

But how do you get to this software nirvana where your customer is happy because your app does what he needs?  Answering that question in the right way is what separates successful software development companies from the less fortunate. Continue reading…

I’ve worked with offshore teams for over 6 years both as a contractor (with an offshore team) and as a VP in my current post heading up Product Development for Dominion Dealer Solutions.

When you are a contractor, managing offshore talent requires no real balance because you are the manager supervising your offshore programmers.  Your job in this task is to communicate well, manage expectations for both the client and the team, and then know the strengths and weaknesses of your team… promoting one and carefully managing the other. Continue reading…

When I think about the beginning of our experience with QA, it seems similar to the early stages of the automotive industry.  I wasn’t around before Henry Ford introduced the assembly line, but I can imagine what it was like when a person built a single vehicle at a time.  I can just imagine a car builder getting half-way through assembling a car and realizing he has no idea if he put the bolts on properly, or getting to the paint stage and realizing that the doors are not flush with the body.  It couldn’t have been fun.

In the beginning of our QA timeline, the development staff was responsible for performing their own testing much like that early car builder.  Sure, there might be others around who could lend a hand, but they might not have the time or proper skills to test correctly.  Each programmer was essentially responsible for assembling the entire task together, mimicking their counterpart at the factory. Continue reading…

Documentation.  Although every developer needs it, most dislike the thought of creating documentation while complaining vocally when it’s lacking.  Creating proper documentation is also expensive, requiring hours of developer or specialized staff time, and even more time is needed to keep documentation current as projects evolve.

But failure to keep code documentation current can be even more expensive.  At best, out-of-date documents can be confusing; at worst the misinformation can cause expensive bugs or lengthy refactoring efforts.

I’ve seen documentation done right only once, at a defense company, and that was largely because the government demanded a rigid process.  But under this model, doing it right meant a full-time staff of technical writers – an expense most start-ups or small businesses cannot afford. Continue reading…

Trying to change a large software organization is like trying to make the Titanic turn on a dime. Trying to embed usability practices into a large software organization that has never practiced it before is like… well you know what happened to the Titanic. However, it doesn’t need to be that way.

The company I work for (Dominion Dealer Solutions) is a fairly large software organization selling multiple, market established products serving around 50,000 users. It’s my job to work across these products, evaluating the user experience of each one and providing recommendations for improvement. On top of that, these are all established products which makes it hard to implement sweeping changes. Continue reading…

John D. Rockefeller said, “The ability to deal with people is as purchasable a commodity as sugar or coffee. And I will pay more for that ability than for any other under the sun.” Project management is, in a word, dealing with people.

Conflict on your project should never be feared but must always be managed. It is as natural and as necessary as emissions from an engine because any system that produces work has heat (friction) as a by-product. The more work is produced; the more heat is generated. However, engines that get too hot can freeze up and then nothing is produced until the machine is repaired or replaced. Likewise, unresolved conflict can cause unnecessary stress, lost time, apathy, bitterness (sometimes resulting in sabotage), and unnecessary bureaucracy. Continue reading…

Getting a bunch of programmers from different companies and corporate cultures to work together is worse than trying to herd cats; it takes a psychologist’s light touch, a politician’s creative tongue, and less knowledge about programming than you might think.  Most of the work is human rather than technical.

Over a year ago, I was asked to bring 4 development teams together so that we could unify our products and develop according to common standards and best practices.  On the surface the problem seemed mostly technical… each team followed different coding and security standards, revisioning control systems, project management systems, authentication schemes… the list goes on.  In truth, however, my main challenges were all human. Continue reading…

Creating a new app or web site often takes a lot of clear thinking and hard work… No doubt about it.  You have to organize your thoughts, write them down, identify work or thought flows, eliminate waste, and get coding.

This blog was no different. It started as an idea months back when a group of us met to discuss coding best practices, smart agile management tactics, how to create usable apps, etc.  We wanted a way to identify best practices, create a forum where we can keep our learning alive, and have a way to share what we know best so that others might benefit, comment, and offer their own thoughts too. Continue reading…