Free AI web copilot to create summaries, insights and extended knowledge, download it at here

Abstract

timated and takes longer than the initial estimate/plan.</p><p id="78d1">When you don’t have the complete requirements, it’s impossible to estimate how long it will take to create the software. <a href="https://javascript.plainenglish.io/software-projects-are-not-late-they-are-underestimated-fe35316ab1e8">Many projects are not late they are underestimated</a></p><p id="8ac2">What makes creating software a fool's paradise? What is it about software development where people believe it will be easy and get into a situation where.</p><h1 id="9f8e">Unregulated and non defined skill set</h1><p id="1322">Software development is unrelegated. There aren’t standard qualifications that other professions like doctors, dentists, architects, etc. need to get.</p><p id="48ce">In other industries like construction, there are rules and checks to follow rules and get approval.</p><p id="924a">Many industries have a method of regulatory to control the quality of the work done. Software, code and development have no regulatory body or any set standards to check the quality of work.</p><h2 id="f7af">Fast moving technology</h2><p id="345d">Technology moves too fast for official courses and for the lectures to be knowledgeable. At university, the technology studied was 5 years old (ancient in technology terms) or too shallow. There is limited value of overview knowledge in technology. It helps you know what it is but not how to use it.</p><p id="d33c">Technology is a skill and to build the skill you need to use the technology and build software. It’s possible to gain knowledge, but this is no guarantee you can use it effectively or successfully to create software.</p><p id="820d">There are certifications. These are useful to gauge the knowledge of a developer and it shows they have ambition, but it’s not guaranteed they can use that knowledge to create software. You cannot get a certificate for skills, only experience will give that.</p><p id="bae0">Which brings us back to the problem: <b>there are no set standards for creating software and there is no way to assess the skills of people assigned to create software.</b></p><p id="5027">There are no certificate, CV, knowledge or experience that you can use to effectively assess the quality of developers or other roles on the project.</p><p id="ab54">There are no best practices that can be used every time you create software. There are good practices you can use based on technology, experience, previous standards, skills. As in most things in development — it depends.</p><h1 id="23af">Incentives</h1><p id="8d43" type="7">“The iron rule of nature is: You get what you reward for. If you want ants to come, you put sugar on the floor.” Charlie Munger</p><p id="e70b">Most incentives on software projects are short term and sacrifice quality for faster creation of software. This creates an illusion of progress but leads to technical debt, lower-quality software, and problems later on.</p><ul><li>Cowboy developers want to get the work done as quickly as possible and who cares about quality</li><li>Managers want projects delivered fast and right now — who cares about quality</li><li>Customers, managers and leaders don’t understand software development and want software created as quickly as possible.</li></ul><p id="dcbf">To understand the decisions on a software, you need to understand the incentives for the key decision makers. In development, the decision makers are customers, managers, and leaders.</p><p id="d55f">The goal is to create software fast, and quality and long-term maintenance is not measured or rewarded.</p><p id="5616">This creates a fool's paradise and an environment where incentives encourage decisions that trade speed for quality.</p><h1 id="9e71">Estimating</h1><p id="1bb1">If

Options

