Testing, Delivery, and Confidence

I’m often asked regarding how likely a code deployment will deliver the expected results. It’s actually a very simplistic formula, the answer is a neutral answer, but people often think of it as either over positive, or over negative, more frequently the later.

Chance of delivering on time is a function of: testing, how recent the tests are, how close the test matches the production system, and the points of failure.

Obviously, by on time, we’re assuming we’re delivering the functionality the client expected to have by a certain date.

A delivery that has no testing, server systems are widely different, and there are many points of failure, have little chance of being a successful one, doesn’t mean it can’t happen. A delivery that has testing, matching server configurations, and little to no points of failure, has a huge chance of being a successful one, but doesn’t it’s guaranteed.

I know I speak for a few, possibly not for all, but developers wouldn’t feel comfortable with the deploy until it’s been released onto production, stress tested by the public, performed as expected, and then, their hearts are finally at ease. This, is also a form of testing, the final one. Even then, in the back of their minds, they’re thinking that the code could’ve been better, there are edge cases it didn’t cover, and so on. We are forever doomed by a feeling of insecurity, the only thing we can say is that we’ve rigorously tested the crap out of it because, fact of the matter, bugs are a fact of life.

Responsive Design: Fixing misconceptions

I’m exposed to more of the web than most people, not only on the usage front, but also from the development front. A lot of people employ a technique called “word salad”. Roughly, the spout a bunch of words, and pray that they have some sort of meaningful connotation.

One of these words is “responsive design”. Truthfully, “responsive design” meaning should be closest to “fluid design”, which is to develop a site that look “right” on different browser sizes and resolution.

One interpretation of responsive design seems to be, develop a webpage, that if the user switches from desktop, to tablet, to mobile, things will look the same, and the user will have the same experience.

That interpretation is absolutely wrong. If anything, the better statement would be mobile-tablet-desktop-friendly-architecture-with-relevant-designs. Fact of the matter, if you’re website is image intensive, 5 megabytes of image intensive, even if you employed the most advance fluid layout techniques, it WILL NOT be a good mobile device experience.

The main thing to take into consideration is bandwidth. Most likely the user is viewing the site using a 3G, 4G connection, and even then, not everyone has access to 25+ mbps wifi line.

Instead of creating one design that will magically work for all 3, I say design 3 versions that are designed for a specific experience. If you design for desktop, tablet and mobile miss out. If you design for mobile, the tablet and pc version is lacking. If you design for tablet, you’re kind of stuck in the middle, with a mobile device that has a slow experience, and a desktop version that has an underwhelming experience, since it could’ve been so much more.

I think if possible, we should stick to the terms “mobile design”, “tablet design”, and “desktop design”, and the “responsive” versions of each. If the web would adopt this, I’m sure a lot of people who do work in the web will be saved a lot of headaches, where requirements just seem to crawl out of nowhere, rendering existing architectures less effective at the very last stages of development.

Happiness Ladder

In my limited perception of the world, I find it interesting. The workers are always looking up at their boss thinking, man, he’s made it. The boss is looking at his boss, and concluding the same thing. For the most part, unless you’re at the very top of the chain, you’re still looking up. Even at the top, you might be looking towards the past for inspiration, comparing yourself to historic figures.

It might sound obvious, but if you were to compare yourself to the people less fortunate than you, you are much better off, but if you compare yourself to a person ahead of you, you feel far behind.

I just think it’s important to realize that as long as your basic needs are covered, everything else is just a plus. It’s important to be content with what you have, but desire upward mobility simply for the sake as a challenge to yourself. It’s not a goal you must met, but a goal you can entertain yourself with. Much like playing a game, that you may or may not win. Sometimes, it’s not winning that’s important, it’s the experience of the game.

The Ten Commandments of Project Management

Following at least these 10 commandments will be a big step towards becoming a well-respected, trusted, and optimal project manager:

  1. Always treat the person that’s working with you with respect.
  2. Always assume that your team is working as hard as they can, as fast as they can, and as well as they can.
  3. Always ask how long things are going to take, never assume.
  4. Code WILL break, it’s just a matter of WHEN.
  5. Describe tasks so even a person who’s never been on the project can figure it out.
  6. Angry, sad, and annoyed team members are non-optimal team members.
  7. The larger the project, the longer the estimate, the more likely it is for the estimate to be wrong.
  8. Anger is a sign of losing control, and not a sign of assertiveness.
  9. Let your team do what they do best, remove obstacles that can get in their way, provide support whenever possible.
  10. Always recount the things your team members did, and thank for the efforts it took to get it done.

There’s more to management than numbers. There’s more to communicate than words. There’s more to life than just work. A project manager is a person placed in a very important role, a bad PM can spell the death of an entire project, a good PM can be at the heart of it’s success. Learn the strengths and weaknesses of your team, and learn to harness their strengths, and try to reinforce their weakness. You catch more bees with honey than vinegar. A happy team is an efficient team, and you’re often times that’s exactly what you want.

