One of the biggest problems struggling development teams have is shipping code. Most projects seem to have the same story of why they are late. Lots of planning and requirements gathering is done ahead of time to set the team up. The project starts off running smoothly and all the metrics are hinting that the project is on track. Confidence is high among the team and the managers are happy. Once you get to close to the 80% mark, then the progress starts to slow down. The last few tickets or a large bug end up taking 4-5x the estimated time. As a result, the deadline is missed. Missed by a mile.

This pattern where the last few issues of a project taking up a large portion of the work effort is common. There is always one bug that needs to be fixed or one feature that is a business owner wants to add. It is easy to find excuses to not ship code. This anomaly, where 20% of the project requires the most amount of effort, is known as the Pareto Principle. Development process like Agile and Lean have sprung up as a direct result of these challenges. Many companies are now familiar with the term MVP to release early and fight off scope creep.

I have found that process, no matter how much or how little, is unable to solve this problem of meeting deadlines. HauteLook uses two Agile methodologies: Scrum and Kanban. We have given multiple presentations on what MVP means. None of it has been as effective as increasing the amount communication among team members. When a team is communicating well they are implicitly working together. They are much more effective at problem solving and cutting through red tape. Communication also increases the sense of ownership over a project amongst the team members. When someone is included in a team discussion they feel like they belong. There is a sense of camaraderie. They are now much more likely to participate in future discussions and take initiative.

You can usually tell the difference between a team that communicates and a team that just goes through the motions by watching the daily stand-up. A team that is not communicating will usually be giving a status report to the scrum master. As each person gives their status update the other team members are zoning out because they are not sure what that person is really talking about. You will notice members of the team checking their phones or staring off into space. A team that communicates will be giving updates to the other team members, not the scrum master. A communicating team is engaged and they are making plans to fix any blockers that come up. There is a sense of urgency.

One of the best ways to facilitate an increase in team communication is to remove process. I first looked to our tools. We use JIRA at HauteLook to track the progress of sprints. It is very easy to add a lot of process to JIRA and think it will increase team efficiency. It is usually just the opposite. Too often process gives people a false sense of security that the process itself is going to solve the problems. Process does not solve problems; people do. When I am leading a team, a ticket is not ready for QA when a JIRA status is changed. A ticket is only ready for QA when the developer contacts the QA people on the team and informs them the ticket is ready. This communication can take place over email, but I encourage a more personal form of communication (in person, phone or instant message). The difference is that when a person changes status they are not expecting any feedback. They place the responsibility on the “process” working. When a person reaches out to another person they are expecting an acknowledgement of some sort. This sort of common interaction among team members creates a positive foundation and allows them to hold each other accountable in a constructive manner.

I double down on intra-team communication when a project is approaching the deadline. It is too easy for some people on the team to feel like they are done with the project when all the issues assigned to them are complete. When someone feels that sense of accomplishment they do not want to have to circle back to work on the project more. That news often comes as a surprise to them and now working on the project feels like an extra burden. By continuing to communicate with every member of the team on what the overall status of the project is they are much less likely to get that false sense of accomplishment. Instead, they are more likely to participate in dragging the project over the finish line and meeting the deadline as a team. Then, and only then, do they feel a real sense of accomplishment.

This time of year is all about giving and open source is no exception. I recently saw some tweets about a project called http://24pullrequests.com/ and was immediately interested. It is an effort to get more people involved in the open source community and the community for the software you commonly use. From the website:

24 Pull Requests is a little project to promote open source collaboration during December.

The idea is basically “Send a pull request every day in December leading up to Christmas”, encouraging developers to give back to open source with little gifts of code throughout December.

This is a great way to discover new projects out there. Once you login, using your github account, you will be given project suggestions. You can also view all the projects and filter by language. If you are interesting in learning a new language, one great way is to fix bugs and update documentation.

I have been doing a lot of development with Guzzle lately. Trying to abstract away the HTTP requests can get pretty hairy when API’s do unusual things. I have been contributing back to the Guzzle documentation to make it easier for the next person to grok just how awesome Guzzle is. Github makes it so easy to update documentation that you usually do not need to even make a local clone of the repo. You can edit it right through the github website.

I have also suggested a number of projects for people to contribute to, including:

• Symfony – TemplatedUriBundle
• Symfony – SessionStorageHandlerChainBundle
• Guzzle
• Guzzle Docs
• Hal for PHP

