Go to content
The Codest
  • About Us
    • Staff Augmentation
    • Project Development
    • Cloud Engineering
    • Quality Assurance
    • Web Development
  • Our Team
  • Case studies
    • Blog
    • Meetups
    • Webinars
    • Resources
Careers Get in touch
  • About Us
    • Staff Augmentation
    • Project Development
    • Cloud Engineering
    • Quality Assurance
    • Web Development
  • Our Team
  • Case studies
    • Blog
    • Meetups
    • Webinars
    • Resources
Careers Get in touch
2020-09-07
Software Development

The ugly truth about software development process

Kamil Ferens

Head of Growth

The ugly truth about software development process - Image

Misunderstandings and a lack of vision of the product that is being built within a software development project are very common problems in the cooperation between the client and the team responsible for the process. These threats have a direct impact on the results achieved and are often associated with missed deadlines and budget losses. See where these dangers may appear and how to fight them.

Swing software - software development process

image source: perfectdigital.com

You know this picture, right?

I think it shows very well that big discrepancies and a lack of vision may appear in software development projects between all participants and people involved. Problems often arise from the very beginning, when the client comes with a (theoretically) final product vision and presents it to the team. Then come further misunderstandings, misinterpretations and, eventually, the project quickly goes down the wrong path of development.

While analyzing the graph above, I will present in a step-by-step manner all possible threats and suggest how to fight them. Let’s get right to it!

1. How did the customer explain the idea?

There will be discrepancies in the product vision from the very beginning. Why? The reason is very simple - everyone interprets reality in their own way, has an idea of something in the mind and may not accurately present this vision to the other party. If you describe in words a product that you would like to build, there is a high probability that the development team will understand your vision in a different way than you intended.

Of course, it is possible to avoid this. You should start visualizing as soon as possible and discuss individual elements of product functionalities based on sketches. Interestingly, the first sketches usually have nothing in common with the final product. At this stage, however, the most important thing is to make the vision coherent.

2. How did the project leader understand it?

Wondering why the first and second picture is so different? The project leader will always take a closer look at the product vision. However, it is important that such a person, essentially responsible for the entire software development process, fully understands the problem and the needs related to the product. The project leader must have a clear "bigger picture." As you can see, both images do not differ in terms of functionality. They just look different. To better understand this point, let’s return to the picture number one. At the beginning of the project, there were no sketches and that already led to a misunderstanding. The functionality of the product is correct, but the design is completely different.

3. How did the analyst design it? and 4. How did the programmer write it?

Sometimes, analysts and developers do not know the needs of users or established business goals. They see only the small piece of the entire project, which captures their main focus. They are not able to look from a broader perspective, and this is particularly the case for large projects, where a lot of developers work at the same time.

We can also use another example. It may happen that the problem to be solved is incorrectly described, for example, by the product owner. This involves providing incomplete information upon which the developer or designer create their own interpretations, and the product deviates from the intended development path more and more.

How to change that? I think that a good solution is to make sure that the people who are key to the project have detailed knowledge about it – the so-called "bigger picture." In case of misunderstandings, it will be easier for them to bring the software development process back on the right track. Therefore, remember - if everyone sees only their tiny fragment of the developed functionality, the misunderstandings in the vision become a likely threat.

5. How did the business consultant describe it?

Here, the matter is simple. The product must sell. You have to stand out somehow, so, for instance, a simple swing for your garden attains extraordinary elements. The idea is to convince a potential buyer. The marketing and sales department will certainly do everything to show that the product is unique.

6. How was the project documented?

Missing documentation is a very common problem. Sometimes, creating documentation during product development seems like an unnecessary waste of time. This is a mistake. I say very often that changes are made faster on paper than in the code, and there is something to it. In addition, it is easier to refer to the documentation to track any changes. Believe me, a project without documentation is at a very high risk of missing the vision.

7. Which operations were installed?

This stage refers to placing the environment on the server. As in the point about programmers and analysts, without full data and with communication gaps, it may turn out that only a part of the necessary environment has been created.

8. How was the customer billed?

It's the result of poor communication, lack of UX and so on. The appearance of errors increases the development time. And time is money, right? My hint is to run the project in accordance with Agile, maintain the highest communication standards and keep clear budget guidelines. I have no doubt that by doing so you will avoid such problems.

9. How was it supported?

