Enroll into QATUTOR Video Course on 

Coding: Part 1

Lecture 4 - The Software Development Life Cycle -> Quick Intro -> Idea -> Product Design -> Coding: Part 1 -> Coding: Part 2

In a nutshell, the programmer’s job is to translate ideas from the specs (or from other sources, like a brainstorming session during lunch) into the software code.

The translation can be made:

either directly (i.e., the programmer takes a spec and immediately starts coding (BAD idea)

or after creating the software design documentation. The software design documentation is a detailed technical description about how the spec requirements are going to be implemented into the software code (GOOD idea)

Two common types of software design documentation are:

– 1. System/Architecture Design Document.

– 2. Code Design Document.

An emerging culture of the creation and maintenance of software design documentation is the first sign that a start-up is converting from a bunch of dudes who write code into a serious software company.

Brain positioning

“There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

– C.A.R. Hoare, computer scientist

Let’s proceed.

In an ideal case, each developer has his own environment (i.e., software/hardware combo) with a certain version of the Web site. This is called the “development environment”, “development playground“, “playground” or “sandbox”. The architecture of the playground imitates the architecture of the production environment. Here is a typical architecture of the production environment of Web-based application:

– Web server

– Application core

– Database

Let’s take a quick look at how these components interact with each other.


ShareLane -> You can look inside each and every Python script mentioned below if you go to Test Portal>Application>Source Code.

You can see HTML code of any Web page if you click

– View>Source from the menu of Internet Explorer or

– View>Page Source from the menu of Firefox.

1. After the user enters https://www.sharelane.com into the address bar of the Web browser and presses the Web browser button “GO,” request to retrieve the default Web page of www.sharelane.com hits the Web server of sharelane.com, and in response the Web server sends this to the hard disk of the user:

– a text file index.html (https://www.sharelane.com/index.html), containing HTML code and

– an image file logo.jpg (https://www.sharelane.com/images/logo.jpg).


The first (default) page that a user sees after requesting the main Web site URL (e.g., “www.sharelane.com”) is called the homepage.


The communication between the Web browser and the Web server is based on the request/response protocol (set of rules) called HTTP (Hyper Text Transfer Protocol). The currents of HTTP-based requests and responses are called HTTP traffic (or simply “Web traffic”).

2. After the user clicks link “Enter”, HTTP request is sent to the Web server to launch Python script main.py (https://www.sharelane.com/cgi-bin/main.py).

Python script main.py belongs to the application core. That script generates HTML code that is sent to user’s hard disk via Web server.

3. After the user clicks link “Sign up”, HTTP request is sent to the Web server to launch Python script register.py (https://www.sharelane.com/cgi-bin/register.py).

Python script register.py also belongs to the application core. That script generates HTML code that is sent to user’s hard disk via Web server. HTML code generated by register.py includes Web form with text field “ZIP code” and button “Continue”.

4. After the user presses button “Continue”, form data (name of the field: zip_code and its value, i.e., user’s input into text field “ZIP code”) is passed through the Web server to register.py for processing.

5. If supplied ZIP code has correct format (5 digits), register.py generates HTML page with web form containing fields “First Name,” “Last Name,” “Email,” “Password,” “Confirm Password,” and a button “Register”. As we already know, that Web page is sent to user’s hard disk by the Web server.

6. After the user filled all fields, he presses button “Register” and request containing Web form data is passed through the Web server to register.py for processing.

Script register.py does processing and if everything is OK (e.g., email format is valid), it inserts new row into DB table users (Test Portal>DB>Data>users) and generates confirmation Web page about successful registration. As we already know, that confirmation Web page is sent to user’s hard disk by the Web server.

Brain positioning

The application core consists of files designed to:

– take input,

– process that input,

– deliver an output.


The term “application” (or “software application”) can be used in either a broad or a narrow sense.

– In the broad sense, it refers to the Web site in general.

– In the narrow sense, it refers to the concrete piece of software (e.g., Python script register.py).

We’ll use the term “application” in its broad sense.

Brain Positioning

The application core is the most sophisticated part of the software application.

Here is an analogy:

When I visit the fine cigar store:

1. I ask a salesperson to bring me a box of cigars.


3. IF AND WHEN MY AGE IS VERIFIED, I give the salesperson my credit card.





All CAPS represent actions connected to the processing of my order (application core).

Can I get the box without having the salesperson’s ears (interface) to receive an order? No.

Can I get the box without having that box in storage (database)? No.

Both the interface and the database are essential to our application, but again, the application core is the most sophisticated and logically charged part.

Programmers are primarily responsible for developing the code for the application core.*

*At start-ups the same programmers usually do it all: write code for the user interface and for the application core. Later, the company usually hires a special person, a UI developer, whose only focus is UI coding.

Later on that code will be given to us, the merciless testers, who know perfectly well all the main reasons why bugs appear in the software code:

a. Bad and/or changing specs

We just covered this.

b. Personality of developer

For example, a developer might be irresponsible, not caring, or just lazy.

c. Not enough programming experience

A developer can be a responsible person, but has no idea how to do programming right.

d. Neglecting coding standards

We’ll cover this next.

e. Complexity of the software

Many Internet projects are so complex that the brain of a mere mortal just cannot possibly predict all the consequences of the creation/modification/removal of a code.

f. Bugs in third party software

For example:

– bugs in operating systems;

– bugs in compilers and interpreters (the programs that translate software code written by humans into software code understandable by hardware; i.e., into 0’s and 1’s – we’ll cover this in a minute);

– bugs in Web servers;

– bugs in databases;

– bugs in software libraries.

g. The absence of unit testing

Unit testing is testing performed by the programmer himself. (The typical developer’s excuses: “Why should I look for bugs while we have testers?” and “I don’t have time.”). We’ll go over this.

h. Unrealistic time frames given to write code

We’ll go over this.

Below are the measures to help us enhance programming practices and prevent a substantial number of bugs:

1. Hire good people, and be prepared to give them a break.

2. Direct, fast, effective communication between coworkers.

3. Code inspections.

4. Coding standards.

5. Realistic schedules.

6. Availability of documentation.

7. Rules about unit testing.

8. “If it ain’t broke, don’t fix it.”

9. Being loved by the company.

10. Having “quality” and “happiness of users” as fundamental principles of the company philosophy.



Hiring is a hard process because an interviewer communicates with a candidate for a maybe an hour or less and afterwards has to make a decision about both that candidate’s technical skills and personal qualities. The simplest and very effective determination about a candidate’s personality is this: that person must be excited about your start-up. If he is not, don’t hire him. The reason is simple: The start-up environment is about a gang of passionate dreamers who are sincerely excited about their product and willing to sacrifice their talents, time and efforts for the company. You don’t need sour, unmotivated folks in your team. It’s better to hire a motivated passionate beginner with the shine of inspiration in his eyes rather than a highly skilled jerk who will later contaminate the start-up atmosphere with his negative attitude.

Here is another thing. A new programmer in the company often doesn’t have enough time to get up to speed. As a consequence, he can write buggy code and/or screw up code written by others. That’s why it does make sense to:

– give time and tutoring to new developers;

– give new developers easy projects to start with.


It’s very important to have this unwritten rule in any start-up:

“If you are asked for help, go ahead and help.”

Yes, there ARE situations when it’s not possible to interrupt your work; in this case, promise to get back to the person (and really get back!) or refer the person to someone else who can help. BUT in the majority of cases, it IS possible to spend several minutes with whoever asks you for help.


As a rule, a start-up is located in the same building and on the same floor, so in many cases people prefer to approach each other personally (rather than sending an email or instant message, or making a phone call). A very simple and effective way to notify others that you are busy and cannot respond NOW is to stretch some tape across entrance to your cubicle and attach to the tape a sheet of paper with these words: “Extremely busy. Email me.” It’s easy to do, but this can save a lot of time and concentration when you are working on something urgent.

Now, let’s talk about what happens if people just ignore help requests.


A programmer comes to the PM for an explanation about some part of the spec. The PM says: “Let’s do it tomorrow, okay?” Okay. What might happen after a couple of “Let’s do it tomorrows” without doing it tomorrow? Right! The programmer might start writing code even if he has doubts about the unexplained part of the spec. Needless to say, there is a good chance that code will not reflect what the PM tried to express.

Who is to blame in this situation? Actually, both the PM and the programmer.

The PM is to blame for failing to do his job properly.

The programmer is to blame because he:

– should have insisted on getting an answer from the PM;

– should not have done coding without a comprehensive understanding of the spec.

Here is a great quote from movie Ronin: “Either you’re part of the problem or you’re part of the solution – or you’re just part of the landscape.” So, let’s toast to being a part of the solution when we are asked for help!


A couple of other things about questions and answers:

– The programmer (like all other participants of the Cycle) should not be shy about asking questions (as many as needed!).

– In many cases it’s a good idea to confirm your understanding of a verbal answer by email; for example, “Hey Mike, I just wanted to double check that I understood correctly item 12.2. of spec #9571. What you said was: ‘<explanations from Mike>.'” Why send such an email?

1. You’ll show another party how you understood and digested information. If you didn’t correctly understand the explanations about the spec, then the PM must respond with corrections.

2. You’ll have an actual document (email message) to cover your ass, if needed. Actual email is much better as evidence than reference to some verbal blah-blah-blah. If you got the explanations about the spec wrong and sent an email asking for confirmation, but the PM didn’t correct you (or gave you wrong information), then the PM will be responsible for the consequent problems, not you.

Management must understand that it’s very important to help workers develop relationships with each other. One of the ways to do this is to have team-building activities. In my opinion, it’s much better to go hiking or play paintball once a month rather than get together every Friday and marinate everyone’s brains with alcohol. But, well, whatever works.

A technical aspect about communications is that each participant of the Cycle must be available for contact. Encourage everyone to publish their

– office, mobile, and home phone numbers

– work and personal email addresses

– instant messaging info

on the Wiki (you can find examples of these documents under Contacts in the Downloads section of qatutor.com).


It’s also very important to agree on a time (e.g., four hours during the day) when everyone (both those who left at 6 pm and those who left at 3 am) must be in the office. I think that the time frame from 2:00 pm to 6:00 pm is just right. By 2:00 pm

– You’ll be back from your lunch if you left at 6:00 pm previous day.

– You’ll be back in the office if you left at 3:00 am the same day.


Some programmers have this concept: “If I write code that only I can understand, then nobody will fire me.” WRONG!

First, anyone can be fired, including CEOs (thanks to corporate corruption in the U.S., we have many stories to illustrate this point).

Second, this approach is simply dishonest, because nobody forced you to work at the company; it was your decision to work there. So, if you agreed to work for the company, go ahead and do your best or leave if you don’t like it there*.

* If you are a consultant, then you usually have a specified period of time in your contract, i.e., three months, during which you must provide your services to the company. If you are an employee, then you’re usually expected to give two weeks notice before you can leave. Read all documents before signing!

To prevent “only-I-can-understand-my-code” behavior (which not only creates bugs, but also makes it harder to fix them), the company must have a practice for code inspections. This can be a weekly meeting when the manager of the programmers prints out the code of a random programmer and the latter explains his code to his colleagues. I doubt that the programmer would have an “only-I-can-understand-my-code” approach if he would most likely be asked at the meeting: “What the heck is wrong with your code, comrade?”


Code inspections have a great ally called “coding standards.”

Remember the story about building the Tower of Babylon, when everyone started to speak different languages? The consequences were really sad: people on earth got disconnected by a language barrier. So in order to communicate, we need to

– learn each other’s native tongue (very difficult if you have friends in many countries) and/or

– get a translator (costly and inconvenient for everyday use) and/or

– create some kind of standard (good idea!)

A similar mess like in Babylon happens at a software company if each programmer uses his own coding standard.


Let’s say that there is no naming convention (standard) for Python functions at our company.


– Matt likes to name his functions using this format: “credit_card” (using lower case for all letters and an underscore between words) while

– Anna likes to name her functions using this format: “CreditCard” (upper case for first letters of each word and no separator between words)


– it’s possible that Anna (remembering her habits, but not knowing Matt’s habits) would try to call Matt’s function “credit_card” as “CreditCard.” As a result, Anna’s code wouldn’t work, because Python doesn’t care about Matt, Anna, Babylon or our super-duper Web site, but it does care about the precise name of the function when that function is being called.

Coding standards can include:

– rules about comments

– naming conventions for classes, functions and variables

– rules about formatting

– and a HUGE PILE of other things

Needless to say, coding standards must be published on the company’s Wiki site, and every new developer must be referred to them. Coding standards must be adopted and followed in any software company that has more than one programmer. For a new company, it makes sense to start with a simple version of coding standards and then update them as the company grows.


When I was a child, my mother used to ask me to help her sort rice. As wild as it might sound nowadays, rice sold in the Soviet Union was not edible until you spent several hours sorting it before cooking. Even after I became quite proficient, there still was a speed limitation, after which I’d start missing things like little stones, so my family members would have to spit out my omissions during the dinner. Why am I bringing this up now? Every person has a limit, whether it’s about sorting rice or writing a software code.

If you create an unrealistic schedule, then either

– you won’t get what you wanted OR

– you’ll get what you wanted, but the result will most likely have poor quality.

This is exactly what often happens at software start-ups: developers are pressed to finish writing code in time, and while they do manage to produce the code on schedule, its quality might be really bad. Can we blame the developers? Of course not! We are all in the game called “start-up craziness” and unrealistic schedules are a part of our lives. Timing is everything, and we have to release our product and win users before our competitors do. That’s why the tester’s role in a start-up is critical – we allow the developers to move on to new projects while we are testing their OFTEN MESSY code. Like it or not, that’s the reality of start-up life.

The good news is that there are ways to ease up on the pressure of unrealistic schedules. One of the most effective solutions is this: before including spec into release, the engineering manager should ask the developer for a time estimate for coding that spec; i.e., how much time the developer thinks it will take to write the code. Having estimates from all the developers, the management can:

– rearrange projects between developers

– drop specs with less priority

– ask the PM to exclude some functionalities from the spec

Our only “hope” is that one day our start-up will become a big company, and everybody will be able to leave work at 6:00 pm. But, trust me, you’ll be missing those old good times when you were sleeping four hours a night but felt happy like never before!


ALL documents which are relevant to the Cycle, including the specs, spec change procedures, coding standards, test suites, etc.:

– MUST be available on the Intranet (e.g., by using Wiki)

– MUST be optimized for easy searching and browsing

It sounds simple and obvious, but if you don’t think about it, others will have to waste time and effort to access your documents.


Unit testing is a test performed by the programmer against his own freshly baked code. I must stress two points here:

1. It’s very important to correctly create and introduce rules about unit testing. If you do it wrong, the developers will be really annoyed, because they are not paid for testing – we, the testers, are.

2. If we don’t have concrete rules about unit testing, then the cost of the bugs will be increased.

Brain Positioning

The term “cost of the bug” has two meanings:

Meaning Number One: Expenses required to find the bug and fix it BEFORE the product’s release – these expenses can be calculated.

Meaning Number Two: Damage to the business (plus the expenses required to fix the bug), because the bug was found AFTER the product’s release – as a rule, it’s extremely hard to calculate the exact monetary amount of the damage to the business

Meaning Number One:

If the bug was imbedded in the spec and the code was written with the bug, but the bug was discovered by the testers, the bug’s cost can be* calculated like this:

Cost1: Hourly pay** of PM(s) multiplied by number of hours spent on buggy part of the spec


Cost2: Hourly pay of the programmer(s) multiplied by number of hours spent coding buggy part of the spec


Cost3: Hourly pay of tester(s) multiplied by number of hours spent for test preparations (e.g., test case creation) and testing of buggy code


Cost4: Similarly calculated costs of spec fixing, bug fixing, test case creation/modification, and testing of the fix


Cost5: Other possible expenses, e.g., expenses that might occur if release date slips

* This is a situation where the spec bug was due to wrong instructions in the spec. If the bug is due to an omission in the spec, then that bug’s cost is calculated differently.

** The hourly pay of a consultant is usually specified in the contract; the hourly pay of a salaried employee is calculated as a total pretax salary per a given period of time divided by the number of hours during that period.

As you can see, it’s possible to approximately calculate cost of a bug found before a product’s release.

There are three important conclusions here:

1. The earlier bug is found, the cheaper it is for the company. This is the main conclusion.

2. The quality of the PM’s work is critical because it takes place before coding and testing. In our example, if the spec had been bug-free, then Cost1 to Cost5 (inclusively) would not have occurred.

3. It’s good to find bugs before the release, but it’s much better and cheaper for the company if bugs are PREVENTED from happening in the first place. That’s why we spend so much time talking about QA – i.e., about ways to prevent bugs.

Meaning Number Two:

If the spec bug wasn’t found before the release, then the bug cost is calculated like this*:

Damage1: Cost1 to Cost5 (inclusively) from Meaning Number One


Damage2: Time spent by customer support to calm down angry users

Damage3: Monetary compensation to users and business partners

Damage4: Loss of profits

Damage5: Law suits against the company

Damage6: Forever lost users and business partners

Damage7: Miscellaneous other negative consequences

* This is just an example. In each case, the damages can vary from fifteen minutes spent by company workers to fix, test, and release the bug fix to an extreme situation where the company’s business is completely ruined.

As you can see, it’s really hard to calculate an exact cost of a bug released to users.

Please understand that we are not playing games here. Here is a quote from Wikipedia: “A study conducted by National Institute of Standards and Technology (NIST) in 2002 reports that software bugs cost the U.S. economy $59.5 billion annually. More than a third of this cost could be avoided if better software testing was performed.

The very important conclusion here is that software companies MUST regard QA and testing as SELF-PRESERVATION mechanisms.

Let’s get back to unit testing. Here are two recommendations:

1. In the case of more or less complex/time consuming projects, e.g., a project dealing with important architectural changes with an estimated coding time of 5 or more days, unit tests should be created BEFORE the code is written. Then, when the programmer gets a new spec for coding, he doesn’t rush in to start coding, but first creates the code design document and the unit test document.

Please note that “document” does NOT mean some multipage, highly formalized document ready to be printed in the Journal of Computer Science. After all, in the start-up phase, timing is everything, so both the code design and the unit test documents can be short memos. However, the programmer must make sure that those memos are:

a. published on the Wiki;

b. easily understood by others.

The beauty of this approach is this:

First, when the programmer abstracts himself from hands-on code writing, he has more intellectual resources to think about the “big picture”. This way the programmer gives himself a chance to predict – and hence prevent – mistakes in the future code.

Second, the programmer will have to imagine HOW he will test his code, and that “HOW” will stick in his brain like a splinter. This way, the programmer will have a “quality guard” in his brain to monitor programming activities and thus prevent and catch bugs.

Brain Positioning

Often it’s boring and laborious to create documentation, and the programmer is tempted to start programming right away without planning. But, IMHO, the main attribute of a real professional is doing what’s right. So, if it’s required by the situation, the company standard, or a verbal agreement to create documentation, that documentation must be created, and it must be created properly.

2. Requirements about unit testing must be formalized in Unit Test Standards. For example, there should be at least one test case for each Python function.


Every software engineer knows about cases where a perfectly working code becomes a nightmare after some “I-can-do-it-better” type of developer tries to improve it.

The problem that I’m referring to usually happens when a major chunk of the code is written and released; users are enjoying our product, and we can relax a bit from the craziness of the early start-up days. Some “I-can-do-it-better” type of developer (or any developer asked to do so by his manager) looks back at the old working code, finds room for improvement, and implements that improvement. And here come the problems!


My friend John and I have just finished the testing of new functionalities and are going to spend two days testing old functionalities (this kind of testing is called regression testing). We’ve executed test cases for regression testing many times for previous releases and usually discover very few bugs. We start testing, and ten minutes later we simultaneously shout: “WHAT THE HECK IS GOING ON?” The reason for this behavior is that the state of our old functionalities reminds us of the state of a fine porcelain shop right after an elephant’s visit – everything is broken!

After more investigation, we find out that there was a cute little project to rewrite several pieces of old code with the purpose of “purifying the breed.” Well, better luck next time. This time, our application is screwed up, and thanks to the regression testing we have uncovered serious issues before releasing that ugly code to our users.

You might be surprised, but situations like the above happen in software companies over and over again. And all because some folks cannot comprehend programming wisdom as old as the world: “IF IT AIN’T BROKE, DON’T FIX IT.”

So why should programmers think twice before changing an old code just to beautify it? The reason is simple:

The old code is usually part of the software foundation in which many pieces of old code and newer code have been heavily integrated, thus creating a complex net of dependencies.

So, when we shake this foundation, as a rule we simply cannot predict which part of the application is going to be affected. That’s why even a simple change in the old working code can have major negative consequences in totally unexpected parts of the software. This kind of effect is called “unintended consequences.”

Unintended consequences during a code change are the major reason we need regression testing.

So, remember that it is usually a very BAD idea to change working code just to improve it. Simply put: “IF IT AIN’T BROKE, DON’T FIX IT.”


It’s really simple. Management should take care of people. Start-up employees are heroes, spending day and night at the office, working on their shared dream to create a super product and get rich. Management should reward them for their hard labor and dedication. Is it too much for the company to give a $100 gift certificate or an extra thousand stock options to the employee who finished some amazing project? Or is it really all that expensive to buy lunches for the employees at least once a week?

It’s human nature to get discouraged when work is not appreciated. I’m amazed that so many managers don’t understand this simple truth. Again and again, I hear stories about unfair financial treatment and the absence of financial encouragement. Who suffers because of it? Everybody in particular, and the business as a whole!

On the opposite end, companies where employees are treated fairly and encouraged to go above and beyond have MUCH more chances of creating a great product.

For a while I worked at the Plug and Play building in Sunnyvale, California. This is an incubator for new companies, with lot of software-related conferences taking place there. The tradition is that the speaker writes something on the wall on the first floor. What do you think one of Google’s managers wrote? “It’s all about the people.”

Yep, without this kind of attitude Google would have been a smart search algorithm, nothing more. But because founders Sergey Brin and Larry Page built their company on the principle “It’s all about the people”, Google is the most successful company in the history of software development. Let me list some of the things available to Google employees at Google’s Mountain View, California campus. Most of these things are FREE:

– 11 gourmet cafeterias,

– laundry,

– dry cleaning,

– oil change,

– car wash,

– gym,

– exercise classes,

– massage,

– Mandarin, Japanese, Spanish, and French classes,

– personal concierge to arrange dinner reservations,

– hairstylist,

– $5,000 toward environmentally friendly car,

– $500 in takeout food for new parents for first month at home,

– five on-site doctors,

– Wi-Fi-enabled shuttles from five Bay Area locations,

– breast pumps for nursing moms,

– heated toilet seats (!),

– requirement to spend 20% of work time for dream projects.

Source CNN Money, 01/05/2007

I forgot to mention that ALL pre-IPO employees of Google became millionaires, and several hundred thousand dollars is a possible bonus for a successful project.

I could go on and on about Google. Now you understand what I’m talking about when I praise Google as an employer that LOVES its employees!

I realize that Google is a rich public company, and start-ups don’t have such huge material resources. But think about this: each big company was once a start-up, and as we know, big companies very often suck as employers. So why is Google both a huge company and a great employer? Because both in Google’s start-up years and now, it’s always been all about the people.

Here’s what any start-up can do, even without Google’s resources:

– pay bonuses for successful projects; even $1000 is better than a moneyless “Amazing job, man!”

– provide free lunches

– provide free soda and bottled water

– provide free snacks

– reward with gift certificates or concert tickets

– give Christmas gifts like jackets with the company logo

– organize paintball parties, hiking, or rafting trips

– give promotions

– pay for memberships to a nearby gym

There are many options, and every dollar spent on employees can turn into hundreds of dollars, because people are basically good and we DO work better in exchange for management taking better care of us.


Management must make sure that everyone at the company understands that “quality” and “happiness of users” are not just abstract concepts but rather the way to success for the company, and hence a way to personal success for everyone who works for the company. If managers make fun of quality measures and make jokes about users (even during an informal chat!), it does real harm to the internal morale of the company, and in the end there will be negative consequences for the company as a whole and hence for those idiots-humorists in particular.

Users know whether or not they are respected after a single error message, email from the company, or call to customer support. And if the real philosophy inside the company is, “Our users are stupid,” then that philosophy will sooner or later be evident to users. Of course, this will be great news for that company’s competitors.

Our users are real people. They should not be perceived as a faceless crowd, but rather as friends who trust us and appreciate our hard work. Next ->

Lecture 4 - The Software Development Life Cycle -> Quick Intro -> Idea -> Product Design -> Coding: Part 1 -> Coding: Part 2