people cared about the actual cost of creating software, they could just double the estimates or</p><ul><li>You could look at how long similar projects took and used that.</li><li>You could create three plans, optimistic, middle and worst case.</li></ul><p id="2227">No one wants the actual cost, no one is incentivised to estimate accurately. Everyone wants a low cost and to keep believing it can be delivered fast and for a cheap price. It's the same as the hope people used to buy a lottery ticket. If I win, it will be great.</p><p id="2b17">The software company who wins the contract usually bids the lowest and an auction drives the price down. This isn’t the price to do the work, but to win the project. This is the price to get the project started at this point. The incentive for everyone is to get the lowest price and time.</p><h1 id="96d6">Developers fool's paradise</h1><p id="cbbd"><a href="https://itnext.io/there-is-no-benefit-or-incentive-for-developers-to-create-quality-code-on-software-projects-a89aae0f8c35">There Is No Benefit or Incentive for Developers to Create Quality Code on Software Projects</a>. Leadership, management and project managers have the goal of creating software fast.</p><p id="06c3">The need for speed, lack of technical knowledge and difficultly assessing quality of developers and work are the perfect mix to create confusion.</p><p id="20ae">The measures on software projects are focused on fast creation. Developers are encouraged to create fast software not quality software. Technical debt and quality are difficult to measure and are not of interest to leadership.</p><p id="4083">If developers are rewarded the same for low-quality code as they are good quality code, then they will create low quality code because this is faster and takes less effort.</p><h1 id="7e1b">Paradise lost</h1><p id="5c6c">Never tell a fool that he is a fool. All you’ll have is an angry fool. — Talmud</p><p id="2a0d">Lots of people put their reputations on delivering the optimistic project plans and go into denial when it looks like it can’t be done.</p><p id="7508">They believe it will happen and deny it won’t right until the last deadline is missed. The reason they do this is they want the project to be delivered in that time so much that cannot face it not happening.</p><p id="2469">When development teams try to pop the bubble with realistic estimates, they are told to stop bringing a downer to the party.</p><p id="245e">This is the fool's paradise of projects ignoring reality and the actual cost or the actual time projects will take.</p><h1 id="b66b">Conclusion</h1><p id="27a0" type="7">The first principle is that you must not fool yourself and you are the easiest person to fool. Richard P. Feynman</p><p id="cca9">People have discovered that they can fool people with a plan, but you cannot fool a software development project.</p><p id="6dca">The difficulty in assessing the quality of developers and their work makes it difficult to get a firm understanding of what software is created or how to plan for the project.</p><p id="5d76">The decision makers have little understanding how software is created and resist advice from developers which say the project will take longer. A calculated risk is to hope the software is created on time and if not there will be valid reasons why it took longer.</p><p id="ddec">The low estimates and optimistic project plans get rewarded at the time and forgotten later. Delivering any software project is difficult and its a success to get software into production.</p><p id="a2f8">A developer may be a fool and not know it, but not if they have a manager and work on creating software. What we should always keep in the back of our mind is sometimes fools are right.</p></article></body>

Is Software Development a Fool’s Paradise?

or is software development a paradise for fools?

“The greatest lesson in life is to know that even fools are right sometimes.” ― Winston S. Churchill

Software development can feel like a group of intelligent people doing foolish things. The plans, reports, and activities around creating software seem to hinder as much as they help.

Software development failure rates or projects delivered late are fuzzy and unreliable. Like much of the reporting on software projects the plans and deadlines can watermelon reporting and created to confuse rather than communicate.

Software development can be a fool's paradise, where the developers know it will take longer (and cost more), but leadership doesn’t want to hear it.

A fool's paradise

The definition of living in a fools paradise

to be happy because you do not know or will not accept how bad a situation really is

Creating software and software projects are a fools paradise. Projects underestimating how difficult creating software is, simplifying the software which needs to be created.

Software projects cannot deliver optimistic plans and soon miss deadlines. Most projects fail to accept how bad the situation is or admit it’s harder and will take longer.

Why? Is it because we use so much software that we assume it will be easy to create or we see other projects creating software then we should be able to do?

The amount of failed or late software projects is a random number. The unusual element of software projects is what the software should do is only known at the end of the project. There is a lot of time wasted trying to measure how long it will take to create undefined software.

Software is emergent, requirements are discovered as the software is created. Trying to measure the progress of creating software is like estimating how long it takes to travel to unknown location.

Some statistics from this page — Project Management Statistics: Trends and Common Mistakes in 2022

70% of all projects fail.
42% of companies don’t understand the need or importance of project management.
55% of project managers cite budget overrun as a reason for project failure.

This page has different statistics

According to a survey by KPMG, an incredible 70% of organizations have suffered at least one project failure in the previous 12 months
50% said their projects had not accomplished what they set out to do.
The Chaos Report group found that only 29% of implementations of IT projects were successful
19% were considered complete failures.

What do I see from software projects I have worked on or seen/heard other developers working on? Everyone single project longer than 6 months is underestimated and takes longer than the initial estimate/plan.

When you don’t have the complete requirements, it’s impossible to estimate how long it will take to create the software. Many projects are not late they are underestimated

What makes creating software a fool's paradise? What is it about software development where people believe it will be easy and get into a situation where.

Unregulated and non defined skill set

Software development is unrelegated. There aren’t standard qualifications that other professions like doctors, dentists, architects, etc. need to get.

