Archive for Featured

The Technical Lead’s Take on the New VEVO Beta Website

VEVO recently went through a redesign and rework of its entire front-end to come up with a brand new beta version of it’s website. I started as a software engineer at VEVO back in August, and I became the technical lead in charge of the new beta project in January after it started in late November and led a team of a few developers to its completion. I thought it would be a good opportunity to write about some of the things I’ve learned and taken away as well as highlight some of the cooler features we’ve been able to work in and add. I’ll break it down into: design/usability changes, technical improvements and process experiences.

Design and Usability Changes and Updates

• Larger Video Player - This is the first thing that anyone will notice when coming to a video. The player dominates the screen regardless of screen size and acknowledges that the user is there to watch a video.
• Advanced Social Integration - By making use of Facebook, we’re able to tell your friends when you’ve watched a video, share a video with them easily by dragging it to them and seeing your friends playlists. In addition, we create playlists for you based on the music you’ve liked on Facebook and your iTunes library.
• Simpler Homepage - The homepage, instead of having a carousel of images and links at the top with a variety of content below, we have one large carousel that really shows the visitor what the highlighted pieces of content are and what’s new at VEVO.
• Dynamic Resizing - The entire site fits the browser on every page, using more real estate on the screen and ensuring that the content (video) is truly highlighted.
• Persistent Navigation and Header - The navigation on the left, the header on the top and the footer are persistent and fixed throughout the site so a user can see their friends and playlists much more easily and search for a video quickly without needing to scroll.
• Continuous Play - When a user watches a video, we always have a new video to show them after that one finishes. This is a seamless experience for the user and also allows for them to enjoy the music videos without needing to really work to find videos that they’ll like.
• Removing Search Results Page - This sounds like it would be a bad idea, however, it improves the likelihood of a good experience. When a user searches for “Lady Gaga” but mistypes “Ladt Gaga” they, based on their experience on Google and elsewhere, expect to be corrected or brought to the right place anyway. VEVO, however, doesn’t have the resources or manpower to spend time on creating such advanced search algorithms, so we instead used only lookahead search, then a user quickly sees that they mistyped and corrects themselves, getting the results they want right in front of them.

Technical Improvements

• Using HTML5 Pushstate - By using the HTML5 pushstate on the playlist and video pages, we’re able to quickly show new content on the video page and decrease load time and increase overall performance, experience and decrease the number of HTTP requests.
• Local Caching - By caching artist, video and friend information on a user’s local machine, that means fewer data requests to our servers and much faster speeds on each additional page, meaning that the user gets a faster and faster experience as they go from video to video.
• Improved Recommendation System - By leveraging Echonest and their recommendation system, we’re able to give a user many, many more videos that are far more applicable to exactly what they are looking for, making the continuous play mentioned above all that more memorable and compelling.
• Cached Pages - By making all user-based calls come after the page loads via JavaScript, that means we can use extensive caching on most pages and modify the pages once the page has started loading on the user’s end.
• JavaScript and CSS Bundling - While previous versions of VEVO had this in a sense, there was often repeated JavaScript or CSS or multiple calls to different bundles on different pages. In addition, the system we used was hard to manage or tweak and couldn’t be debugged or adjusted on the fly. The new system combines all JavaScript and CSS files into two large bundles that are the same on every page, making it fast and simple, with an option to turn it off if debugging is needed and a switch to regenerate the CSS or JavaScript bundles on the fly.
• Facebook Integration - We were able to heavily leverage Facebook to get information about users of the site, including friends and music likes to greatly personalize the website.
• iTunes Scanning - We used a Java Applet to allow users to scan their iTunes library and create a playlist based on the artists they have in their library. This was one feature that really got some oohs and aahs and showed people some of the more unknown videos we have in our catalog.

Process Experiences and Lessons Learned