If you want to suggest an open source project yourself, go to http://24pullrequests.com/projects/new and fill out the form.

Happy hacking!

This post is inspired by Steve Yegge’s blog post Get that job at Google.

I have noticed that some candidates are taken by surprise during HauteLook’s interview process. These people are definitely smart and I think may have had a better chance at landing the job if they knew what to expect. So here is what you need to know in order to get a job at HauteLook.

General Overview

HTTP

HauteLook is an e-commerce company on the web. Pretty much everything we do involves the web (even our iOS apps). You should be familiar with the basics of HTTP 1.1. The basics include things like verbs, response codes and headers. You should also know high level concepts like how caching works over HTTP. All of this information is readily available on the web. That being said, I really like the HTTP Developers Handbook because it explains HTTP in a way that is easy to grok.

Code

Code is the preferred medium of choice when communicating concepts between different developers. We love code. We are excited to show you our code and want you to show us your code as well. Be prepared to write some code on the white-board. I know we spend most of our time writing code in front of a computer, so it may be helpful to practice writing some code examples down on paper to get familiar with the process.

HauteLook is an open-source friendly shop. We also want to see how involved in the community you are. In addition to your resume, we like to check your github account to see what projects interest you. The link to your github account is one of the most important things you can put on your resume. I normally use http://resume.github.com to get a nice overview of what each interviewee has done. Put your github username into the form and see what it looks like. If nothing else, let that inspire you to submit a few pull requests to your favorite project.

Logic

You might be asked a logic question. If you can get the answer that is great, but we really want to see your approach to solving the problem. Our logic questions are not riddles nor do they require leaps of faith. They are fairly straight-forward problems that can be solved with basic math. Consider practicing some logic questions with your friends so you are more comfortable during the actual interview.

Position Specifics

The HauteLook development team is split into four categories:

1. The backend engineers working primarily in PHP
2. The frontend engineers working primarily in JavaScript
3. The mobile engineers working primarily on iOS
4. The devops engineers bringing it all together

Backend Engineer

You need to be familiar with basic algorithms like sorting, tree searching and hash tables. We won’t ask you to implement these on the whiteboard, but be prepared to apply them to a problem and answer questions about the Big-O for different implementations.

Know how the database works. Doctrine and other ORM libraries are great at boilerplate SQL, but that does not excuse one from understanding what is going on. Be prepared to answer questions about the SQL-99 standard and be familiar with how indexes work.

Be familiar with design patterns as well. You should be able to discuss the common ones with us and have an opinion about them. You should also tell us when it is appropriate to use them. I recommend reading Head First Design Patterns if you are unfamiliar with design patterns.

Frontend Engineer

This position is all about JavaScript. You absolutely need to know how the language works. Be prepared to explain things like what a closure is and what the “A” in AJAX stands for. A high level overview of these concepts is not good enough. We will also ask about common patterns in JavaScript, such as the module pattern.

The use of jQuery is ubiquitous among all websites and it is just assumed you are familiar with it. HauteLook is now focused on the new class of frameworks out there like Backbone or Ember. You should be familiar with these frameworks and ideally have written some code in at least one of them. If not, you should at least know why these frameworks are important and what problems they are trying to solve.

Mobile Engineer

Our mobile team is primarily focused on iOS. The more you know about creating apps for the iPhone or iPad the better. This involves everything from available iOS frameworks, to app states to submitting an app. That being said, we like Android too. If you your passion is creating Android apps then show us.

Threads. Know why they lock and how to prevent locking. Also be prepared to discuss memory management.

DevOps Engineer

You need to be familiar with the role of a backend engineer and be knowledgeable about the infrastructure needed to run a high-volume website. Be very comfortable in at least one scripting language (bash, perl, etc) and how to interface that language with common unix commands like ssh.

Be prepared to talk about the tools used for continuous integration, automation, measurement and tracking.

Send Us Your Resume

You know what to expect, now go apply. Study up, nail the interview and join our team.

I wrote a blog post about the use of ORM in response to aother blog post about the move away from using an ORM. This is the philosophy I spread at HauteLook. When dealing with big data, patterns like Active Record just don’t cut it. We pay very close attention to the queries that drive HauteLook’s most popular pages.

