Tonight, the Founders @ FAIL meetup group, organized by former CCM’er Schuyler Brown, put on its second meetup, this time with the team from Haystack Media. Unlike for the first FAIL meetup, I’d like to focus on one particular point that is more relevant to me – the development of their technology. Specifically, there were technology related mistakes that they made – using an offshore development team and developing a system using mostly proprietary code – and I will discuss why it seems these “technical” decisions have consequences for a business in general.
During the interview, the Haystack team discussed how the development team was an offshore shop. I have always thought that using offshore shops, at least in the early stage of a start up, is a bad idea. An offshore shop is not going to have incentives aligned with the rest of the team, meaning that they are even less likely to produce what their clients want or, more importantly, need. In general, it is hard enough to get everyone on the same page, but having the extra barrier just makes it harder. Having an in house team who gets rewarded based on the success of the product certainly helps.
More importantly, developers, because they end up coding the business’s logic into software, end up understanding the business really well, and therefore develop validated learning about the business logic that can feed back into the rest of development plan. As Kent Beck said at the Lessons Learned conference, not only is working software more important than documentation, but validated learning is even more important than working software. As the people at Haystack Media discussed, they had a 400 page specification and barely working software. By not having an in-house team, they also lost an opportunity to gain from the valuable learning that occurs during the development process.
The other mistake that they discussed was building a system mostly from proprietary code. In recent years, the software industry has developed the concepts to understand why developing from scratch is bad for the business. When an accountant looks at a business, he sees assets and liabilities. Software can be seen in the same way. As a team develops a piece of software which will be an asset to the company, it creates liability in the form of future maintenance work. This liability due to maintenance is referred to as technical debt. The goal of the software development process is to create an software asset that will minimize this (inevitable) technical debt.
Developing a mostly proprietary system creates all sort of debt. First of all, a business can only have a few core competencies, and developing entirely in house creates a need for maintenance in areas that the business does not care about. For these, the system should use third party libraries which you let someone else maintain. That is one of the benefits of open source – when building an enterprise application, there are so many libraries out there that handle the stuff you need to do but doesn’t matter.
The Haystack Team summed it up by saying that “[they] didn’t know they were building a technology company.” As web technologies mature, more and more companies, start-up and otherwise, will find themselves in this position and will need to have a better understanding of how their software is being built and who is building it.