What are the worst programming jobs

Introduction of Coding Standards: Successfully Modernizing Software Projects - Part 3

With us, too, the assumption that developers are hopeless optimists and that the time required for a project is sometimes so poorly estimated that you have to add 100% to a realistic forecast has often been an issue.

The programmer and author John Sonmez adds another to the list of considerations with a recent blog post. According to him, are four main reasons responsible for the fact that developers' estimates are sometimes off by several factors:

Number 1: The "unknown unknowns"

If you follow Plato's epistemology, you are on the right track if you know that you know nothing, that is, you are in the realm of conscious ignorance.

Every software development process is full of imponderablesthat could be assigned to this area: Some unknown factors are emerging and can at least roughly be included in an estimate - Sonmez, for example, mentions the scenario that data must be stored in a database, but one is not yet clear about how you want to do it. So this would be one "Known unknowns"

However, sometimes you can too "Unknown unknown" appear, which to a certain extent throw everything upside down. Sonmez clarifies the relationship between “known unknowns” and “unknown unknowns” with the following picture: It makes a huge difference whether you know that a bridge to be crossed has a hole, or whether you have to cross it blindfolded and then the hole first then noticed when you fall for it.

Number 2: Long periods of time

Everyday experience already shows that short-term prognosis is usually much easier than long-term. The problem in software development is that estimates basically always relate to quite long periods of time - for example, not the writing of a unit test, but the completion of a feature.

However, the longer the period, the more factors such as the "unknown unknowns" already mentioned, or even small miscalculations, accumulate to form an ever larger mountain, which makes the original estimate increasingly inaccurate. Sonmez ‘experience has shown that these difficulties arise already for tasks that take longer than two hours.

Number 3: Exuberant (self) confidence

Some people are absolutely convinced that they are always in the longest line at the supermarket checkout. However, this is not the truth, instead it is a consequence selective perception: Only certain aspects of the environment are perceived and transferred to the memory, while others are ignored. In the case of software development, this would mean that you only remember those cases in which you were correct with your prognosis - and (unconsciously) suppress all others.

This phenomenon, taken together with the Overestimation of one's own abilities, often leads to the fact that as a developer you sit in front of a feature to be implemented and have to realize that the task is much more difficult than you initially assumed.

Number 4: Lack of (self) confidence

Just as too much confidence in one's own abilities can lead to an underestimation of the time required, a lack of confidence in one's own abilities can cause the exact opposite: An overestimation of the time required. This is particularly evident with new tasks: people tend to do tasks that they have to tackle for the first time as much more difficult to assess than they actually are. Frequently completed tasks, on the other hand, are assessed more easily than they actually are.

Even if an overestimation seems harmless at first, it can have negative consequences: Since people tend to have a Make full use of the available time window, in case of doubt, work is done much more slowly than one actually could, or there is simply dawdling. So lost time that would have been better spent elsewhere.

Do these things sound familiar to you? Would you suggest any others? Or is it all mercilessly exaggerated? Let us know what you think!

Lead image: Pretty young lady taking a decision with scale above her head by Shutterstock / Copyright: ra2studio