This is a story of "any resemblance to actual events or persons is purely coincidental," plus some nonsense. Please don't take it personally. Here we go...

I was holding a water cup, feeling a bit awkward. Sitting directly across from me was our visiting guest, President Wang. He had been making his way elsewhere and, in recent years, was said to have done quite well. Seeing how mobile internet was booming, he naturally wanted to get in on the action. Although President Wang's line of work was somewhat related to IT, he hadn't touched technology for so long that some things weren't familiar to him, so he always wanted to consult me—an old programmer who had spent over a decade in frontline development. Over ten years of development could mean several things, but that's not the point, so let's temporarily ignore that detail.

The reason I felt awkward was that I didn't quite know how to respond to President Wang's request, as if I had fallen into some kind of habitual contemplation.

President Wang stood up, handed his phone to me, and said, "Take a look, just an app like this." He swiped across the screen a few times somewhat clumsily. I didn't look very carefully, because I knew this question was tough—it's the kind every developer gets asked, and probably the most frequent one: "How long does it take to develop an app like this?" I really wanted to say "I don't know," which might be the most straightforward and accurate answer, but facing President Wang, an old friend, answering like that might be a bit rude. So at that moment, besides roughly thinking about what aspects the app he pointed to involved, I also had to organize my words to tell him politely that I couldn't estimate this. "You see, just such a simple app," President Wang continued, fiddling with the screen a few more times, then looked at me with some expectation in his eyes.

I said cautiously, "Frankly, I can't say for sure. I don't have much experience in this area either. Although I've done app development, it's very different from this. I'd have to analyze all the logic in detail before I could estimate the time."

President Wang seemed unimpressed by my words. He shook his phone and said, "I don't have many requirements; it's actually simpler than this." Pointing at certain places on the screen, he continued, "This, this, and this can all be removed. I just need a list like this, with details inside, where you can view and edit..."

Naturally, I thought this was a typical "assume it's simple" attitude. I figured I needed to make him realize the complexity of the problem, so I asked back, "Does it need login?"

After a brief pause, President Wang said, "Of course."

"What kind of login? Username and password, or phone login, or third-party login like QQ, Weibo, or WeChat that can be borrowed?"

This time President Wang seemed to think for a moment: "As a mobile internet thing, I think phone login is definitely needed. QQ, Weibo—oh, WeChat, WeChat is certainly needed too... Oh, you mentioned username and password earlier; that should be needed as well."

I smoothly continued asking, "Then you'll need registration. If you plan to use phone login, you'll need to find an SMS platform. For WeChat login, you need to complete enterprise identity verification first. Also, with login and password, you'll need a password recovery function, right?"

"That's for sure."

"With multiple login methods, you have to come up with a reasonable logic to 'integrate' them. The most common approach is, of course, account binding—for example, binding your account to a phone number so you can use the phone number to log into the same account. The same applies to WeChat login. But today's mobile internet users really dislike registration processes, so they often demand to log in directly with their phone or WeChat, and have the registration process completed automatically. Considering this situation, if a user first logs in with WeChat, then later logs in with their phone number instead of binding, that would create two different accounts that can't be 'integrated' anymore. We need to come up with a relatively complete solution..."

President Wang seemed somewhat impatient with what I said: "Does it really need to be this complicated? Look at this app—doesn't it already have all these things?"

"Did you try it to see whether the problem I described earlier exists?"

But President Wang didn't seem concerned about the problem. He only wanted to know how long it would take to build such an app, and of course how much it would cost—that was also something he cared about. He said in a confident tone, "What's there to fear from problems? What are difficulties? I believe they can all be solved. But time is critical; we need to move fast. Our competitors won't wait for us. It's just such a thing—think about it, how long will it take?"

Judging by his demeanor, he was exactly the kind of successful person who had made it big, and as a lowly programmer, I really had trouble speaking up in front of him. I had wanted to continue telling him how important the details were, but he interrupted: "No, it doesn't need to be that precise. Just estimate a range—two weeks? Or two months?"

I felt there was no need to hide anything anymore: "I really don't know. Maybe an excellent team could do it in two weeks, though I don't really believe such an amazing team exists, but I'm clearly not the one who could create such a miracle." I thought to myself that even a joking range like "two weeks to two years" might be wrong.

President Wang seemed very disappointed with my answer. But he is a person with strong execution ability—if he wants to do something, he will definitely take action, act quickly, and get results. I do admire that decisive style, but for his project, I really couldn't be of help. Still, out of politeness, I said, "If there are any technical issues, you can still come and ask me."

====================== A Not-So-Glamorous Separator ======================

"How long does it take to build an app?" This question is probably harder to answer than predicting how many days a person has left to live. How can you answer such a question with so little information?

Overall, the clearer the requirements and the more mature the team, the more accurate the time estimate. But software development—no matter how many years it evolves, no matter what methodologies are proposed—cannot have its "man-hours" calculated as precisely as in traditional manufacturing, because of the intricate logical relationships inside. Software engineering can never be mass-produced.

Users see only an app. If they use iOS, they might never come into contact with Android, and don't realize that besides an iOS version, developers also need to make an Android version, or could there also be a Windows version? That would undoubtedly mean even more work. Or maybe a web version can do everything? Perhaps you wouldn't think that way after actually building one. Besides, can a model like WeChat's mini-store really apply to all situations? Moreover, unless there's a network anomaly, ordinary users won't even notice the existence of servers. Servers always work silently for users around the clock, and their development difficulty is probably no less than that of the app itself. And maintaining the app requires manpower; once it grows larger, you may even need to form a professional team. They need a "backend" to view and process data at any time. If you need to view and process data anytime, anywhere, you might have to create a dedicated app for the backend.

