BeBee and the new platform... How to develop new software and not die while trying?
At the end of April, I published this article in the hive "beBee in Spanish", in which I talked about the development of software, its stages, and some of the tests that are usually done, during the whole process of creating the new software, until the launch of the program in its official version (alpha version).
The reason was to render a simple homage to beBee and all its team of professionals who, for some months, were under great pressure, since they had to develop and implement a new platform, fully operational, and available for different environments (desktop and mobile), also taking into account the different operating systems available on the market today.
Moreover, all this while using the old platform known to all of us.
Which was creating malfunctions, and as I already said a lot of pressure on all beBee members.
Remember that it was a very difficult few months for beBee, I as a brand ambassador felt I had to do something that would somehow relax the tension in those days.
My intention was to make known the great difficulty of the whole process that was being carried out, so that all the bees in the hive could understand in some way that this is not an easy process, much less a fast one.
The truth is that just 2 months after the publication, my article has been very well received, and with great comments.
That is why I decided to translate it into English for all of you, so that you can also be part of this simple tribute to beBee and his team, who work so hard every day to make beBee better and better.
I apologize to the real IT professionals who can read me, in case I have made a mistake. I am not at all a professional in these matters, and all readers in general, who can read me (hopefully many) because of mistakes in the translation. My English is very oxidized after many years of not practicing it properly.
I will be happy to correct anything that you tell me is incorrectly redacted.
Thanks in advance to all of you for reading me, and for all the support and follow-up you give me, it is a real privilege for me.
* * * *
Hello bees, it is at this time when it is (now!) 2 "intense" years since I joined beBee, and as in previous years I wanted to do something "special", but still faithful to my usual theme.
In addition, I wanted to "seize the opportunity" to thank in some way, and "pay tribute" very humbly to the whole beBee team, for their great patience, effort and dedication, because users can be very heavy and inconsiderate sometimes, and did not know how to do it, or what to write about.
In the end the solution to this lack of inspiration was simple, I only had to review the evolution and the current situation of the hive in recent weeks to be clear about what to write about, in such a way that at the same time it could serve as a recognition of the great work and the enormous effort of each and every one of the components of the beBee template, from the "bosses" to the "buttons", so to speak.
So I'm going to talk to you about software development, and the different tests that are performed, before the final and definitive version reaches our mobile devices and personal computers.
We have all noticed and "suffered" (in recent weeks) the inconveniences of what the development of a new platform for our beloved hive can mean, but as much as it makes us uncomfortable, we must think that this is a direct consequence of the great success of beBee, and of its great growth that, among other things, puts a lot of pressure on us, and forces us to make many more improvements than those initially planned, and of course, in much less time, which in turn also generates new failures and mistakes, which we all suffer.
If we can be bothered by a malfunction of something as users, can you imagine what this can mean for the different members of the beBee team, who are under pressure from all of us, from the market and "current events", from each other's superiors, and also from investors, who have placed their trust and money in a project, with which they certainly want to make a profit, as they are not NGOs.
You can be sure that of course, it's not easy, much less pleasant, and for you to have a "slight idea" of the enormous amount of work and effort involved in everything they are doing, that's why I'm writing this article, which I hope and wish you will read with the same attention and love (for them) that I have put into this post, bearing in mind that I am not a professional software developer, so it may be that the article could contain errors, for which I apologize in advance to the real experts and professionals in the field, such as beBee members themselves, and other users and professionals with great knowledge of the subject.
Written by me, with all the love and admiration that has been possible for all of you, beBee guys, and of course, "summarized and tamed" also by me, with the same love and respect for all beBee bees, whether they are known or not, followers or not, veterans or newcomers, all this is of course also for each and every beBee bees.
Dedicated to all of you!
The success and "performance" and the quality and reliability of our software will depend to a large extent on the tests that we put into the previous version of each program, and on the "bad times" that we have had, both we and the users, since we NEVER get the "perfect software" the first time (not by a long shot), and we must continue to improve it, even after it has been released.
This seems to many to be an "obvious"
truth, but it is still one of the outstanding issues in the world of software
application development, much more common than I would like to see it, and more
common than it might seem.
Developing software without testing is like doing tightrope walking without a safety net, and also represents a source of errors and bad practices, as well as ensuring almost certain failure.
I am going to try to show you some of the basic
concepts of the tests that should be done, according to the general opinion of
professionals in this sector, but bear in mind that I am not a developer, much
less a professional of this, I am just a modest theorist and passionate about
Why run tests?
Testing is the way to
make sure that what we want our programme to do, to do it effectively and in a
stable' way, and to do it, of course, without error.
Failures and errors are inevitable, especially if we only try to avoid them with our own capacities, so we must use other "tools". There is software that helps us to "correct software".
When thousands and thousands (sometimes even
millions) of lines of code are written, and even in different programming
languages, and therefore, with different "spelling rules", a
simple"," or "space", of more or less, or in the wrong
place, can make the software not work, or worse, malfunction, so that the
"concrete" error could go unnoticed, then we would know that there is
a malfunction, but we would have no idea what kind of malfunction in the code
is causing it, and in what part of the code it could be.
It is here, when we must bear in mind that there are also "dependencies", so, just as an error here, it can be reproduced there as well, since the "wrong instruction" can be used in several different processes, we will have to know which dependencies that instruction has, to correct it in all the processes where it is executed, this is what is called "refactoring", and it allows us to correct an error in the code, having the dependencies that the erroneous instruction may have, in such a way that it will be completely corrected "where necessary", but without affecting the satisfactory behavior of the program.
Fortunately, before writing the code, you have to "design" the program, using different graphics, where you "see how the software works" and all the "methods" (instructions, functions) that your software will need to work properly, and all this has to be done before you start writing the code, properly speaking as we know it. This is what is called UML (Unified Modeling Language), which in Spanish means Unified Modeling Language, and of which our beloved Federico 🐝 Álvarez San Martín surely knows many things, and can tell us many "stories to keep us awake".
There are the "Integrated Development
Environments" (IDE), which are like "special" text editors that
warn us of "spelling" and "grammatical" errors and suggest
possible alternatives for better "writing".
If you add to that that "that text"
will surely be written by more than one person, it can be very complicated, and
that is why you must establish a "prior rule" of how to write that,
for everyone to do it in the same way and, furthermore, the lines of code must
be commented on, to facilitate correction and understanding afterwards.
As a curiosity, Linux OS can have about 300 million lines of code, Mac OS about 90 million, and Windows XP had about 45 million. If certain writing rules were not followed, nor were comments made about what is intended to be done in this or that part (module, lines) of the code, you can imagine what it would be like to correct a code error 3 years later, and without even writing it yourself... It would be IMPOSSIBLE. The tests are not optional. Software without evidence is a bomb about to go off.
Which developer has not had his code left in a box for half a year, and when he comes back from touching it, he has the feeling that someone else has written it?
Me in a systems programming course, when we were doing a "simple" (for me it was a whole world) program without a graphic environment and written in Java language, which represented a video club (with all its operations and usual functionalities). When months later I wanted to improve it at home "quietly", when I saw the code again, it was as if someone else had written it, and I almost had to redo it from zero.
We do not recognize our own creature. And let's
not talk about it when we are integrated into a team, or receive the
"little gift" of supporting or evolving a legacy code.
Therefore, testing is essential, as it allows
us to ensure that applications meet the functionality expected of them and
quality expectations (not just code) helping to find those errors or defects that
have not yet been discovered, reducing the cost of development, the cost of
ownership for users, and generating confidence in customers to avoid annoying
Not to mention the growing sense of security we need to have, as we get closer to deploying the new software, because the more code we have, the more testing we have to do to make sure "everything" works properly.
The "universe" of types of tests
The tests also have an endless number of different types, versions, evolutions and classes, just like the software in general, here are some of the most common, important and essential.
Unit tests: Unit tests are automated tests that verify functionality at the component, class, and method or property level.
The main purpose of unit testing is to take the smallest piece of verifiable software in the application, isolate it from the rest of the code and determine if it behaves exactly as we expect it to. Each unit is tested separately before being integrated into the components to test the interfaces between the units.
Unit tests must be "written" before (or very soon after) writing a method, with the developers who create the class or method designing the test.
Integration tests: The individual units are integrated together to form larger components. In its simplest form, two units that have already been tested are combined into a'new' integrated component and the interface is tested between them.
Integration or "component" tests identify problems that occur when units are combined. The new errors that arise are probably related to the interface between the units, rather than being errors unique to the units themselves, simplifying the task of finding and correcting defects.
Regression testing: Every time changes are made to a project, the existing code may not work properly (as it used to) or that previously undiscovered errors may occur. This type of error is called regression.
The entire project must be regressed, which is a complete re-test of an entire modified program, rather than a test of only the modified units, to ensure that no errors have been introduced with the modifications.
This type of testing should be automated, because it can be composed of tens or thousands of unit tests, integration tests or more.
A less expensive version could be to build tests that replicate the actions that caused the regression, and check that they have been corrected when the errors do not happen again, in addition to adding unit tests to ensure that the code where the regression has been corrected works correctly.
Functionality tests: These are automated or manual tests that verify the functionalities of the application or module already built, but from the point of view of the end user, with its different roles, to validate that the software does what it should and, above all, what has been specified.
In their automatic version they are tests that are automated to "save time". From the test cases of the manual tests, other test cases are automated to be repeated in the executions. These cases are often the most important of the "vital" business modules or processes in the application. That is to say, they are the processes that always have to work, and that under no circumstances can they fail. The purpose of automatic functional testing is to check that there are no regressions.
In the case of manual tests, they are executed by a tester (or several) as if he were a user, but following a series of steps established in the test plan, designed in the requirements analysis, to ensure that the software does what it should (positive cases), that it does not fail (negative cases), and that it is what the customer has requested.
The tester will perform the actions indicated in each step of the test case, checking that the expected result is met. If the result is different, a defect will be reported in detail: description, data used, screenshots, etc. to be able to replicate the error if necessary, and facilitate the solution.
The biggest problem facing functional tests for automation is their fragility. Each test can test thousands of lines of code, hundreds of integrations, and a changing user interface. Becoming not "sustainable" in its entirety and in accordance with its objective and definition, cost and maintenance.
Looking for the limit of the applications
Now comes the operations part, where you must also automatically test the capabilities and weaknesses of the software and the platform it runs on (infrastructure and dependencies), taking it to the limit, to check its availability, stability and resilience. Looking for the limit of the applications
Stress testing: In the case of small-scale testing, where a single user runs a web application or database with only a handful of records, it may not reveal problems that occur when the application is used under "real" conditions.
Stress tests look for the functional limits of a system. This is done by subjecting the system to extreme conditions, such as maximum data volumes or a large number of simultaneous users and processes. They are also used to enable the system to be tested for continued operation beyond its limit after it has collapsed and to assess its "resilience" capacity once it has been released from the load and returned to its optimum operating condition.
Performance testing: Determines the responsiveness, performance, reliability and/or scalability of a system under a given workload.
In web applications, performance testing is often closely related to stress testing, performing checks such as measuring delay and responsiveness under a heavy load. In other applications (desktop and mobile applications, for example), performance tests measure both speed and resource utilization, such as disk space and memory.
By conveniently storing all the results of the performance tests over a period of time, we will be able to know the health status of the application, being able to obtain trends and performance forecasts; and optimizing each deployment according to the performance required in each case.
Security tests: Validate the security services of an application, and identify possible failures and weaknesses.
Many projects use a black box approach to security testing, allowing experts, without software knowledge, to test the application for holes, bugs, exploit and weaknesses.
As you can see, the "universe" of tests is immense, being one of the branches of computer science that requires a specific specialization.
Programming is not the same as writing code
It is a general
opinion among professionals in the sector that there is a big difference
between programming and coding, in reference to the design and creation of
The act of programming is rather to organize,
plan, and structure through some kind of methodology and algorithms, the optimal
solution to a need or problem raised. And encoding is writing code in a
computer language, to instruct a computer to perform the required activities,
if possible more quickly and efficiently.
When we say, we are going to program, in fact what we are saying is, that we are going to organize ourselves in the best way to find the best solution before we sit down in front of our computer to write code, without having a solid base of what result we want the computer to give us back, and that is satisfactory for us.
Important points in the design of a program
1º. We must analyze what the client asks of us, not to do more than necessary, although it is always good that what we do has added value. It is not a matter of doing simply and "strictly and exactly" what the client wants, because he could ask us for "impossible things", or totally out of budget, we should not do something that does not serve the client well, or cannot pay.
We are the ones who have the knowledge, and surely, we can provide better functionality to the software, which has not been requested by the client, and which contributes to a better later operation, with new updates. Software must be open to future new functionalities, and must therefore be scalable; it must be able to continue to "grow".
2º. First of all, we should focus on making the "overall" solution satisfactory, and after we have achieved the goal, then worry about the graphical interface (GUI), because before we "waste time" in making our program look good, we must make it work properly. And that it works not only means that it has no compilation errors, but also that it shows the actual results of what is expected.
3º. Search for any and all of the validations and/or restrictions (what can be done, where and how) that can be applied to it so that the end user does not make mistakes that cause our program to have fatal failures such as unexpected system abandonment or loss of information.
4º. Make a precise and detailed algorithm of the steps that give the solution.
5º. Make a Flow Chart that represents each and every one of the steps indicated in the algorithm.
6º. It may be convenient to make a "pseudocode" (code written in human language) that we will use (as a reference) to write the code of the solution to the problem.
7º. Use the best programming language, to write the code of the solution to the problem. The best programming language is not the best technology, it may not be the most current, nor the one with the best properties, the best language for a programmer, it is always and will always be the one that you as the best programmer master and work with, since, under this simple concept, we will not waste much time in first knowing the language, its syntax, and then apply it.
Although this is secondary nowadays, developers and their teams know several different languages, as they are composed of several people, specialized in different languages, and depending on the type of software, and how and where it will run, it will be much better to use one or the other, since each language has different capabilities, even different languages can be used, in different areas of the software we are developing.
8º. We must also be very attentive to the further development of the program we have developed, in order to be able to offer a good subsequent maintenance solution, (normally it is in maintenance where the real business is), when it is fully operational at the customer.
9º. We will also have to act as if we were end users and thus perform any and all necessary tests on the program before delivering it, and we can also choose real end users, and ask them to use the program in the same way as they would later, when the program is implemented and operational in their'real environment'.
10º. In the event that we are ever unable or unable to find a solution to a particular problem, we will always seek help, asking questions, consulting other professionals, and also researching on the Internet or in books and specialized publications, since it is certain that the same (or a very similar) problem has occurred to someone before.
"That's all folks"...
I hope and wish that you liked it. Now it's your turn if you want to make a comment...
References (Spanish language)