How long does it take to make an app like this?

[[142904]]

I was holding the water cup somewhat awkwardly. Opposite me sat Mr. Wang, who was visiting. He was working hard elsewhere and was said to have made a lot of money in the past few years. Seeing that the mobile Internet was in full swing, he naturally wanted to join in and try his hand. Although Mr. Wang's business was related to IT, he had not been exposed to technology for a long time and was not familiar with some things. He always had to consult me, an old programmer who had been in the front-line development for more than ten years. After more than ten years of development, there were several possibilities, but this is not the point, so let's ignore this detail for now.

The reason why I was embarrassed was that I didn't know how to respond to Mr. Wang's needs, as if I was lost in some habitual contemplation.

Mr. Wang stood up, handed the phone to me, and said, "Look, it's just an app." He swiped the screen a few times in an unskilled manner. I didn't look at it very seriously because I knew this question was difficult. It was a question that all developers would be asked, and it might be the most frequently asked question: "How long does it take to develop such an app?" I wanted to say I didn't know, which might be the most direct and accurate answer, but in front of Mr. Wang, an old friend, it would be a bit rude if I answered like this, so at this time, in addition to roughly thinking about what aspects the app he was referring to involved, I also had to organize my own language and tell him in a very decent way that I couldn't estimate this matter. "Look, it's just such a simple app," Mr. Wang continued to fiddle with the screen a few times, and then looked at me with a bit of expectation.

I said cautiously, "To be honest, I can't say for sure. I don't have much experience in this area. Although I have developed apps before, it is very different from this. I have to analyze all the logic in detail before I can estimate the time."

Mr. Wang seemed to disagree with what I said. He shook his phone and said, "I don't ask for much. It's actually simpler than this." He pointed to certain places on the screen and continued, "This, this, and this are all fine. All I need is a list like this with details that I can view and modify..."

I naturally thought that this was a typical "take it for granted" attitude, and I thought I had to make him realize the complexity of the problem, so I asked back: "Do I need to log in?"

Mr. Wang paused for a moment and said, "Of course."

"What kind of login? Username and password, mobile phone login, or third-party login like QQ, Weibo, WeChat?"

Mr. Wang seemed to think about it for a moment. "As a mobile internet, I think mobile phone login is definitely required. QQ, Weibo, yes, WeChat, WeChat is also required... Oh, you mentioned username and password before, this should also be required."

I continued to ask fluently: "Then there must be registration. If you plan to log in with your mobile phone, you have to find a text messaging platform and WeChat login. You have to do corporate identity authentication first. Oh, by the way, if there is a login and a password, there must be a password retrieval function as well."

"That's for sure."

"There are multiple ways to log in at the same time, and you have to come up with a reasonable logic to 'integrate' them. The most common one is of course account binding, such as binding your account to a mobile phone number, so that you can use the mobile phone number to log in to the same account. The same is true for WeChat login, but nowadays mobile Internet users are quite disgusted with the registration process, so they often require direct mobile phone login or WeChat login to automatically complete the registration process. Consider this situation, if the user logs in with WeChat first, and then logs in with the mobile phone, instead of binding, then two different accounts will be generated, and they cannot be 'integrated' again. We have to come up with a more complete solution..."

Mr. Wang seemed a little impatient with what I was saying: “It doesn’t have to be so complicated, does it? Look at this app, doesn’t it have all of these?”

"Have you tried the problem I described earlier?"

But Mr. Wang didn't seem to care about the problem. He just wanted to know how long it would take to make such an app. Of course, how much money it would cost, which was also what he cared about. He said confidently: "Why are there problems? What are the difficulties? I believe these can be solved, but time is very important. We have to be quick. Our competitors won't wait for us. Just think about it, how long will it take?"

He looked like a successful person who was doing well in his career. As a lowly programmer, I was speechless in front of him. I wanted to continue to tell him the importance of details, but he interrupted me: "No, it doesn't need to be precise. You just need to estimate a range. Two weeks? Or two months?"

I felt that there was no need to hide anything anymore: "I really don't know, maybe a good team can do it in two weeks (but I myself don't believe there is such a great team), but I am obviously not the one who can create such a miracle." I thought that even if I said a joking range like "two weeks to two years", it might be wrong.

Mr. Wang seemed disappointed with my answer. But he is a man with strong execution ability. If he wants to do something, he will take action, and he will take action quickly and produce results. I really admire his vigorous and resolute style of doing things. However, I really can't help him with this project, but I still said politely: "If you have any technical questions, you can still ask me."

====================== A not-so-gorgeous dividing line======================

"How long does it take to make an APP?" This question is probably more difficult than measuring how many days a person can live. How to answer a question with such insufficient conditions?

Generally speaking, the clearer the requirements and the more mature the team, the more accurate the estimated time will be. However, no matter how many years software development has been developed or what methodology has been proposed, it is impossible to calculate "working hours" as accurately as in traditional manufacturing. Due to the complex logical relationships within software development, software engineering cannot be mass-produced.

What users see is just an APP. If they use iOS system, they may not have any contact with Android. They may not know that in addition to iOS version, developers need to make an Android version (is there a Windows version? This will undoubtedly be more work) or a web version can handle everything? Maybe you will not think so after you actually do it. Besides, can the WeChat store model really be applied to all occasions? Moreover, if there is no abnormality in the network, ordinary users will not notice the existence of the server. The server always works silently for users around the clock. Its development difficulty is probably no less than the APP itself. The person responsible for the operation and maintenance of the APP also needs some manpower. When it grows up, it may even need to form a professional team. They need a "backstage" to view and process data at any time. If you need to view and process data anytime and anywhere, I am afraid you have to make a special APP for the backstage.

