A software engine

Software and software development can feel pretty abstract and might even be considered witchcraft by some.

I like using analogies to explain to other people what it is we actually do while trying to avoid our confusing jargon.

Actually I like using analogies so much, more than one of our customers have commented that if I ever tire of software development I should start selling ceramic tiles with sayings on it. I would like to invite you to come along on this little thought experiment with me to look at what we do in a slightly different way.

Driving software

Think of using software like driving a car. Driving a car has a function in taking you from A to B or moving cargo. Much like software can be used to say write a text document or share pictures. Cars can be driven for work or fun just like software can be used both for work or gaming. By driving long distances across our road network we can get in touch with other people. The internet and the software we run on it does much the same. We used to even send our written mail across roads to each other....imagine that.

For most people cars are utilitarian except for car enthusiasts and car builders. The latter group lives for their cars and take great pride in what they drive and or build.

Some even get almost religious about brands and their toiled perks to the point where it starts to annoy everyday car users. The damn thing should "just work". Which I imagine is a hated sentence for car and software builders alike. Over time cars have gotten more complex but we've also gotten way better at building them in a faster and safer manner.

And lastly cars can be driven by the buyers themselves or they can have a chauffeur. A construction vehicle for instance can require a driver with specialized training and will not be meant for the general public. If you make cars for the general public they need to be far more intuitive (or have a great manual) then one where someone is expected to complete a training course. You do not need a drivers license for software, thankfully but some might require a different kind of license before you are allowed to drive them. And there is also the business of selling cars to other businesses. For example selling cars to a cab company or law enforcement agency which would have slightly different requirements. Software will end up being built differently depending on if it is meant to be used by customers directly or other businesses.

Building a car

If I look under the bonnet of my car I feel....lost. Partly because the engine in my car isn't in the front but also because an engine looks like a circus of parts working together in magical ways. However, as complex as an engine is, if you take it apart for long enough you end up with small, simple and understandable parts. Things like nuts, washer, hoses, drive shafts, gears and so forth. Spend enough time under a bonnet and you start seeing the different sub-constructs that make up the engine. You realize there are pumps moving fluids and turning things making other bigger things turn. Software is similar except the visual inspection part just has you looking at text; code as we call it. I'm going to ignore the physical part(computer, phone, etc) we run the software on for now but the same principle applies about taking it apart.

Computer code, unlike car parts, can be written in different languages. The closest analogy I can think of is that a part can be made out of steel or carbon fiber but still serve the same purpose. They just have different properties which makes the one more applicable then the other for building certain specialized sorts of cars. I have a saying that "programming is a skill and the language is a choice" which applies here. Most programming languages have the same nuts and bolts but they might go together slightly differently or they only fit in certain places. For instance, if you want to develop for a mobile operating system like say iOS you have to write your code in a language called Swift. On the web the language of choice is JavaScript. I'm simplifying here with the language choices because we also have tools that can turn output from one language into another. Because software is not restricted to physical limitations we can change things up a lot faster than we could on a car. Would be nice if we could use some process to transmute the metal on our cars to gold because it has better heat conductivity. These are the kind of experiments we can do with software which is part of the appeal of the field. Also we've been building cars for considerably longer than we have software. Which means that the tools we use to build cars have become far more advanced than the ones we use for software. The same thing applies to quality control. Inspections and crash tests for cars are mandatory while for software development its presence is recommended but sadly often missing.

Life of a builder

I'm not going to pretend to know how cars are built in any level of detail. I can however talk about software builders a bit because that is what I consider myself to be and that's what we do at SpringTree. As developers we love our shiny cars and would prefer to only spend time tinkering with it and driving them. Software development tools and the technologies involved are what we consider our tools to build the cars for our customers. Our learning process involves trying out new ways to put the nuts and bolts in our programming languages together. Our quality process is ensuring that the nuts and bolts are fastened correctly and the manuals correctly state what the final product does.

We make a diverse mix of software both directly for consumers and for other businesses. For some of our software we end up being the driver with the customers being able to work while sitting in the backseat. Taking that last scenario as an example, the goal would be to get that 5 star rating from your customer. Now if you pull up in an unwashed car with a friendly but casually clothed driver the customer could still enjoy the ride and be content getting where they need to go. Depending on their mood they will give you a 4 or 5 star rating but if something goes wrong you are quickly getting that dreaded 1 star review. Now imagine if the car pulling up looks pristine and shiny, the driver wears a suit and the inside has been vacuumed just before the ride. That should improve the mood of the customer and if something does go wrong the inspired confidence might prevent that 1 star review. Also what the customer does not see is that the driver checks his car every morning for defects and checks the tire and oil pressure before each ride. He also cleans the windows with alcohol because another more experienced driver told him that will prevent the glass from fogging up if the weather suddenly changes. SpringTree is not a 3 star company. We aim for that 5 star review and will grudgingly accept a 4 star review on a Monday. Oh and to my fellow developers, we know writing up that time-sheet for the fairs you performed is the most annoying part of the job. But if we don't we cannot bill our customers and we'd be a very popular but soon to be closed business.

In closing

I hope you enjoyed this little ride along. So what was the point of me writing all this down you might wonder.

My goal is to demystify the field of software development a little for anyone reading this by looking at something which could equally be seen as magic.

Also if this article has inspired any developer to vacuum their cars more often I'll be very happy.