Following on from our recent post, we have part two of our jargon buster courtesy of Paul Collins, CTO, and Ben Williams, Chief engineer – @Spica Technologies Ltd, translating the jargon and buzzwords to explain common terms we frequently encounter.
PC: IPS stands for indoor positioning system and it’s just a type of technology that allows you to work out where either a phone or a device is, inside a building. Which is important because GPS, Global Positioning System, is not accurate enough inside a building, so you need an indoor positioning system.
BW: Because GPS is talking to satellites and the building tends to get in the way.
PC: Is an overused phrase but for us means a computer model of the building and everything that’s in it.
Fine Grained Security
BW: This is the ability to give individual users security permissions in the application that suit their role in the business. Rather than having to give lots of users all the same permissions, you can if you need to, give particular users particular access suited to their work.
Vertical and Horizontal Scalability
BW: The way I think of it is that for vertical scalability, eventually, once you have a very large number of devices, you can’t run one computer, one piece of equipment, that does all the work, you have to split it onto multiple machines. With vertical scalability, you split it based on functionality. Maybe you’ll have one machine that does one job and another machine that does a different job and another machine that does another job.
With horizontal scalability, every machine does a little bit of all the jobs. That basically means your vertical scalability is limited to how you design the software, whatever that limit is. However, your horizontal scalability is not limited to any size you like, because each machine is doing the same thing. So you can just add more and more and more machines all doing the same thing.
PC: Horizontal scaling is harder but almost inevitably with complex applications you end up doing both.
PC: A back end system, for us, is normally a computer system that’s used by a customer, often an enterprise customer, that people don’t normally see, it’s in the background. Things like a finance system or an order processing system.
BW: I would think of Devicepoint® as often being a back-end system for our client. With our app, it’s the interface to lots of back-end systems, meeting room booking, service desk etc, your phone which is running the app is not a back-end system.
PC: It’s a bit of a subjective term.
BW: This is more typical for web applications or mobile applications where if there’s a particular page that maybe you could navigate to through the UI that you want to share with someone else, the URL is navigable, so you get to the page using it and you can just cut and paste and send them the URL, they put it in, might have to go through a login screen but after that they’re on the same page you are, looking at same data as you.
PC: When you write a computer program, you can write a computer program and just think of it in lines, like do this then do this then do this… And that’s fine but the challenge is, if you then need that computer program to do something slightly different, then it can’t because it’s been written to do just that one thing. So software engineers will often think of a computer program as a group of building blocks that can be wired together in all sorts of different ways to be able to solve lots of different types of problem with the same code and reuse.
That’s what I think of being architecture-centric, is thinking of the problem in terms of blocks and sub-components or groups of things, then writing a program in such a way that you can assemble it to do different things, in a more re-usable way.
BW: The whole of software development is about managing complexity and abstraction is really the main technique for doing that, one abstraction is to have a well defined architecture that declares what each building block will do and the second side to that is to have governance to ensure that people use it the way it was intended rather than bending the rules. That’s how you start to deal with the complexity, and it’s a difficult thing, to build software, when you’ve been building it for 5 years and you’ve got 5 people, 10 people, 50 people working on it.