This is a bit similar: when we see a fighter jet brilliantly completing the mission of destroying the enemy in the sky, we think that it is only the fighter jet itself that is great, and often ignore the supporting facilities related to the fighter jet. If there are no skilled pilots, combat command centers, ground radars, early warning aircraft, supplies, airports or aircraft carriers, ground crews, etc., then the fighter jet will lose its combat effectiveness. The same is true for APP. It is not something that can be done as long as it can run. The supporting facilities and maintenance work are no simpler than the APP itself.

Apart from these major aspects, there are also many uncertainties in the details, so a mature team is particularly important. An experienced developer will know, at least roughly, what problems will be encountered in the development process, which problems are relatively simple, and which problems may take a lot of time, which depends on experience. I have a saying that I often say, which is: "Don't easily say that something is simple if you haven't done it before." The attitude of "taking it for granted to be simple" is of no benefit to the project. If you are not sure, then consult someone who has experience in this area. Even if you can't get a specific answer, you will have a general direction. If you study along these directions, you will know the problems you will face, of course, it is often not all.

Regarding the issue of "underestimating the difficulty", my previous company has a classic story. At that time, there was a small project, which was to add multi-language support to a set of English-only programs that were already used on instruments. The program was not large and the content involved was not too much. At first, the engineers thought it was just a simple translation job that could be completed in two weeks at most, but once they started working on it, they found it was not simple. First of all, the translation had to be done by professionals, and they couldn't do it themselves. None of us was proficient in the languages ​​of European countries. Then there was unit conversion. Some countries used the metric system, and some used the imperial system. This had to be considered, including the date display format. I didn't know how much more work there was all of a sudden. After all these were almost done, we found that the German words were too long and the screen of our instrument could not display them. It was out of range, so we adjusted the font and simplified it. We held meetings and discussed it N times. Finally, when we wanted to release it, we found that the size of the program had become much larger due to this change, and the memory of some instruments could not fit it. Everyone was dumbfounded. They optimized and streamlined it, and the program began to become a little messy. Finally, it barely passed the inspection of the quality control department and was finally released, and we found that it took half a year. But now I think that one of the important reasons why it took so much time was my lack of experience. I was unfamiliar with multiple languages ​​and internationalization, and I took a lot of detours. So as I mentioned before, a mature team is particularly important.

When we estimate the project time, we often only count the "time to write code" and ignore the time spent on arguing with the boss or the client, doing requirements analysis, design, testing, and fixing bugs. These times usually add up to a lot more than the time to write code. I personally don't easily say that the completion time is very short just to please the boss. Why? - It's impossible, why lie? If a new feature development takes a week to complete, I usually have to double this time, which is already considered "unconservative".

Even if you only count the time spent writing code, it is often underestimated. Your boss or client may not be satisfied with what you have developed. Maybe you misunderstood his functional requirements, or the interface is a bit stuck, or the color of the icon is not good-looking. You are a developer, not an artist. Although you can be an artist, you are not professional after all. More importantly, doing UI design and drawing things also take a lot of time. When you are worried about "one pixel", do you really want to have a designer in the team? At this time, you have to remind your boss: You have to make some trade-offs between time and function. Of course, the boss is very unhappy, but he has to make some compromises on the function. Although this can allow the difficult project to go online earlier, it gives the boss a good excuse for the failure of future projects: our engineers are too bad and did not do what I said.

In addition to complaining that your work is not good-looking enough, your boss or client will also mention many other things: Can this interface be changed to multiple choices, can a notification function be added, should there be read and unread status, can the interface be smoother, why did the program "crash back" last night... The requirements only mention the functions, but do not say how beautiful the UI should be, nor how stable the program should be, let alone how much throughput should be achieved. Of course, what may be more important - security is not mentioned either. You are shocked: Yes, if there are hackers, no, malicious users who know a little bit of technology want to blow up our servers, it is too easy, and I haven't taken these protective measures! Fortunately, the project is not well-known enough, so there is no need to consider this for the time being. (It seems that most apps don't live to the point where they need to consider this)

All these, whether it is function, detail or robustness, are not things that can grow automatically from the soil. You need to spend time thinking and doing them. Some of them are even "system engineering". If you treat the symptoms without addressing the root cause, the system will be full of "flying wires", which will undoubtedly leave many hidden dangers for future maintenance. Have you considered all these things, siege lion? Not to mention the low-performance computer purchased by your boss to save costs, which makes you crazy all day long.

====================== A not-so-gorgeous dividing line======================

After Mr. Wang said goodbye to me, he quickly registered a company, a domain name, and an office. He also called a group of people to start working in a hurry. With such a development momentum and enthusiasm, I can only sigh that I am not as good as him. Deep down, I really regretted not following him to start a business, but it was only an emotional moment. Reason pulled me back in the next few hundred milliseconds: It’s better not to go, I can’t communicate with him.

Mr. Wang's project later developed rapidly, and he is now the CEO of a company with a valuation of hundreds of millions. As for me, I feel more and more like a loser. I sit alone in the office, still holding that water cup, feeling annoyed - stop! Is this more dramatic? Although I stated at the beginning that "any similarities to this story are purely coincidental", I can't make it up randomly. The real ending is: it was indeed very busy for a few months, but then suddenly there was no news. I wanted to call Mr. Wang to ask how he was, but he became another super busy man and no longer had the heart to chat with me. Well, the ending is still similar. I am still the programmer who continues to sit in the office. Oh, don't think about it, let's get to work!