Customers frequently focus only on building a product and finish at that. However, we live a time of many changes and technological innovations, which is why it is necessary to maintain constant tech support. The idea is to avoid a situation in which something suddenly stops working as it becomes outdated and the product loses its value. This aspect should not be forgotten either.

10. What did the customer really need?

We have reached the last point. Look at the discrepancy between the first and last graphs. After all, both relate to the client's perspective. Why is this happening? Everybody lies it as simple as that :) Survey results always differ from your respondents’ actual needs. While answering the researcher's question, users want to show their best side. Therefore, THEY OFTEN DO NOT RESPOND TRUTHFULLY, but rather in a way they think they should answer. Basically, they do not want to be exposed to the negative assessment of others. Here is a small hint for you – mention in the instructions that there are neither good nor bad answers.

Where else do the differences appear? People often don't know what they really want. Quite often, users initially say need 10 functionalities in the product, and later they actually use only, say, 3.

So how do you solve this problem? In addition to asking the users what they want and need, allow them to test to the product, preferably on authentic items to maintain credibility. The more tests during the creation of products, the greater the chance that the result will be accurate.

Summary

If you ever become a member of a software development project, remember my examples and draw conclusions so as not to copy the above errors. And remember, these concepts are very important in building a product (application) from scratch:

- good UX and tests, so you can learn what your users really need,

- communication within the project, so a deep understanding of the problem and needs is available for key people in the project,

- develop the product in accordance with Agile,

- don't forget about tech support.

Read more:

- How to effectively manage remote developers? The guide for CTOs

- Python vs. Ruby? Which technology should you use for product development?

- A quick guide to building and developing your own marketplace. What is worth to know?

Related articles

Software Development

3 Useful HTML Tags You Might Not Know Even Existed

Nowadays, accessibility (A11y) is crucial on all stages of building custom software products. Starting from the UX/UI design part, it trespasses into advanced levels of building features in code. It provides tons of benefits for...

Jacek Ludzik
Software Development

5 examples of Ruby’s best usage

Have you ever wondered what we can do with Ruby? Well, the sky is probably the limit, but we are happy to talk about some more or less known cases where we can use this powerful language. Let me give you some examples.

Pawel Muszynski
Software Development

Maintaining a Project in PHP: 5 Mistakes to Avoid

More than one article has been written about the mistakes made during the process of running a project, but rarely does one look at the project requirements and manage the risks given the technology chosen.

Sebastian Luczak
Software Development

Why you will find qualified Ruby developers in Poland?

Real Ruby professionals are rare birds on the market. Ruby is not the most popular technology, so companies often struggle with the problem of finding developers who have both high-level skills and deep experience; oh, and by the...

Jakub
Software Development

9 Mistakes to Avoid While Programming in Java

What mistakes should be avoided while programming in Java? In the following piece we answers this question.

Rafal Sawicki
Software Development

A quick dive into Ruby 2.6. What is new?

Released quite recently, Ruby 2.6 brings a bunch of conveniences that may be worth taking a glimpse of.  What is new? Let’s give it a shot!

Patrycja Slabosz

Subscribe to our knowledge base and stay up to date on the expertise from industry.

About us

The Codest – International Tech Software Company with tech hubs in Poland.

    United Kingdom - Headquarters

  • Office 303B, 182-184 High Street North E6 2JA London, England

    Poland - Local Tech Hubs

  • Business Link High5ive, Pawia 9, 31-154 Kraków, Poland
  • Brain Embassy, Konstruktorska 11, 02-673 Warsaw, Poland

    The Codest

  • Home
  • About us
  • Services
  • Case studies
  • Know how
  • Careers

    Services

  • PHP development
  • Java development
  • Python development
  • Ruby on Rails development
  • React Developers
  • Vue Developers
  • TypeScript Developers
  • DevOps
  • QA Engineers

    Resources

  • What are top CTOs and CIOs Challenges? [2022 updated]
  • Facts and Myths about Cooperating with External Software Development Partner
  • From the USA to Europe: Why do American startups decide to relocate to Europe
  • Privacy policy
  • Website terms of use

Copyright © 2022 by The Codest. All rights reserved.

We use cookies on the site for marketing, analytical and statistical purposes. By continuing to use, without changing your privacy settings, our site, you consent to the storage of cookies in your browser. You can always change the cookie settings in your browser. You can find more information in our Privacy Policy.