Design Development Maintenance
and growth
Designing
an IT system
Software
development
Software
maintenance and growth
Tomasz

Tomasz Gdula, software engineer at FINGO, speaks about
developing business software

How is bespoke software made?

There are multiple myths about developing tailor-made software. Many people think, for example, that once developers receive a specification, they lock up in their rooms for several weeks to develop the software until they open the door and reveal the effects of their work to the delighted client.

Is the client actually delighted?

In accordance with modern methodologies and to ensure high quality and customer satisfaction, software is always created in close cooperation with the client. For me, software development is not a situation where we simply get a written specification and get down to the coding. My role in the company involves agreeing with the client how the software should work, and overseeing the development process to ensure the client's satisfaction.

But isn't it common that application development starts with a preparation of a detailed description of functionality along with the client, followed by development of the application based on such document?

Currently, the work of the project team is organized differently. The traditional approach you are talking about is increasingly being superseded by agile methodologies. We also work in this way. In the traditional approach an exact specification of the program is followed by the designing of the entire system, then developers start preparing the source code. Subsequently comes the testing phase, and the final product is delivered to the client.

We also follow these stages in our approach, but the time intervals are shorter and the phases apply only to smaller parts of the whole system. Such phases are called sprints. During a single sprint, which usually takes two weeks, we are not able to implement all the functionalities of the application, only a part of them. After each sprint the work can be tested and submitted to clients for review. Most complex information systems follow this development path nowadays.

What are the advantages of this method?

Clients are more hands-on with the project, they can quickly evaluate the application and give us feedback. While in the traditional approach they have to wait up to a few months to see an early version of the system, here the first functionalities are ready for testing within the first month. We continue the development if the client is happy, and include potential suggestions in the next sprint.

For example?

Let me use a system for traders working remotely as an example here. In the first stage we prepare a customer base that reps can freely browse and search. Even though it lacks several functionalities, it can still be used for instance for business correspondence. In subsequent sprints we implement the ability to create orders, view inventory, calculate transport cost for specific orders, view payments and credit rating. Each of these functions is a value for the users.

Are there any other benefits of developing applications in short sprints?

Many projects assume that clients know precisely that the application should do from the get-go. But when it comes to development, it turns out that this vision becomes less clear. Let me use the earlier example to illustrate this.

Along with the growing number of customers, the application should provide our client an easy way to find them in the database. The search can be implemented in many ways, from simple find by name, to sorting by various parameters such as time of last contact, the volume of orders (or recent lack thereof), customer location and the like. It is often not until users actually start to use this application when we find out their preferred search method. You can obviously try to predict it at the design stage, but life can surprise even the most experienced people.

What kind of requests do you get from users?

Users report requests such as: „I use it quite often. It would be best to put this feature on the main screen. This should work differently” etc. Thus, a great advantage of working in sprints is the possibility to give applications to users and listen to their suggestions for further development.

So, how to begin the first sprint?

We begin our work by defining a minimum viable product, i.e. a basic set of functions that must be implemented to allow the client to verify the business value of the product. Sometimes several Sprints are needed to achieve this.

How much time does it take to create the first version of the software?

It happened to us that the first version of the software was ready in a month. If this time is longer, it's good practice to prepare a working prototype that enables users to evaluate the proposed solutions. Although some functionalities may not work, the users will be able to formulate their initial opinions.

What makes good cooperation in software development?

Feedback is very important. It is the cornerstone of agile methodology. When lacking such information we must create software guessing at whatever would appeal to the customer. This approach, however, is doomed to fail. Fortunately, customers are usually after efficient communication. It helps a lot.

I think the greatest concern clients have against agile methodologies is the lack of information on the cost and time-frame of the project from the very beginning.

Since it is difficult to say how much the project will cost, a very detailed specification is needed. However, the cost of creating such specification may actually be bigger than the cost estimation error of agile development project.

Customers may have had bad experiences with projects whose cost increased along the development process, well over the estimates agreed on during the sales stage…

Whether it is business or any other relationship, building trust is important. The provider must earn it. It is difficult to take it for granted, especially if the client has bad experience working with other companies. We often started working with very limited trust, but ultimately managed to earn it with time.

Additionally, agile methodology allows clients save money on useless, from their point of view, detailed documentation which would still be subject to change later on. Instead, the client can oversee our work and receive the first version of the product. There is no need to make any assumptions, the clients can see for themselves we are able to deliver exactly what they need.

If your products are developed at such a pace, is there actually any time left to test them?

There is always time for that. Otherwise, error correction costs too much, and may also compromise our reputation.

We test our software in various ways. We like automated testing: we test in this way the individual functions in the code, as well as all the functionality. Think of it as a machine testing our application: clicking all the buttons and navigating through the screens. For some of the projects we do, automated tests are so complex that they take all night to complete. But when we come to the office in the morning, we can immediately see what needs to be improved.

Of course, even the best automated tests will not replace our invaluable testers. Their extraordinary inventiveness allows to detect issues that no programmer or machine would otherwise pick up.

You sound like „Sprint based methodology, i.e. SCRUM, is so effective that I can not imagine working in a different way”.

Traditional methods make sense for clients who know exactly what they want their product to do and can not afford continuous availability at the meetings. They would rather come back when it's ready and receive a complete system, developed exactly to their specifications. If, however, at the stage of making assumptions there were many concerns in the project team, you may want to consider agile methodology instead. Then most of the concerns will be settled during the development, with the participation of end users.

We have talked much about the methodology. What's a programmer's daily work at FINGO like?

Each of us works a bit differently. Some of us work on huge 30-inch monitors. I work on a laptop, which is just fine for me. It is often said that IT people would rather read an email from you that speak to you. While I understand some people are busy and don't like being distracted, I personallly love to talk and definitely prefer a little chat to e-mails.
Anyway, conversation is an important part of the methodology we use. We meet every morning to discuss the tasks for the day: what has been done, what obstacles are impeding the progress, and what we should focus on and do today.

Contact

FINGO sp. z o.o. (LLC)
  • Plac Powstańców Śląskich 7
    53-329 Wrocław, Poland
  • 8:00AM – 4:00PM
  • NIP (Taxpayer ID) 8942683871
FINGO sp. z o.o. (LLC) based in Wroclaw, Plac Powstańców Śląskich 7, 53-329 Wrocław, registered in the District Court for Wrocław-Fabryczna in Wroclaw, VI Commercial Division of the National Court Register under the KRS (Court Register Number) 0000020323, NIP (Taxpayer ID) 8942683871, REGON (Business ID) 932670710. Share capital 50.000,00 zł fully paid.
We use cookies to enhance your user experience. By continuing to browse the site, you are agreeing to our use of cookies.
Read more