Version 1 is very bad, but it is still released

Address: http://www.codinghorror.com/blog/archives/001313.html

I am not satisfied with every software I have released. Because I am a perfectionist like many developers. There are some inevitable problems:

• The schedule is too tight. We need more time!
• We encountered unexpected technical problems and had to compromise.
• Our design has problems and we have to improve it during development.
• There is a conflict and friction between Members that we don't want to see.
• Customers are different from what we previously imagined.
• Communication between designers, developers, and project teams is not very effective.
• We are optimistic about the speed of learning new technologies.
• ...

The list will continue. The reason for the failure of the software project is as follows.

The end of the software development cycle is the glorious milestone you imagined at the beginning of a pale shadow software.

(At the end of the development cycle, you end up with software that is a pale shadow of the shining, glorous monument to software engineering that you envisioned when you started .)

At this point, it is easy for people to admit defeat-increase time to complete software development. Because, after all, the real developer release.

I tell you, this is an error.

Indeed, you have made many mistakes in the project. But at the same time, you have made many mistakes in areas you have not noticed. These errors can be discovered only when this version is released and before users and customers. I think what Donald Rumsfeld says is:

As we know,

Something you know,

Something we know,

We also know that,

What we know is unknown,

That is to say,

We know there are some things we don't know.

But there are some unknown,

There are some things we don't know. We don't know.

 

In the face of the inevitable Project's final blues-full of compromise and expediency-you can sit down and lick your wounds. You can reorganize the release (release) and fix it in a few months. You may feel good about yourself-This decision allows the world to lose a bug-filled software.

Unfortunately, this is worse than releasing a defective version.

Don't spend three months in a sterile, closed lab. You can spend three months listening to real-world user feedback. Software and users are not in your imagination, but in real life. You can turn around and take advantage of this. The real-world feedback not only fixes the worst of the first version, but also uses a user data base to make your development advance more effective.

Previously, I didn't say that you should release garbage. Believe me, we are all perfectionists. But the real world is cruel and heartless to perfectionist. Let it go, and when you find that your software crashes in the real world, disappointment is inevitable... but this can be repaired! The status of the initial software version is not that important-in fact, some people say that if you are not suffering from V1.0, you are not releasing it early enough-, what are you doing after the software is released?

The response and speed of your team's feedback to users determine the quality of your software, which is more important than any release. This is what you need to be good. It is not a perfect software for the pull scheme, but a response to your users, your customers, and continuous improvement of your software through their feedback. Therefore, if you are optimizing software release close to perfection, you are doing something wrong.

There is no doubt that you should release software as early as possible and then quickly iterate based on real-world feedback.

Believe me: Although version 1 is terrible, release it.