This series of articles is written for non-technical decisions makers who have a business need for software development but no technical background to validate their decisions. The objective is to allow them to make better business decisions regarding their project and therefore achieve a better Return On Investment.
Unlike other resources available on the web, we will not cover such an important topic for your budget with a one pager and 6 bullet points. We make the choice to get deep enough in each part for you to understand what is at stake. We make each article short enough to read each it in one go. We believe that this level of understanding is the one required to make better decisions. We know that when our customers understand better their own project, our partnership is even stronger.
So, let’s get going…
After so many years developing software, I had to explain countless times to non-technical people what my job was about. And in fact, every time it was a difficult task. There are some jobs for which when asked “What are you exactly doing?” one can answer rather easily. Not that the job is easy to perform but one would explain something not too alien to the audience.
If I am a pediatrician, an architect, a teacher, or even an entrepreneur, I can explain fairly easily what my job is about. People grab the concepts at stake: curing people specializing in children, creating buildings in which we will live or use, transfer my knowledge to others, or create an activity that will ultimately make some money against products and/or services. When it comes to software development, things are different. In fact, unless you have some experience yourself in software development, people have generally no clue. They know they are using software on a daily basis. They know that their lives are too often managed by software. But if you ask them how it works…
So, today, we will start a series of papers explaining what this business is about. The objective is to allow those of you who have a dear need of Software but do not have any technical background, such as entrepreneurs, investors, CEO, CFO, etc. to have a better idea of where their money is going and why it requires that big percentage of their wallet. We believe at Liemur, that trust cannot come from just faith. It is nice that our customers have faith in our skills. But it is nicer when they have faith and know why. The foundation of this trust is much higher and allows going much further together. In a way: Software development is far too expensive to spend your money based on faith and hopes.
Obviously, if we want to go beyond the surface and beyond pre-conceived ideas, we will need to cut this work in several articles.
So, here are the questions we will answer to in this series:
So, let’s get going!
At the beginning is Automation. Humans are lazy animals and they like the idea to have machines do their tedious jobs. A machine does not get tired and can work 24/7. On top of that, if we humans are clever enough, we can make these machine work faster than a human being. We then win twice as we do not have to work ourselves and the amount of work achieved is higher than doing it ourselves. That is the kind of win/win humans are addicted to. So, the purpose is simple enough: get more work done faster than what we could do and be able to redirect our energy on some more rewarding tasks.
Essentially, converting our real life problems into software solutions is a paradigm shift. From a world of people, objects, concepts, etc., we need to move into a world that knows only one thing: manipulating numbers. Although you do not need to understand in detail this conversion (if you wish, I explain it better in the Appendix), you might want to consider for a moment what it really means.
You have a car flow problem? Convert that into numbers! You have a customer management problem? Numbers! An image synthesis analysis problem? Numbers again! A medical diagnosis problem? Numbers! Etc. Etc. Etc.
Why should you care? Because, the paradigm shift implies a very serious transformation of your problem. Fortunately, along these years, computer scientists have grown tired of manipulating numbers to sort out problems, so, they have invented tools and techniques that make the world of programming and the real world closer and closer. Several layers of abstractions (notion of abstraction will be developed in a later article) have been added to the system that allows higher level of thinking. It does make the work faster. The bad news is: the faster we go, the more we are asked to do. In other words, as soon as some productivity gains are achieved, the next project piles-up bigger expectations. Murphy’s law anyone?…
The job of the software developer is basically a job of translation; But a pretty tricky translation. Let’s have a look.
You, the stakeholder, have a problem you want to be sorted. You explain that in plain natural language. If you think about it, this explanation is rarely easy for a start. But let’s say you could explain fully and crystal clear what your needs are. –This question of crystal clear expressed needs will be covered later in the article about Requirements- The developer’s job is to convert all your concepts, actions, transformations, results, into another world via the use of another language: the programming language.
You mention your customers? They become in the developer’s mind a bunch of pieces of texts, numbers, logical values, etc. You describe actions on the screen? It becomes instantly a network of actions captured by the machine and converted into values that can be interpreted in order to do something.
These concepts in his/her mind have now to be patiently converted in new words, the development language words. But the problem is: this language is not as clever as the natural language. If you remember, far behind, this software language is only capable of understanding numbers. So, even if you add a fairly good amount of complexity and “intelligence” (and in time the industry actually did) the developer has to perform a very very serious translation of your problem. And because the target language is not a human one, i.e. fairly stupid, it requires a lot of explanations to get the machine understand what you want.
Now, one could say that there are plenty of industries where the job is to decompose the problem in smaller pieces. Building a bridge or a sky crapper is clearly not a piece of cake. That is true. And I would argue that these examples are neither cheap nor fast to create. But the point which makes software development so tricky is that it is 100% dematerialised. At no point in time, will you ever be able to touch the result of your work. The work is totally abstract. Concepts are abstract, transformations are abstract and results are abstract. Nobody can go into the code and have a look for visible defaults, leaks, cracks or improvements. To do so, one needs to first understand the objective, then recreate the abstraction in the mind and start working on it …virtually. And every developer will tell you that getting into somebody else’s code is a very hard task. if the humans have developed this capability of abstraction, it remains a complex activity to work in a totally virtual world that is neither visible to the eyes nor touchable.
One might want to compare to the work of writing books for instance. In some respect, it is, but books do not drive cars, pilot airplanes or alert you of your next meeting.
Conclusion: A better return on investment
In our next topic, we will cover the following questions:
Liemur provides Software Development Services within UK and with its nearshore branch in Budapest.
Contact us about your project.
The means are “calculation”. In fact, calculation can achieve almost anything. Calculation can find the square root of a number fast yes, but it can mostly sort numbers, manipulate numbers, transform number. So, at the beginning are numbers. If we want to be true to what a computer can do, it cannot really do much as it can mostly manipulate 0 and 1. But cleverly combined, 0 and 1 can represent other numbers. With these other numbers we can represent all calculations. But we can do more: we can represent other types of information. Indeed, one needs to manipulate text and concepts. So, we started by representing characters with special numbers. Have you ever heard of the ASCII table? This is just a list of numbers (between 0 and 255) in front of which we have a character.
The reason for the 0 to 255 is a bit beyond our objectives. I’ll ask you to take that for granted. Maybe I would just say that 256 is equal to 2^8 (2 at the power of 8). 2 is the concept of 0 and 1, two values. 0 and 1 are “bits”. 8 is the number of bits we are working with, hence the notion of 8 bits architecture. That was at the beginning. Since then, we have had 16 bits, 32 bits and nowadays 64 bits architectures. Obviously using 64 bits to represent the world is much better than 8. With 8 one can represent 256 things. With 64 one can represent 1.8 10^19 things (2 power 64). That is a hell of a lot!
What about concepts then? Numbers again! If one needs to manipulate colours, for instance, we just give a number to each colour. Does the time we had screens in 256 colours ring a bell? Well, you have the explanation. And nowadays, with the 64 bits world, our screens are so much nicer! You now know why!
So, basically, when properly done, we can manipulate almost anything we want, providing we can represent that very thing with numbers.
What we cannot do is representing fuzzy concepts with computers. So, we do not have the possibility to represent Love, Empathy, Joyce, Sadness, Honesty, etc. We have tried and are still trying and we call that Artificial Intelligence. But so far, it is not 100% convincing. As long as numbers represent the world, we have a problem! …even with many of them. The real world is not totally made of numbers.
Liemur provides Software Development Services within UK and with its nearshore branch in Budapest.
Contact us for more information.