• Scope Creep - The bane of all projects, large and small is scope creep. While we did limit it in some ways during the project, pushing things back saying we could add or improve them post-beta, that wasn’t always the case. Especially when we were near the end of the project, the final 10% of work seemed to drag on and on with small, and large, additional changes.
• Time Management - While you always try to plan to have time to tweak features and eliminate bugs, the reality is that you can never plan enough time for that. Again, that last 10% usually takes the most work and there’s nothing like having more time to handle that and not needing to scramble.
• Chaos Versus Agile - While VEVO touts using an agile process, the beta version was given such a short deadline and so many things to accomplish and change that that process started to break down. Tasks were lost along the way or never assigned to developers or designers, so it wasn’t clear who was assigned what as well as what the status was on a given feature, design or bugfix.
• Running on Empty - Given that it was a big project with a small team, people were running at their top performance for quite some time. While this can be good for short times, doing it for two or three months discourages people and hurts motivation as well as quality of work due to overwork and general tiredness. In addition, the ideal of doing things fast tends to hurt the ideal of doing things right, so the final stages, often the most crucial, are filled with the most mistakes. Combine this with scope creep and you are left with a frustrated team in general.
• Beta Means Beta - While I appreciate perfect, often “done” is better. And there should be a criteria for “done.” This eliminates scope creep, gets things rolled out on time and encourages agile development. We aren’t releasing a magazine, newspaper or book – we can always add more features, fix more bugs or improve performance later and start getting user feedback and information sooner.

It was a fun and exciting, while stressful, project to be a part of and I’m looking forward to its reception in the coming days, weeks and months. I’m sure it will be mixed and that there will be both positive and negative reviews, but I’m proud of what the team has accomplished in the time we were given and I’m proud that we were able to change how video sites work and able to make an impact as the second largest video site in the United States.

4 comments

The Individual Roles Within a Software Development Team

When it comes to any one problem to solve, place to get to, goal to achieve, there are limitless ways to get there, especially when it comes to software. Those differences can be in technology used, development lifecycle, team size, test-driven, you name it, there’s a different way to do it.

One aspect, which is likely the most important aspect of them all, is your team’s structure and the different roles that people take and how those roles fit into getting things done well. Even when the team is really just one person, that one person has to take on those different roles. Though there are many different names for these roles, I’ll give them the most generic classifications possible and then give examples of those kind of roles and their relationship to the features or requirements needed for a project or effort.

Source – Examples: Client, Business Analyst
This is the person who has the inspiration or idea for what should be created and at least some vision of what that will look like. This could be a client who needs a website made, a developer with an idea for the next killer app or a business requirement coming from management. I tend to think of them as “the Source” because they are where the work or project is coming from.

Refiner – Examples: Project Manager, Lead Developer, Designer
Here we have the person who really delves into what needs to happen to make something useful and compelling. They either can be the Source who refines their own idea, or they could have a back-and-forth with the source to really find out what is going to happen, what’s needed and what benefit the idea is going to provide.

Architect – Examples: Technical Lead, Lead Developer
After the Source and Refiner have done their jobs and come up with what should be built, the Architect decides how it’s going to be built and how it’s going to happen. That can include deciding the technology or methodology that will make the idea into an actual project and how it’s going to be completed.

Builder – Examples: technical Lead, Developer
The Builder will take what the Architect, Refiner and Source have put together and make it a reality. They will take the project and actually build or complete it, likely with a fair amount of interaction with the above three as unforeseen or unplanned events, complications or considerations come into play.

Tester – Examples: End User, Project Manager, Client, Developer
Once the Builder believes they have finished creating the project, or at least portions of it, someone checks to make sure it’s behaving and works as expected. This Tester will often go back and forth with the Builder when unintended problems are found or missing features are discovered or additional requirements that weren’t thought of before are found.

User – Examples: General Public, Employee, Client
Finally, once the project has been completed, there is the actual user of that project. This is the person who the project was built for and who should be the main consideration throughout the project, making their life easier or more enriching in one way or another.

Now that we have these different roles defined, I hope to go into what an ideal structure would be on a given project in a follow-up post.

1 comment

Managing Complexity in Software Development

One software development book that I have found is very informative and though-provoking has to be Code Complete. One of the main points is that the ultimate goal for software development is to manage complexity.

It goes very well with Wil Shipley’s blog post about being a code samurai, an article that is a favorite of mine. Ultimately, they say the same thing: develop deliberately, with the goal to keep the software simple.

I’ve mentioned keeping it simple in mobile web development, but it applies to all development, in fact. Development shouldn’t just be done with the goal to get things done quickly, it should be done with the goal to get things done right. What’s right? Something that gets the job done efficiently now, but also can be revisited and updated later, which is ultimately the most important goal because very rarely, especially in these days of web development, is software ever “done.” How does getting it done right happen?

It happens when a developer keeps it simple. Both for the current development and for the potential future developments. Ultimately, the best coding comes when the software is simple and readable. This gets the job done well and let’s a developer continue to get the job done well and quickly later. Simple is maintainable, and maintainable is good. More than good, the best.

Minimize complexity, keep it simple.

No comments, be first...