Welcome to our 8th news blog from Lakeshore Operations GmbH.
As everywhere in the world, the methods of software development change over time. The classic principles that were used 20 years ago carry great risks. New agile approaches are currently the non-plus ultra in modern software development.
In our blog today we want to take a stand here and describe the pros and cons of modern software development.
What is the goal of customers who want to develop software?
It is clear that the customers want to implement their ideas in a short time and with a manageable time and calculable financial commitment.
More than 20 years ago, software projects worked as follows.
In a so-called specifications, the requirements of a software to be developed were described in more or less detail. Often external consultants or business analysts were used, who wrote this document with much effort. There were countless meetings in which the ideas were discussed and discussed. Not infrequently, this document had many 100 pages and the compilation of the specifications often took several months, or even longer. This was depended very much on the complexity of the task and the requirements of the client.
What an incredible effort?
This specification was then sent to potential suppliers as a tender. Now, if a supplier got the order for the development of the software, the contractor had to create a requirement specification first. There, the software supplier has now described in detail how he will implement the task and what the customer gets in the end exactly. At the end, the specifications were considerably more extensive than the specifications and formed the basis for the contract to be concluded together.
Through these preparatory activities, a lot of time and money was burned and in the meantime, not a single line of code has been written.
We also believe that both documents have never been fully read by both parties. But such documents made a big impression, because you could prove that you had dealt with the task intensively.
Does a programmer know what he is doing?
Then began the actual work of the programmer, who now knew "exactly" what he should program. Everything was described in detail in the specifications.
Then the first project meeting was scheduled, where the developer should present the status and progress of programming. Not infrequently, after the first meeting, the customer felt that it was not what he wanted.
In most cases, the programmer just kept doing this. He knows what he does and in the specification, everything is described in detail.
The customer is nervous!
Then came the time when the customer visibly nervous pulled the ripcord and wanted to have changes or the program did not work as he had imagined.
At the latest from the time the discussion broke, who should bear the costs for the extra effort. Quite apart from the time that has been lost.
We personally have written a few specifications and functional specifications earlier according to the described method. We cannot remember a document that actually corresponded to the developed software.
It has now been recognized that software cannot be built like a house or a bridge.
Do you want to have what you have planned or what you need?
For this reason, the agile approach to software development has meanwhile become established.
The guiding principle is that the more you work according to plan, the more you get what you have planned, but not what you really need (source Wikipedia).
The goal of agile software development is to develop software much more flexibly and to get there faster and more cost-effectively to the goal.
The expense curve should be kept as flat as possible.
There are no endless planning sessions in the agile method. There are also no hundreds of pages of paper printed. In the agile principles, one communicates roughly about the task and subdivides the big task into small manageable subtasks.
How do you get to your destination faster?
The programmer then starts with the implementation of this first manageable subtask. The results are presented almost every day or shown to the customer after one or two weeks at the latest.
In this short meeting, the achievement of the specific goal is checked and the next manageable task goal is defined, which will be presented again after one or two weeks.Through this approach, a development in the wrong direction can be stopped immediately. Changes to original plans are possible at any time. Alone by eliminating the huge forecasts, significantly money will be saved and the implementation is progressing much faster.
How can the costs for development be planned?
It may come to the argument, however, that the costs of development in advance cannot be calculated. Yes, that's right. Here is a rough estimate necessary at the beginning. Most companies can roughly estimate from their experience how big the effort involved in programming a software is.
One thing is certain, and many examples have shown that the total cost of agile software development is significantly more favourable than the classic approach.
How many projects fail?
According to the controversial Standish Chaos Report 2011, projects created with agile principles are far more likely to succeed. If only 14% were successful in applying the classical method, 57% were problematic and 29% of the projects failed, 42% were successful with agile principles, 49% were problematic and only 9% failed. (Source Wikipedia)
So, if you are about to start a larger software project, you should first think carefully about how you want to develop your software. Even here it can decide whether a project is successful or not.
If you need support, just contact us!
Exciting for you!
The Lakeshore Operations GmbH is a software house, which was founded in 2016 to support companies in the digitization processes. We can draw on more than 20 years of experience. With IT experts from Rostock and Hamburg as well as programmers from Poland, Lakeshore Operations GmbH has a powerful team to support large or small companies in their IT or software projects.
Which way do you want to go?
Have you decided to bring your company up to date with digital progress? Do you want to find the right solutions so that you can shorten your work processes? Then you are exactly right here.
This will enable you to overtake your competitors and secure a place in the market. It is not the big one who eats the little one, but the fast one who eats the slow ones.
We wish you much success!
Jürgen Möller & Gunnar Bock