In other industries like construction, there are rules and checks to follow rules and get approval.

Many industries have a method of regulatory to control the quality of the work done. Software, code and development have no regulatory body or any set standards to check the quality of work.

Fast moving technology

Technology moves too fast for official courses and for the lectures to be knowledgeable. At university, the technology studied was 5 years old (ancient in technology terms) or too shallow. There is limited value of overview knowledge in technology. It helps you know what it is but not how to use it.

Technology is a skill and to build the skill you need to use the technology and build software. It’s possible to gain knowledge, but this is no guarantee you can use it effectively or successfully to create software.

There are certifications. These are useful to gauge the knowledge of a developer and it shows they have ambition, but it’s not guaranteed they can use that knowledge to create software. You cannot get a certificate for skills, only experience will give that.

Which brings us back to the problem: there are no set standards for creating software and there is no way to assess the skills of people assigned to create software.

There are no certificate, CV, knowledge or experience that you can use to effectively assess the quality of developers or other roles on the project.

There are no best practices that can be used every time you create software. There are good practices you can use based on technology, experience, previous standards, skills. As in most things in development — it depends.

Incentives

“The iron rule of nature is: You get what you reward for. If you want ants to come, you put sugar on the floor.” Charlie Munger

Most incentives on software projects are short term and sacrifice quality for faster creation of software. This creates an illusion of progress but leads to technical debt, lower-quality software, and problems later on.

Cowboy developers want to get the work done as quickly as possible and who cares about quality
Managers want projects delivered fast and right now — who cares about quality
Customers, managers and leaders don’t understand software development and want software created as quickly as possible.

To understand the decisions on a software, you need to understand the incentives for the key decision makers. In development, the decision makers are customers, managers, and leaders.

The goal is to create software fast, and quality and long-term maintenance is not measured or rewarded.

This creates a fool's paradise and an environment where incentives encourage decisions that trade speed for quality.

Estimating

If people cared about the actual cost of creating software, they could just double the estimates or

You could look at how long similar projects took and used that.
You could create three plans, optimistic, middle and worst case.

No one wants the actual cost, no one is incentivised to estimate accurately. Everyone wants a low cost and to keep believing it can be delivered fast and for a cheap price. It's the same as the hope people used to buy a lottery ticket. If I win, it will be great.

The software company who wins the contract usually bids the lowest and an auction drives the price down. This isn’t the price to do the work, but to win the project. This is the price to get the project started at this point. The incentive for everyone is to get the lowest price and time.

Developers fool's paradise

There Is No Benefit or Incentive for Developers to Create Quality Code on Software Projects. Leadership, management and project managers have the goal of creating software fast.

The need for speed, lack of technical knowledge and difficultly assessing quality of developers and work are the perfect mix to create confusion.

The measures on software projects are focused on fast creation. Developers are encouraged to create fast software not quality software. Technical debt and quality are difficult to measure and are not of interest to leadership.

If developers are rewarded the same for low-quality code as they are good quality code, then they will create low quality code because this is faster and takes less effort.

Paradise lost

Never tell a fool that he is a fool. All you’ll have is an angry fool. — Talmud

Lots of people put their reputations on delivering the optimistic project plans and go into denial when it looks like it can’t be done.

They believe it will happen and deny it won’t right until the last deadline is missed. The reason they do this is they want the project to be delivered in that time so much that cannot face it not happening.

When development teams try to pop the bubble with realistic estimates, they are told to stop bringing a downer to the party.

This is the fool's paradise of projects ignoring reality and the actual cost or the actual time projects will take.

Conclusion

The first principle is that you must not fool yourself and you are the easiest person to fool. Richard P. Feynman

People have discovered that they can fool people with a plan, but you cannot fool a software development project.

The difficulty in assessing the quality of developers and their work makes it difficult to get a firm understanding of what software is created or how to plan for the project.

The decision makers have little understanding how software is created and resist advice from developers which say the project will take longer. A calculated risk is to hope the software is created on time and if not there will be valid reasons why it took longer.

The low estimates and optimistic project plans get rewarded at the time and forgotten later. Delivering any software project is difficult and its a success to get software into production.

A developer may be a fool and not know it, but not if they have a manager and work on creating software. What we should always keep in the back of our mind is sometimes fools are right.