The holiday season is HauteLook’s busiest time of year. We have spent a lot of time creating new products and optimizing website performance for the increase in traffic. We can now sit back and monitor our dashboards. This makes it a perfect time for us to implement a code freeze and spend some time on internal projects. These projects include paying off technical debt, planning for the 2012 year and training. Here are some of my activities during code freeze:

Attended the jQuery Summit

I spend most of my time working with server-side technologies, such as PHP and MySQL. The jQuery Summit had a great developer track that exposed many of the new trends and technologies being used to power websites. I discovered things like Backbone.js, RequireJS (AMD), better ways to handle iframes and now have a more in-depth understanding how jQuery works.

Streamlining the build process

We like pushing lots of small changes throughout the workday instead of large changes. I have been working with the release manager on some bottlenecks in the release process. I have been adding new features to our open source IRC bot plugin to make it easier for our developers to keep track of what is being released. HauteLook uses the Phergie IRC bot and our Jira plugin exposes a lot of common Jira tasks as IRC commands.

Learning Backbone.js

I am working with the front-end team to integrate Backbone.js into our existing codebase. We are always trying to improve processes, especially the amount of time it takes to create and improve features. The HauteLook backend is fairly well architected and organized. There is a clear separation of MVC concerns and our Restful API makes it easy to expose HauteLook to other platforms. Backbone.js looks to provide this same sort of separation to the front-end. A number of us are implementing existing website features using Backbone.js and discussing what we learned and what best practices to introduce to the entire team.

Fixing bugs and adding features to xhprof

Performance is a big deal at HauteLook. Our bursty traffic patterns present a hard, but interesting challenge to keep the API, website and all platforms fast. I created a custom fork of Facebook’s xhprof to store PHP performance profiling data on Amazon S3 and created a more functional dashboard to view the results. Recently, I stumbled across a tweet from Paul Reinheimer about the xhprof fork he had been working on. I decided to collaborate with him and merge my changes into his fork.

Attending the PHP Architect Cloud Summit

PHP Architect hosted a cloud summit where a number of startups presented on how they were using the cloud. HauteLook is traditional in that we have a data center with hardware that we own. We do use some cloud features, such as Amazon S3, where appropriate. A number of us attended the online summit and discussed the ways we can leverage new cloud technology.

Planning for the release PHP 5.4

The release of PHP 5.4 will bring about some significant fundamental changes to the way PHP works. I am already assessing what PHP changes we have to make in order to upgrade to 5.4. This involves custom builds of PHP to run the .phpt tests that ship with PHP on our production web servers and running our PHPUnit test suite against 5.4.

The PHP 5.3.7 fiasco really highlighted the need for more people to test PHP release candidates and not wait until the code has been released. This is even more important with PHP 5.4 as there are a number of significant changes to the way PHP works. A release candidate should be tested in two ways: that PHP builds and executes correctly on production web servers and that the HauteLook application works properly. Testing the application is really no different when testing against a release candidate. Building a release candidate to test against can be a little tricky however.

HauteLook uses CentOS on our production web servers and PHP is built by a number of rpm packages from Remi. Unfortunately, Remi does not package up the release candidates as RPM though. This means I need to compile PHP from source while making sure I am configuring everything the same. HauteLook has 24 rpm’s that make up PHP. Trying to manually determine the configuration settings for all of these rpm’s would be a tedious chore. Luckily PHP will tell us the configure command to use. I ran:


php -i |less


I copied the Configure Command section into a file called php-config. Now all I need to do is get the source code:

wget http://downloads.php.net/stas/php-5.4.0RC1.tar.gz
tar xzf php-5.4.0RC1.tar.gz
cd php-5.4.0RC1
sh php-config


This will compile PHP, but not the way I wanted. The Configure Command puts apostrophe’s around each configuration flag and this causes a problem. I used a quick sed command to clean this up:

sed -ie "s/'//g" php-config

The next problem is that I was using a production vm snapshot to test against. I need all of the development packages in order to compile PHP against them. Rather than manually hunting down every package PHP needs to compile against and installing the -devel counterpart, I again used sed to just install the development headers for all packages:

yum list *-devel | sed -ne '/^Installed Packages$/,/^Available Packages$/ p'

Now PHP should compile successfully:

sh php-config
make
make test

The make test portion will run all the tests shipped with PHP against what I now have compiled. It is not uncommon to have some tests fail. There is an option to send an email to the PHP QA team with a list of failed tests and some system information. I encourage you to send this email anytime you are testing.