Sometimes I tell a story about a farm and farmers.  A farms’ business is producing food, whether it be hops, cabbages or livestock.  They make their money by selling their output.  Obviously, they use many tools such as tractors, harvesters, seed drills etc etc.

Profit in farming is generally quite thin so the farmers don’t like spending money on things they don’t have to. They try to keep their machinery operational for as many years as possible using it for as many harvests as they can and getting as much value for money out of their investment as is achievable.  Tractors break down though, they require repair and maintenance and there comes a time when it’s no longer cost effective to keep the old tractor in service.  The decision is made to replace it with a new turbo charged John Deere or New Holland or Massey Ferguson or such like.  It’ll be expensive but it’s a long term investment, carefully calculated by the bank and other stakeholders and one that’s worth it in the long run.

Here at cap hpi, our product – the thing we sell - is the data. More specifically the access to the data we have.  Some of it is homegrown, created by our data scientists; some is acquired from other sources such as DVSA, maybe enriched in some way and presented in a certain form or cross referenced with other data in a unique way in our products.  The key here is that we sell access to the data, not software products.

We use tools, just like the farmer to produce the data, our crop.  Computers of course are our tools and like the farmers’, the age of our tools vary, they still do their job, “if it ain’t broke, don’t try to fix it”.  But like the farmer there comes a time when it’s no longer cost effective to keep patching up old tools or systems and a replacement is required; this is patently true when thinking about an old car.

We have a number systems for managing, amalgamating, and packaging datasets.  There are of various ages and using a number of technologies, probably closely aligned with whatever was en vogue at the time of their conception.  Not limited to Java we use Microsoft technologies too but this blog is about Java at cap hpi.

The Java squads, yes we are Agile and work in squads, are small and there are currently two of them.  They are not aligned with products as one might expect though, instead with the part of the business that the products support; the main one being the history of a vehicle.  You go to buy a used car, you’d like to learn what you can about the history of the car to determine if you might have any surprises at the next MOT and if it’s worth the asking price.  Perhaps more importantly if it’s not actually the vendor's car to sell, for example if it’s stolen or on finance.  That is one of a number of types of data our systems provide in a HPI check, which you may have heard of.  One of our Java systems does these kinds of checks and is used by car dealers and by our own call centre staff when people request checks by phone.

Imagine you wish to trade in your car.  The car dealer might get on his phone app, tap in some information about your car and present you with a valuation that he thinks the car is worth to him and hence what he might offer you to buy the car.  It’s likely that he used our data, maybe even the phone app supplied by cap hpi to present the data.

The Java squads develop and maintain all these kinds of applications which clearly use several different technologies, not just Java.  The handheld mobile applications run on IOS and Android and are supported by Java backends – using Angular.  There are Java web apps using Struts, JSPs, XML/XSL, EJBs (JBOSS), some tiny webservices using Spring, SOAP endpoints, Java 8, Java 6 – with an ambition to upgrade.

As Agile teams, with modern software development practices, the developer is expected to do much more than just writing Java code.  Developers at different levels perform pretty much the same tasks just the more senior ones do the more difficult ones and take more responsibility for the technical decisions made by the squad.  The squad makes decisions about the product, within Agile the Product Owner is in the squad and the squad members are trusted to make sensible decisions.  The squad determines how a tranche of functionality will be designed, maybe influenced by Solutions Architects; they’ll build it, QA Analysts who are also squad members will test it and arrange for it to be made live by Service Delivery.  Day to day support is done by the Java squad so we really do have to live by our decisions; we are never very far away from our software, after all it belongs to us, we run it, we don’t sell it.  The small squads mean everyone has a voice and is encouraged to speak up and play their part.

Remember our farmer buying his new tractor?  There is a Java squad currently responsible for providing a system that supports the functionality currently provided by a mainframe system.  This is a brand-new system, a greenfield project developing the system using modern technologies and techniques, deployed into The Cloud.  It’ll take a while and people are rotating in and out of the squad.  There is a lot to learn, undoubtedly mistakes will be made but it is Agile, we are not afraid to try, we’ll fail fast, learn from the mistakes and move on.  This project is in its Spring, the seeds that were sown in the winter are starting to sprout through the bare earth.  We are building the system with regular, small deliverables and it’ll take a few iterations before we have something tangible but bit by bit the squad is piecing together a working system.  The other products we look after are developed in the same manner with fortnightly sprints and regular releases.

We are working hard on creating our new system and at the same time maintaining, enhancing and simplifying our existing ones as well as support the customers using them.  We are busy and some nuts are harder to crack than others but isn’t that why we do it?  To rise to the challenge.