Invest in Your Business: Time is Money

Everybody knows time is money, but it seems to be a very important concept that seems to escape a lot of developers’ mind as we strive towards code utopia. One of the strengths of developers as Larry Wall, the father of Perl, has put it, is laziness. We’re willing to go through great distances to save time in the long run. We invest into infrastructure so that we can benefit from it in the future. This causes us to obsess over frameworks, languages, plugins, coding standards, documentation, and so on.

One key thing to remember as a programmer is: “time is money”. The ultimate law of an employee is that you must bring in, in one form or another, more money than you cost. If that’s not the case, the company can quickly go out of business, or you become a burden on the resources and less of an asset. Sometimes, as a developer, we need to take a step back, and think “What does business what? What does business need? What WILL they need? How are the investments I’m making going to further that?” Often times, the code infrastructure investment doesn’t.

For example, if we decide to port the javascript over from one js library onto the next, and it cost the entire development team a couple of weeks to port, a week to test, and another week to put out all the fires that occurred because of the port. To developers, they might think, “Yes! Now everything is on a more modern javascript framework, we might get more cool stuff for free from now on, or it’s less likely to break. We can do javascript faster now!”

From the business standpoint, “We just lost a month worth of development time, and ALL these bugs just came out of nowhere! Our competitors just launched X! We need to gain ground!”

As developers, we need to understand that we’re playing a support role, a significant support role, but a support role nonetheless. We need to be more of an asset and less of a liability. We’re helping to keep a ship sailing. When we make our time investments we need to not only make it from our the perspective of making developers lives easier, but also whether or not that type of investment is even an option for the business. As a developer we are often times protected against all the business craziness so we can focus on our work, but at the same time, I do believe that exposure to such business requirements can help us better align how we use our time a bit more appropriately. At the end of the day, if the ship sinks, what good are all those technology investments we made?

Facebook’s Phone Number Search

Like everything Facebook, the new search feature is cool, creepy, and easily abused.

Have Just A Phone Number? iOS 6 Facebook Integration Can Fill In The Blanks [Corrected]

Even though I like the feature, I think it’s a feature that Facebook is ultimately better off not having. Given the elevated status of Facebook, a lot of information now can be tied to a person’s Facebook account. A number’s just a number, but if you can tie that number to a Facebook account. Then it means that people can use the number to figure out your Facebook, then they can figure out all the things you like, then they can figure out what to nag you about. Not only that, but if you have a land-line, they can tie the number to where you LIVE.

Imagine that? Before, you were a nameless entry on the white pages, now some guy knows exactly what you look like, and where you live. What can go wrong?

TONS!

That being said, if they’re going to be adamant about it, I can probably build a big-data platform around it, and sell it to ad-networks. If any lawyers want to patent this for me, I’m more than willing to give you a fair share if you do it for me, and then hand me the rights. I’ll do the coding 😉

Project creation, specification, and sizing

There are couple things that every single developer needs to know in a project:

1. How it looks
2. How it functions

To figure out how to code something, I generally one, talk to the “client” and figure out what they want. In this process it’s very important to figure out what the client wants it to do. This is where we gather a feature list.

Then, we map out these features, figuring out what actions are necessary for users to get to the desired page. Mapping out which sections users click on, where they’re placed, and etc. This will generate a wire frame. It’s also at this stage that you break down each overall functionality of the site into the various relevant sections. The output of this stage should be one: a diagram with very generic depictions of interfaces, resulting pages from user actions, and a list of functionality and more specifically the logic for the functionality.

The wire frame will enable both the designer, and developer to work in parallel, since they both have a basic idea of how everything will flow. Hopefully, by this stage, you have a good grasp of the functionality.

The designer takes the wire frame, logic, and specifications, and generates a mock.

Development

There are 3 classification of development:
1. HTML/CSS
2. Frontend
3. Backend

1. HTML and CSS controls the way it looks.
2. Frontend development generally involve the javascript, and various controllers
3. Backend development will involve the database, business logic and etc.

Of course, this can all fall under the broad umbrella of development, but the main reason why I broke it down is due to the fact that the work can be broken down, so that multiple hands can work on it at once. That being said, the more hands on deck, the more overhead is generally involved.

So we’ve covered how to create a project, and how to specify the project. With the specifications listed, now it’s possible to come up with accurate estimates, or size the project. Everything can be estimated and delivered. The person who dreamed up the project is responsible for listing out the ideas and how it’s going to work. Together with a UI person, he can then work out and deliver the wire frames. Then the business person, and the designer can get together and design out how all the pages will look, delivering the mocks. Finally when the mocks are delivered, they can be handed off to the developers, and the developers will be able to code everything. The better a job the business person does at being specific, the less likely he’ll be pestered by developers to clarify the business logic. Essentially, having the project broken down into these sections will allow the estimates to be much more accurate. The more complex the business logic, the more complex the code, and most likely, the more man hours it’ll take to code it.

