What challenges do developer-programmers face?

The 8 most common mistakes in software development

The 8 most common mistakes in software development

Below are some of the major challenges in software development.

1) Missing planning of the project

Nobody wants to take the time to plan. Instead, I would like to start programming right away.

It is best for the programmer to sit down and write the first line of code. That way, you think, you waste less time and are productive right from the start.

The problem with this, however, is that if you do not plan to become productive more quickly. However, you are most likely overlooking important points, such as choosing the right technology or properly defining the purpose of the software.

Solution: There is hardly any solution to this error. Usually none of the parties (programmer, client, service provider, etc.) has the will to deal with extensive planning.

2) Inaccurate description of the requirements

Due to a lack of planning, the exact requirements for a project are also missing.

This makes it extremely difficult for the developer to implement the right things.

For example, in many projects the Requirements only formulated in writing.

For example, a Supplementing with pictures (for example wireframes, approximate drawings of the functionality) help a lot.

The requirements are also not communicated correctly. This is mostly due to the fact that there are many layers of project leaders, team leads and managers between the actual project formulator and the one who programs the whole thing.

Solution: It would be better enable direct communication between the project formulator and the programmer. This avoids nasty surprises. It is funny to do an ear whisper experiment where one person says something to the other and the sequence continues and something completely different comes out at the end, but in software development this leads to discussions and conflicts in the end.

3) Inappropriate choice of development method

The so-called waterfall method of software development is used in many software projects.

The advantage here is that the requirements are all recorded at the beginning and the price can also be set, so that there are no surprises later.

The reality, however, is that the project client realizes during the project that this and that functionality was incorrectly planned or that a completely different functionality would be better.

However, this cannot be incorporated into the waterfall method, at least it contradicts the philosophy of it. This can lead to conflicts if the client relies on the implementation of the functionalities, but the executing company or the programmer insists on the functionalities specified at the beginning and is not ready to make changes during the project. Rather, it insists on having this implemented in the next phase at the end of the development.

So the so-called agile software development is always better, in which one assumes from the beginning that further functionalities will be added and that it is the human way not to consider everything from the beginning.

The problem is then that there is no fixed price with Agile, but rather everything seems very vague to the customer. Because of this, it will be difficult to set up this form of programming.

What many contractors do because of this is just to name the advantages of agile and to start with the agile implementation. However, once the price goes up, conflict can arise. Statements like “That was part of the requirements right from the start” are known to almost every programmer.

4) Wrong technology selection

Errors are often made, especially when it comes to technology for development.

New, exciting technologies are often used, examples today are Golang or Node.JS.

The problems that arise from this are diverse:

  • a) If the manufacturer of the new technology decides to update, then you may have to rewrite the entire code. One thing that is very cumbersome and not really practical.
  • b) It is also difficult to find good developers for these technologies. Either they are 1) too expensive because good developers are in demand in these niche technologies, or 2) they are relatively inexperienced because the technology hasn't really been around for long.
  • c) Let's say it is possible to find a good developer. What if he leaves the company? Finding a replacement is a challenge, because mostly the developer you already had was one of the few who really knew about the technology.

The best solution: The best solution is to use tried and tested technologies.

An example here in the web area would be the combination of PHP, MySQL, JavaScript, HTML, CSS.

This combination of skills can be found almost everywhere and experts can be found at affordable prices / salaries.

Addition: As soon as you add just one more "exotic" technology, such as Angular, to this web combination mentioned above, then the number of possible programmers decreases considerably, because perhaps only 10 percent of web developers in this area are familiar with it . If you add Node.JS, for example, then it may be 5 percent, if not less. So it's best to stick to the core technologies that have been around for a long time and that will certainly be around for a long time to come.

5) Too compact incomprehensible code

In the past, legitimate attempts were made to write “more efficient code” by using short names and complex functionalities to make the code shorter.

Because of this, the code became executable quickly over time, but it became more and more illegible.

Nowadays this is no longer necessary, there is almost infinite computing power and you can write more lines of code without worrying that the program will be slower.

If you write the code cleanly and also describe it, then another developer will be able to familiarize himself with the programming.

6) The time required is incorrectly estimated

There is hardly a single project in which the timeframe of software development is adhered to.

It always takes at least two times to a multiple of the assessment at the beginning of the project.

This is due to the new requirements made by the client during the project, but also to the fact that a developer cannot precisely assess larger projects.

If a developer estimates a project to take 6 months to develop, then the alarm bells should be ringing, because nobody will be able to accurately estimate such long project periods. Not even the most experienced programmer.

Solution: It is better to break down the tasks into smaller modules of a few days. This makes it possible to give a more precise estimate.

7) Budget is set too low

Due to the lack of planning, the wrongly estimated time and the increasing complexity of the code, the necessary budget for the project will also increase.

Just like the time, the budget is usually twice as high or a multiple of what was initially planned.

Solution: Always plan a buffer of budget. Definitely not working with exact amounts.

The challenge here too - in order to win the project, everyone (including the client) will set the time for the development and thus the budget low. With the illusion that it will then be cheaper.

8) Missing documentation

Just like planning, software documentation is an area that nobody likes to deal with. Rather 100 lines of code, which is considered more productive, than “wasting time” documenting the code.

That's ok if you program a programmer on it for two or three days. The However, the reality is that after a few weeks or months even the programmer no longer knows what he was thinking when coding. The training, even for the developer who programmed it, takes a long time. Which is a challenge if you want to continue programming on the software.

It is, however, the case that it is not one developer who works on the software, rather a team of developers, and that the same developer will not deal with the code later and that it is not two three days of development work, but several man-years in many cases. Understanding such code is possible, but it takes forever. And nobody really wants to take the time to familiarize themselves with such legacy code.

Better: It is better to do appropriate code documentation in the code itself from the beginning, to make the code as readable as possible and also to create written documentation with the logic, where the code is also described (with screenshots) and the functionalities which are in the software happen (with screenshots). This is the only way to make software really maintainable and expandable.

Conclusion

Nowadays there are still infinite “code monsters”, software that is ancient and nobody knows what certain functionalities in the code are for.

Even the programmers themselves then wonder what their predecessors were thinking.

Even small changes to the software take a long time to develop.

This is good for service providers, because it means there is enough work, for example for the maintenance and expansion of legacy systems. However, the whole thing is not really efficient.

The reality, however, is that many successful software projects are almost impossible to maintain and you simply invest a lot of time and money in expanding them.

A real solution to the problem has not really been found yet. Because nobody (client, programmer, service provider, manager, etc.) wants to invest the necessary time in things like planning or documentation.

In your opinion, what are the most common challenges in IT projects?

Interesting posts:
Software development challenges and how to avoid them
Problems that can arise

Images: Canva


The author: Sascha Thattil works at YUHIRO and helps entrepreneurs and companies to easily set up programming teams in India. YUHIRO is a German-Indian company which provides IT companies, agencies and IT departments with software developers.

By Sascha Thattil on June 19, 2018 / Project Management, Software Development / Leave a comment