We run a cloud service for oil and gas. Our goal is to grow organically, and to grow profitability not staff numbers. We value a high degree of autonomy, and we operate entirely virtually. We’ve been extensively using cloud services to run our business for over ten years, and now virtually everything we do, from mail and calendar to accounting and document management, is done in the cloud.
However, we didn’t start out that way. In 2000, when we formed the company, we didn’t have a grand plan, or a big vision, but we were sure we wanted to do things differently. Our business was building large, custom software applications for major companies like Sun Microsystems and the Health Professions Council. And when we looked at what our competition was doing, it was a really depressing picture. Failed projects everywhere, and processes that were designed to reduce risk and increase the chances of success, but ended up doing exactly the opposite. Vendors bid low, and made their money through change requests. Systems were delivered that barely met the needs of the client as defined twenty-four months previously, and which were miles away from current needs. Customers struggled to fit their new requirements within the straitjacket of the original specification, and suppliers delighted in proving that what was needed was not the same as what had been asked for. Everything seemed to be about confrontation. Requirements capture documents were about how not what, and the excruciating detail was intended to ensure that there were no change requests. In fact, the approach guaranteed a multitude of such requests. We looked at all of this, and we simply thought that “it must be possible to do it better.”
In our search for this better way, we investigated a multitude of ideas over the following years, and over the wide range of projects we delivered. We invested hugely in training, year in, year out. We looked at software development methods, like the Unified Method and the emerging agile methodologies. We became experts in requirements capture, and consulted widely in use case design. Everything we did was object-oriented, and we extended our use of Java so that it became our sole development language. We applied distributed object technology, and built systems with CORBA and investigated solutions that employed Jini. We used UML for modelling, and explored model-driven development. We studied component-based software development, and paid for some of the leading experts to train our staff. Over all of our years as a company, we never found the magic bullet, but we did learn a few things. I’ll talk about these more in subsequent blogs, but here are a few random thoughts.
First, customers fail to anticipate the full cost of a custom development over the life of the software, including maintenance and necessary changes and updates. If they did, it would be obvious that far fewer people should do it. It only makes sense to build rather than buy software if it truly drives massive competitive advantage.
Second, buying software and then heavily customising it is the worst of both worlds: the limitations of standard software and the high costs of maintaining customised code. Deployments we see of SAP and Microsoft Dynamics exemplify this.
Third, delivering excellent software requires excellent, highly trained and highly motivated staff, but it is difficult to scale this. As a direct result, our recommendation to clients with major projects has always been to split them up into small teams with deliverables that constitute a working part of the whole delivery, and not a sub-system or infrastructure layer. That is, divide vertically and not horizontally.
Finally, while we’ve changed our ideas many times and investigated and argued over and over again, we still believe that it must always be possible to do it better. There’s always a better way. That’s good in some ways, as it provides constant challenge, but it also means that our work will never be done, and we can never settle for the status quo. Next time I’ll talk about how our beliefs have shaped the software that we currently deliver, and why we think it embodies some fundamental principles that should underpin all software.