MVP Minimum Viable Product

Most Valuable Player? That’s what I originally thought, but in the start-up space, it means “Minimum Viable Product”. The LEAST you can do, to get your product to market.

The concept behind MVP is to test and collect data as soon as possible, saving time and resources. To construct a MVP, what you need to do is dream up your product, and the trim the hell out of it. You have an apple? Give me the core. You have an apple core? Give me the seeds!

The reason why you want a MVP, most likely, is for data collection and idea demonstration purposes. Often times, people have an easier time understanding your product if they can see it, or interact with it. Out of the two, interaction is often the best. We can try to explain things in all sorts of ways, using all different types of lingo, but the minute one interacts with the product, they’ll know in their own words what it does.

After your MVP is released and has fulfilled it’s role, and if the fates have decided in your favor, then you go ahead and tack back on all the things you’ve trimmed one layer at a time, until your dream comes to fruition.

That’s what MVP is all about apple seeds and fruition.

Facebook IPO: The things you can learn!

SELECTED CONSOLIDATED FINANCIAL DATA

 

The consolidated statements of income data for each of the years ended December 31, 2009, 2010, and 2011 and the consolidated balance sheets data as of December 31, 2010 and 2011 are derived from our audited consolidated financial statements that are included elsewhere in this prospectus. The consolidated statements of operations data for the years ended December 31, 2007 and 2008 and the consolidated balance sheets data as of December 31, 2007, 2008, and 2009 are derived from audited consolidated financial statements that are not included in this prospectus.

 

You should read this information together with “Management’s Discussion and Analysis of Financial Condition and Results of Operations” and our consolidated financial statements and the related notes included elsewhere in this prospectus.

 

     Year Ended December 31,  
   2007     2008     2009      2010      2011  
     (in millions, except per share data)  
Consolidated Statements of Operations Data:             
Revenue    $ 153      $ 272      $ 777       $ 1,974       $ 3,711   
Costs and expenses(1) :             
Cost of revenue      41        124        223         493         860   
Marketing and sales      32        76        115         184         427   
Research and development      81        47        87         144         388   
General and administrative      123        80        90         121         280   
Total costs and expenses      277        327        515         942         1,955   
Income (loss) from operations      (124 )      (55 )      262         1,032         1,756   
Other expense, net      11        1        8         24         61   
Income (loss) before provision for income taxes      (135 )      (56 )      254         1,008         1695   
Provision for income taxes      3        —        25         402         695   
Net income (loss)    $ (138 )    $ (56 )    $ 229       $ 606       $ 1,000   
Net income (loss) attributable to Class A and Class B common stockholders    $ (138 )    $ (56 )    $ 122       $ 372       $ 668   
Earnings (loss) per share attributable to Class A and Class B common stockholders(2):             
Basic    $ (0.16 )    $ (0.06 )    $ 0.12       $ 0.34       $ 0.52   
Diluted    $ (0.16 )    $ (0.06 )    $ 0.10       $ 0.28       $ 0.46   
Pro forma earnings per share attributable to Class A and Class B common stockholders(2):             
Basic              $ 0.49   
Diluted              $ 0.43   

 

(1)  

Costs and expenses include share-based compensation expense as follows:

 

     Year Ended December 31,  
       2007          2008          2009          2010          2011    
     (in millions)  
Cost of revenue    $ 1       $ —       $ —       $ —       $ 9   
Marketing and sales      3         4         2         2         43   
Research and development      56         7         6         9         114   
General and administrative      13         19         19         9         51   
Total share-based compensation expense    $   73       $   30       $   27       $   20       $ 217   

 

(2)  

See note 2 of the notes to our consolidated financial statements for a description of how we compute basic and diluted earnings (loss) per share attributable to Class A and Class B common stockholders and pro forma basic and diluted earnings per share attributable to Class A and Class B common stockholders.

As you can see, Facebook was losing TONS of money until in 2007 and 2008, and it wasn’t until 2009 that revenue overtook expenses. Think about that, a company started in 2004, losing millions of dollars a year, and not until 2009 was it profitable. 5 years of just spending money, 5 years of justifying the lack of revenue and the costs of everything. 5 years of, “Yeah, we’ve been losing a lot of money, but you should still invest in us”.

Another interesting thing to look at is the MAU graph, it details out what Facebook has been doing since 2004, and how many users they have obtained through that time:

 

I just find it AMAZING how much information is being provided as a by-product of Facebook going public.

The link to Facebook’s Registration Statement can be found here: http://www.sec.gov/Archives/edgar/data/1326801/000119312512034517/d287954ds1.htm#toc287954_2