This principle is somewhat similar: we see a fighter jet beautifully complete its mission of destroying enemies in the sky, and assume it's just because the fighter itself is impressive, often ignoring the supporting systems around it. Without skilled pilots, command centers, ground radar, early warning aircraft, supplies, airbases or aircraft carriers, ground crews, and so on, the fighter would lose its combat capability. The same goes for an app: it's not something that's done just because it runs. The supporting infrastructure and maintenance work are no less simple than the app itself.

Apart from these major aspects, there is also a lot of uncertainty in the details, which is why a mature team is especially important. An experienced developer will know—at least roughly—what problems will be encountered during development, which ones are simple, and which ones may take a lot of time. This depends on experience. I often say a phrase, which is:""Don't casually say something is simple if you've never done it before."The attitude of "assuming it's simple" does no good to a project. If you're not sure, go consult someone with experience in this area. Even if you don't get a specific answer, you'll at least get a general direction. Research along those directions, and you'll learn about the problems you'll face—though often still not all of them.

Regarding "underestimating the difficulty," there's a classic story from my previous company. At the time, there was a small project: we planned to add multi-language support to a program that was already running on instruments and only supported English. The program wasn't large, and the content involved wasn't too much either. The engineers initially thought it was just a simple translation task that could be completed in at most two weeks. But once they started, they found it wasn't simple at all. First, the translation had to be done by professionals; we couldn't do it well ourselves—none of us were proficient in European languages. Next came unit conversion: some countries use the metric system, some use imperial, so that had to be considered, including date display formats. Suddenly, there was no telling how much extra work had appeared. When these were mostly done, they discovered that German words were too long and couldn't fit on the instrument screens—they exceeded the display area. So they adjusted fonts and trimmed content, and held meetings to discuss N times back and forth. Finally, when they wanted to release, they found that with all these changes, the program's size had become much larger, and some instruments' storage couldn't hold it. At that point, everyone was dumbfounded. So they optimized and streamlined, and the program started to become a bit messy. In the end, they barely passed the quality control department's inspection and finally released it—only to realize it had taken a full six months. Thinking back now, an important reason it took so much time was a lack of experience; unfamiliarity with multi-language and internationalization led them down many wrong paths. So as I mentioned earlier, having a mature team is especially important.

When estimating project time, we often only count "the time spent writing code," leaving out the time spent arguing with bosses or clients, doing requirements analysis, design, testing, and fixing bugs. These times combined usually exceed the time spent writing code by a lot. Personally, I don't easily give a short completion time just to please my boss. Why? Because it simply can't be done—so why lie? If a new feature development requires one week, I usually double that time, and that's already relatively "non-conservative."

Even if you only count the time spent writing code, it's often underestimated. The boss or client may be unsatisfied with what you've developed—maybe you misunderstood his functional requirements, or the interface is laggy, or the icon color isn't pretty. You're a developer, not a graphic designer. Although you might pass as one in a pinch, you're not professional after all. More importantly, doing UI design and making images also takes a lot of time. When you're struggling desperately over "a single pixel," don't you long for a designer on the team? At such moments, you need to remind the boss: you have to make some trade-offs between time and features. The boss will certainly be unhappy, but he has no choice but to compromise on some features. Although this allows a troubled project to launch earlier, it also gives the boss a great excuse for the project's future failure: "Our engineers were too poor; they didn't do what I told them."

Besides complaining that what you've made isn't good-looking enough, bosses or clients will also bring up many other things: Can this interface be changed to multi-select? Can a notification feature be added? There should be read/unread status. Can the interface be a bit smoother? Why did the program "crash" once last night... The requirements just list features, but don't say how beautiful this UI should be, nor that program stability should be good, let alone what throughput needs to be reached. And of course—what might be more important—security isn't mentioned either. You're startled: right, if there were hackers—no, as long as a malicious user with even a little technical knowledge wanted to flood our server, it would be all too easy, and I haven't done any of these protective measures! Fortunately, the project is still too unknown, so no need to consider this for now. (It seems most apps never live to the point where they need to consider this.)

All these things—whether you call them features, details, or robustness—aren't things that can automatically grow from the soil; they all require time to think about and to do. Some are even a "systems engineering" job. If you treat the head when the head hurts and the foot when the foot hurts, the system will be full of "flying wires" everywhere, which will undoubtedly leave many hidden dangers for future maintenance. Have you, the engineer, considered all of them? Not to mention the "insignificant" matter of the low-performance computer the boss bought you to save costs, which drives you crazy all day long.

====================== Not-so-fancy divider line ======================

So after Boss Wang said goodbye to me, he registered a company with lightning speed, registered a domain name, secured an office, and even gathered a group of people and got things rolling in high gear. I could only feel I was no match for this momentum and drive. I did somewhat regret not pursuing a career with him, but that was only an emotional flash; rationality pulled me back within the next few hundred milliseconds: better not go—he and I just can't communicate.

Boss Wang's project later took off and developed rapidly, and today he is the CEO of a company valued at several hundred million. As for me, I increasingly feel like a loser, sitting alone in my office, still holding that water cup, full of chagrin—stop! Wouldn't that be more dramatic? But although I declared at the very beginning that "any resemblance in this story is purely coincidental," I can't just fabricate things. The real ending is: they did indeed hustle for a few months, then suddenly went completely silent. I originally wanted to call Boss Wang to ask what was going on, but unfortunately he had become another super-busy person with no interest in chatting with me. Well, the ending is still pretty much the same—I'm still the programmer who continues to sit in the office struggling. Sigh, stop thinking, let's get to work!

Source: http://www.cnblogs.com/guogangj/p/4676836.html