I have been fortunate enough over the years to work for some exciting software companies. Many of my favourite are, sadly, no longer with us. When looking back over why some of these companies failed, there are a surprising number of similarities (hopefully unrelated to my employment with them).
The first software company that I worked for fulltime was a brilliant little company in Portland, Oregon called Now Software. We were the biggest Mac-only software company in the world in the early 1990s and counted among our customers the US Government and NASA.
Our products included Now Up-to-Date and Now Contact, client/server-based scheduling and contact sharing applications that could still rival Outlook today. We also had a very popular Macintosh system utilities product called Now Utilities that were very useful little productivity and system personalisation tools. We acquired our competitors, Touchbase Pro, and were the first to have a handheld PDA calendar and contact syncing software solution for both Apple Newton and Palm.
The culture of Now Software was one of fun, supportive people. We had nerf gun wars, Quake tournaments using the intercom to communicate across the building, and the occasional office dog keeping us all on our toes. Many of our customers who would call our support department sent us gifts as thanks for helping them. It was a very nice atmosphere and my favourite place to work.
At the MacWorld Expo every year, Now Software had a large presence, and we always had crowds of customers coming by to engage with our technical staff.
When a new CEO came on board and decided to branch out into the Microsoft Windows market with new client versions of Now Up-to-Date and Now Contact, he did what many companies do: made decisions on investment and implementation without having his technical team perform due diligence on the technologies. He raised a round of venture capital, hired a VP of Engineering from Intel, and told him to ‘Make It Happen’. Because the development team were all Macintosh developers, the VP of Engineering outsourced the development work for the Windows client and the lack of communication between his outsourced team and the existing development team caused a mentality of ‘Us and Them’ to permeate the company.
The mistake so often made, though, that was certainly the point of failure in this situation, was the lack of Quality Assurance Checkpoints in the development process. QA Checkpoints are stage gates in the product development process where a build of the application is given to QA and tests are run to ensure that the functionality is compatible with the rest of the solution. In this case, the servers that shared calendar and contact data across multiple users’ machines (clients) required the data to be shared in a specific structure (as any data warehouse would) and the communications needed to match what was on the Mac-based server and the Mac-based clients for seamless back and forth transfer of data.
There are may ways to avoid falling into this trap.
First, using a development methodology that allows for testing at regular intervals, such as Agile SCRUM, means that the QA team can test from the very beginning and fatal problems can be identified before progressing too far down the development schedule. With Agile, the development and QA teams are ideally sitting together and in regular communication with their daily standups, so there are few surprises.
Next, schedule code reviews between the team doing the new work and the team who knows the other portions of the product. Code reviews might be seen as soon as invitations to critique coding style, but that is not meant to be the case and that behaviour should not be tolerated. Rather, code reviews provide an opportunity to ensure that the developers are writing the software to work most efficiently with the code written by other developers once integration occurs.
Finally, do not invest such a large amount of money into a project that it could bring down a healthy company if that project fails to sell. Even with QA checkpoints and code reviews ensuring that the software will work as expected, without a selling product the rest of the successful products are put at risk if the company has taken too high a risk for too little reward.
Unfortunately Now Software did not have sufficient QA Checkpoints in place with the outsourced agency doing the work on a Windows client. It wasn’t until the final product was delivered to our home office and the money had all been spent that it was discovered the Windows client didn’t communicate correctly with the server. Some wonderful products disappeared from the market because of these very preventable mistakes.
It was this example of how quality assurance, or the lack thereof, can impact the health of an entire company that convinced me to go into that field back in 1996 by joining Microsoft after the firesale of Now Software. If you are looking for an exciting career of playing with puzzles, quality assurance would be an excellent area to try. And campaign for QA checkpoints!