"Hi, Amigo!"

"Hi, Bilaabo!"

"Today I'm going to tell you about how programs are usually developed."

"In the 20th century, when modern IT was in its infancy, everyone seemed to think that programming was like construction or manufacturing."

"Things usually went something like this:"

"The customer would explain the type of program that he needed — what it should do and how it should do it."

"Business analysts would listen to him and make a complete list of program requirements based on what he said."

"Then project managers would divide these requirements into tasks, and would also determine which programmer would do what task and in what order."

"Then the programmers would get to work. Sometimes they would work several years(!)."

"When they were finished, the program was given to testers."

"The testers would go through each of the program's requirements to verify that they were implemented and that the program worked as it was supposed to."

"If something went wrong, the testers would log the bugs and send them to the programmers."

"Then the programmers would fix the bugs and send the fixed program back to the testers. And the cycle would repeat."

"When the main bugs were fixed, the program was given to the customer."

"That's really how things went?"

"Well, of course, I've simplified a lot, but that's pretty close to how things were done."

"And a project could really take a year and a half to two years to complete?"

"Sometimes if a project's development was really long, they would break it into separate releases. Every 3-6 months, developers had to create a specific part of the program’s functionality, test it, fix all of its bugs, and show it to the customer."

"First off, so that he could share his impressions. And second, and more importantly, so that he would keep paying for the program's development."

"Keep paying?"

"Back then, development often took 2-3 times longer than planned. And because programmers were often paid hourly, the program became 2-3 times more expensive. What's more, the benefits were also reduced. After all, what the customer wants today for $100,000 may not be needed in 3 years — especially at three times the price."

"Did customers often refuse to pay?"

"Yep. They later started adding penalties to the contract, but this didn't improve the situation. Software development dragged on and on. And no one could do anything about it even if they wanted to."

"But why?"

"Well, first, too little is known during the planning stage. More often than not, at the beginning, no one could predict the problems that the programmers would face."

"But experienced programmers should have been able to foresee everything, right?"

"Can you see that programming is a unique profession."

"An ordinary worker frequently performs the same job over and over again. Watchmakers make watches, cooks cook, teachers teach, doctors treat, etc."

"Each of these professionals does basically the same thing day in and day out. As a result, they start getting better and better at their jobs."

"In programming, the approach is different. As soon as a programmer faces the same task every day, he writes a function, module, or program to perform it, and never comes back to it again."

"Each programmer usually solves each task once in his or her lifetime."

"Something like scientists or design engineers who invent things."

"Ah. Well, what's the most important role in a project?"

"Hmm, how should I answer that. It's easy to say which is the most important, but identifying the least important is difficult."

"The primary job of a tester (Quality Assurance, QA) is to monitor a program's status and report bugs promptly. The more and earlier a tester finds bugs, the more that can be fixed. A good tester influences product quality more than a good programmer does."

"Why can't programmer test their own programs. After all, don't they know better than testers what does and doesn't work?"

"A good programmer is simply incapable of being a good tester. A programmer knows how the program works really well, so he or she always uses it in a certain way. As opposed to ordinary users who use the program however they'd like."

"Additionally, testers don't test what doesn't work yet. The tester tests the functionality or parts of the program that the programmer says are already working almost perfectly."

"And when the tester finds tons of bugs in that functionality, and the programmer fixes them, then the product actually gets closer to perfection."

"The primary task of a programmer (Software Developer Engineer, DeveloperSDE) is to implement new functionality. Or, put more simply, to perform the tasks assigned to him or her. When programmers are assigned tasks with new features, they perform them. When they are assigned bugs, they fix bugs."

"But sometimes there are more challenging tasks, for example, come up with the architecture for the program or parts of it. The better the proposed architecture, the easier it will be to get things done in the future."

"The problem is that the architecture needs to be chosen at the very beginning, but it's not until you're in the middle of development that it's clear whether you chose the right architecture."

"Additionally, if the architecture is successful and the program turns out great, then the customer will probably want to use it as the basis for new versions of the program."

"Here's what I'm getting at."

"Whatever architecture you choose, there will always be a bunch of changes, additions, and new features that the architecture doesn't account for."

"Here's a good example."

"A customer asks you to build a 5-story building, so you design an architecture and build the house."

"Then the customer asks to add another story, and then another, and so on."

"But the first floor's walls weren't designed for that much weight, and neither was the foundation. So everything has to be redone."

"But after the 5-story building is done, what if the customer immediately decides he wants a 50-story building?"

"It would be easier to demolish the existing structure and rebuild everything from scratch…"

"But I have one piece of advice for you regarding architecture."

"An application's architecture must, first and foremost, be flexible, which means you won't have to start from scratch if you decide to redo half of the application. This type of architecture is usually called flexible and modular."

"The project manager's primary job is to make decisions. The project manager is the one who sees the big picture and makes decisions based on that perspective."

"Suppose that during development it becomes clear that a certain task won't be completed as planned. The project manager can then:"

"a) try to negotiate with the customer to modify the task"

"b) allocate more time to the task"

"c) bring in more experienced programmers from other projects."

"And there are many other possibilities."

"Each option requires you to sacrifice something, and the manager's job is to minimize the total losses from these sacrifices."

"For example, suppose competitors steal the lead programmer by offering him twice as much money."

"The project manager can:"

"a) do nothing. The programmer will leave, and the project will likely fall behind and incur penalties."

"b) double his salary. Then everyone else on the team will also want raises. If you give all of them more money, then the project's costs will increase and it might become unprofitable."

"c) some other option that you think up."

"I see."

"With a bad project manager, a good team usually lengthens a project, but not always."

"A good manager with a team of average programmers will almost always complete a project faster than a bad manager with a team of excellent programmers."

"I see."

"Okay, let's take a short break, and then we'll continue."