Ok, long time no post. I’ve been working on some very cool stuff. I was the front-end architect for the Amazon Cloud Player as well as the tech lead for the Amazon MP3 Uploader. Both of these along with the Amazon Cloud Drive that the player uses were launched just under 24 hours ago and so far the news seems good. Very excited to see how this grows and how people react. Could write a lot more, maybe later, but I’m keeping busy right now so who knows.
I like documenting the previous work that I’ve done, so I’m posting some of the pages from PlayFirst.com that I worked on. Much credit needs to go to Colin Felton, Karen Chu, and Maria Waters, the designers at PlayFirst, for the exceptionally attractive designs they came up with. Sadly, pictures don’t do justice to the full experience since much of a UI is how it reacts as you using it, but I don’t feeling like doing a video, and the site is already changing, so I’m a little late.
Front Page of PlayFirst (Dec 2009)
The global nav, which includes the left sidebar, was all coded up by myself. Not shown is that there could be a popup when hitting this page that would display a marketing video to users who hadn’t seen it. Big game launches would use this feature, but since it was slightly intrusive (as popups are), we only used it for promoting the best quality games.
All Games Page
The All Games page listed, of course, all the games for sale. There was a feature to include an image with a link at the top of the page for promotions. This could be a rotating set of images that would change each time you hit the page. Next to the front page, this was the second most hit page, and that kind of exposure could drive traffic for important new releases.
The fun feature I built on this page was a pop over for the game images. It would seamlessly display more information over top of an image that you hovered over. This could include game description, pricing, buy/download buttons. These would open as you hovered over an image, and go away as you hovered away. As you might notice between this and the above image, the popup image was perfectly aligned with the main page image giving it neat effect when it faded and out.
There were a number of things to consider while doing this feature. First, you only want one loading and opeing at at time, and you don’t want one opening if you scroll and hover over while scrolling. Popup placement was a changing target too if you scrolled any as the popover still needs to render perfectly over top of the image even if it moved a little. On performance, when you’re tracking hundreds of potential target images to activate the effect, that’s an event that can drag on performance if done without consideration (one key to the solution being event delegation). For this page, I had to make performance adjustments as there were over 700 game images on the page, and even though the popup was an AJAX created popup (created on hover), the hover over and off effects needed to immediately load and reloading each time perfect on top of the image even after scrolling some.
Another feature that you can’t see on this page without using it is partial image loading. The 700+ games are in a table that is filtered with javascript as you select categories on the left sidebar, or type in a title in the title filter at the top. The page needed to re-render the images instantaneously, but also only load the minimum number of images for the viewport. As you’re seeing only 12 or so of the 700+ possible images at any one time, I’d only load those plus a few extra for when you scrolled. And then, as you scrolled, new images would populate themselves just outside of the viewport, so you’d always see something, but the page wouldn’t get slowed by trying to render so many images, including when you filtered them by category, title, or some other criteria. (Obviously, people with javascript wouldn’t see these features, but the page would still work).
Detail Page
The game detail page was completely redesign and I did all of the implementation work for this very important page. There’s a slideshow of game images, and possibly a link to a game trailer. The buttons, try it, buy it, buy with PlayPass, would change depending on the game’s status (pre-release, in beta, live, etc.), and the user’s membership status with the site. The tab selection would change as not all games would have all the tabs. I made the tabs with AJAX enabled content loading. For SEO purposes, there were uniques pages with URL for each tab view, but if you had javascript on, then the content would fade in place of the content for the previous tab.
Another view of the detail page. This time with a non-PlayFirst game.
Not all of the pages that I touched, or features I worked on, but these were the key ones that I had a lot of impact on. Overall, I helped reduce page load times by up to 45%. Average load time for the site dropped from ~6 seconds to ~4 seconds. The main reason for this was optimization of the thousands of images used on the site. Use of sprites for buttons and other elements helped smooth over interactions and such. Lots of fun, but I’ve moved on.
Thought I’d mark this moment on the blog. I’ve recently quit my job with PlayFirst.com, and I’m moving to a new position with Amazon.com. Lots of smart and experienced people at PlayFirst with an interesting and always changing environment, but I’m really looking forward to my new position working on Amazon’s MP3 digital download store and helping build and improve its interfaces.
I’m posting almost never now, but that’s just because I’m busy with other stuff. Work is ever changing and interesting, and I’m going backpacking in Peru in a few days.
My last post was a partly about differences of opinions at work, and while I haven’t really made much progress moving people to my point of view, I am altering my view on things a little. First, things are working well enough with how we’re doing our jobs, so I have to give that credit. Certainly, some problems could have possibly been avoided, and some future problems that we’ll have to address still loom, but overall, things are functions well enough code wise.
So really, our biggest challenges are business oriented, and the company is at a special place trying to push itself passed that key tipping point for a startup, so there’s an especially acute set of pressures coming from the business side. That’s caused me to tone back my point of view a notch in light of understanding the business needs better, but it’s also toned back a notch because I’m more interested in focusing my efforts on front-end development. Also, I’m on the committee that’s helping draft company core values as well as improve internal company problem areas, which is a fun big (internal) picture kind of function that I really enjoy, and which I hope will also help us become a much better company.
But that will all be placed on hold very soon for my hike to Machu Picchu, and I’m getting really excited for this trek (if not so much for the 30+ hour flight down south).
The big divide at work (for me at least) is between the hacker coding style of development and object oriented engineering. I’m in the OO camp, and my two superiors are in the hacker style camp. I’ve been working on the hard sell of trying to change how we develop as a team, and frustratingly enough, I don’t seem to be making much progress. Good thing I’m stubborn.
What I call hacker style is a method of development where getting things to work and out the door is the primary goal. Time spent thinking and planning development is limited to small scale, low level, single function planning. Nothing is really orchestrated, and the “system” is more of a patchwork of processes that when run in the right order, perform the overall tasks as though it were actually a whole. The focus is on speed, and being able to do new things.
Now, I don’t have any problem with that in general as there’s a trade off when moving to a more thoughtful, and deliberate OO style of development, which can have a real positive or negative impact on business. And for startup companies, hacker style is the preferred and probably optimal style of development. Business demands require speed and getting things out the door, so you can finally have a proof of concept that generates real revenue. Spending extra time to choreograph the whole system is money lost that’s hard to replace when you’re already on a shoe string budget.
Admittedly, I work for a startup, but it’s a startup with real revenue (million of dollars of revenue a year for multiple years with continued growth), and I’d says it’s in a transition between the “we’re still a startup” and the “we’ve got revenue streams to worry about” stage. The engineering team to date has done a great job doing what needed to be done. That’s something to be proud of, but now the code base is old and messy.
If there’s anything to be said about my last job, it’s that I’m experience in old and messy code (I’d include my time at Citigroup too, but the code was just old, not as much messy). And I’m definitely experienced in leading a development team to a more appropriate style of development. I personally prefer a more deliberate OO style of development, but my last job needed more hackers. Still, OO can be implemented with great successful if you have the right experience in earlier stages of the game. With this my new company, which is a little bigger, they’re about at the end of the hacker stage as I see it, but they’re holding on tight.
With a team of good developers, how do you transition them from being hackers to engineers, and what is the benefit of an OO approach to engineering as well as the business? As your code base grows, its complexity grows. Maintenance, scalability, adaptability, once corner stones of the hacker style, now become elusive and out of reach. Even with well build systems, things get old and messy. From my experience, most systems only last 4-5 years before needing a good overhaul, or the business risks losing it’s ability to change and respond to new situations. Developer time gets lost to fixing bugs and time gets eaten up by the many workarounds that inevitably happen when implementing additional functions and features.
The ultimate goal of OO design is building an intelligent code base. Intelligence is not a measure of behavior like most people think. Intelligent is an understanding that allows one to predict future events. A code base can “predict” future events by understanding what is likely to change in the future, and having that part designed in a way that makes changing it easy. You don’t make everything easy to change, but that which is likely to change. You need to manage the complexity of your code or it’ll blow up in your face.
People who aren’t familiar with OO design, or aren’t experienced with good OO design (it’s easy to screw up if you don’t know what you’re doing), they may see OO as more complex and slower to implement. When transitioning between development styles, in the short term that may well be the case, which is why startups generally don’t do OO design unless they’ve got some special previous knowledge in the matter. But as complexity grows, patchwork systems lead to more bugs and a more complex interaction that will drag down a development team, and in the extreme, can cripple a business’ ability to react.
One of the main pieces missing when doing hacker style development is a big picture view of the system and the various interactions. As the system was developed in pieces, the patchwork of functions were developed with limited consideration of other existing functions, and usually no consideration for upcoming functions. Without a big picture view, you can’t pull yourself out of that patchwork. You need a guide to get yourself to a better position.
There’s an additional drawback to the patchwork (utility class) design. Because it focuses more around processes and less around object relationships, it’s impossible to discuss the parts of the system. Engineers will be forced to learn from the code instead of other engineers. Additionally, as the code base is process focused, you’re code will give as much if not more weight to dealing with edge cases. This is part of the reason why engineers have a tough time discussing such existing code because you can’t generalize and talk about the overall interactions, but instead are caught up mulling over special cases.
The benefits of OO engineering range from greater ability to react as system complexity grows to better team communication as you move away from process acted upon multiple complex objects to relationships between a common set of objects. Getting a team to handle this change properly requires a map, but also vision and a mission.
Businesses have two functions. Marketing (PR, advertising, sales), and invention (engineering). The marketing side of the business will most certainly have a set of ideals such as VMOS (there are many varieties of this), vision (the dream), mission (what you’re trying to do in the next couple years), objectives (focus or important metrics for accomplishing the mission), strategy (lines of action for meeting your objects). The highest level long view down to actionable strategies. Engineering needs a similar plan that describes how they’ll implement the business’ VMOS. The engineering VMOS will reflect the business’ VMOS, but translated for engineers and around the act of inventing instead of marketing.
Somewhere in the objectives and strategy level, you can setup a diagram of your system. Not how it is today, but how it should be tomorrow. This’ll be constantly changing, but it gives engineering a way to communication, and a guide for how to develop. Where do you spend the extra time planning? What is really an at risk area? What functions are important to keep on the radar?
OO engineering can easily break down without a plan, but also without a leader. Just as the graphic design team will have a head designer who will pull together the design and keep it looking like one common design, engineering needs a head engineer to pull together overall development as though it was actually done by one person. Since any problem can be solved in 20 different ways, you need someone to short cut the discussions, and make a decision even if it doesn’t look like the best choice to everyone. Just because you’re given more room to plan and think deliberately, doesn’t mean you can waste valuable time not getting code out the door (I’m not advocating a waterfall approach mind you).
This gives the engineers the tools to both communicate and predict. With the high level ideals defined, you can develop a plan for transitioning. How do you meet business demands and still maintain and improve the code base? It’s laid out in the engineering VMOS. Without this, all you can do is react to the nearest term demands and situations, which becomes tougher and tougher the more patchwork and complex the code. The engineers are the protectors of the code, and they must always be mindful of that while they get pressure for more from the business, so you can’t let the marketing side make all the plans and call all of the shots.
Wrapping this up, both styles work with the variety of agile development approaches. Both styles have value for a business at different stages in it’s life. Both can be good or bad if you go too far to an extreme. Balance is key as is so much in life. In the case with my current job, moving to OO engineering removes much current and future complexity.
