By Michael Woloszynowicz

By Michael Woloszynowicz

Thursday, December 8, 2011

A Month With Scala

Although I’ve played around with Scala for the few months, these efforts largely involved simple scripts and casual reading. It wasn’t until last month that the opportunity to use Scala in a large scale project finally arose and I dove right in. The project was a typical REST based web service built on top of Amazon’s Elastic Beanstalk, SimpleDB, S3 and Redis*.

First off let’s talk about why I chose Scala in the first place. After spending a good deal of my last year entrenched in JavaScript and appreciating its functional nature, brevity and flexibility, writing Java code became a tremendous chore for me. At the same time, our developers have grown accustomed to, and appreciative of the wide array of quality frameworks and tools available for Java, so a drastic departure was out of the question. This left us with two viable options: Clojure, and Scala. Ultimately I decided on Scala as it provided an easier transition, was more mature, had greater community support, better interoperability with existing Java code, and a nicer syntax. That being said, the last month hasn’t been as painless as I expected and Scala’s use in a real project is a far cry from its use as a scripting language.

The Good

Simply put, this is the main reason for my departure from Java. I fell in love with having Functions as first class members in JavaScript and it pained me to work without them in Java. Coupled with other functional niceties like currying, partially applied functions, etc. it improves code re-use and drastically accelerates development. Although I’ve seen several people grumble that Scala isn’t a purely functional language as it contains a good deal of Object Oriented features, I see this as a strong point. It provides OO programmers with an easier transition and allows them to strike a balance between the two styles. That being said, if Scala is to be adopted across the whole team, it’s best to decide on a coding style and enforce some best practices as Scala’s laxity can lead to greatly differing code styles.

Lists and Iteration
Scala’s lists and maps are completely different from those provided by Java which is both good and bad (more on the bad later). For starters, in true functional fashion, they are immutable by default but mutable variants are available. Their strength comes from the broad array of iteration and filtration functions that make manipulation a joy. These include the usual suspects such as map, filter, foreach, etc which accept a predicate or translation function to produce a new List. Some examples of iterating lists include:

val cars = List("honda", "audi", "bmw")
//Upper case each entry (using _ notation)
val uppers = 
//New list for names less than 5 chars
val shorts = cars.filter(A => A.length < 5)
//Create a list by joining two lists 1..4 and 6..9
val nums = List.range(1,5) ::: List.range(6, 10)
//Make comma separated string "1,2,3,4,6,7,8,9"
val numsStr = nums.mkString(",")
var sum = 0 //Get a sum of all the values

Compared to Java, Scala code is easier to digest but it’s certainly no Python. The language lacks the intuitiveness that Python brings and only becomes fully readable once a good degree of familiarity has been gained. That being said, I now prefer to read and debug it over Java any day. Scala does away with excessive return statements, semi-colons, and allows for much more natural and expressive function naming and invocation.

Sort-of Statically Typed
Although we can debate the merits of dynamic vs. statically typed languages for hours, I think Scala has struck a good balance with its use of type inference. Dynamic typing in JavaScript is often a blessing and a curse so Scala’s promise of brevity and type checking is appealing and well implemented.

Concise Methods and Classes
As time passes, the “v” in Java begins to stand more and more for verbose. From lengthy boilerplate to duplicate statements in object declarations, Java is hardly a model for brevity. Scala on the other hand does an excellent job of this in many regards. Its functional nature has a lot to do with, as do the syntactic enhancements. Additionally, Scala helps by automatically building accessor methods for private class variables, as well as declaring those variables and the object’s constructor all on one line. Other features such as Traits and pattern matching provide further brevity. Traits allow you to mix additional functionality into an object regardless of its hierarchy. For example, Scala provides an Ordered Trait, that when mixed into an object that implements a compare method, will provide functions for object comparison operations such as “>, <, >=, <=”. The best thing about Traits is that they can be mixed in at the point of instantiation as well as declaration which allows you to build full featured objects on the fly. Pattern matching is the Swiss Army knife of Scala. Despite its somewhat deceptive name, pattern matching goes beyond the functionality of a simple “if” statement as shown in the below examples.

val cars = List("audi", "honda", "bmw")
cars match {
  case List("audi", x, _*) => println("second is: "+x)
  case first :: rest => println("first is: "+first)
  case _ => println("something else")
//A general size function
def getSize(a: Any) = a match {
  case s: String => s.length
  case l: List[_] => l.length
  case m: Map[_,_] => m.size()

The Bad

Not a Beginners Language
By most measures, Scala is not a simple language to learn. While there are lots of languages that are large in scope and features, most can be learned over time. Scala fall short by requiring you to learn at least 75% before you can do anything meaningful. When I first started out with some basic scripting this didn’t appear to be the case, however; once I tackled a real project, I realized how limited my knowledge really was. For those that think you’ll coast by because you’re a Java expert, think again. My Java knowledge is extensive and the parallels between the language are few and far between.

Java and Scala
One of the major draws to Scala was that it interoperates with Java code, so years of utility functions and helper classes would not go to waste. While it’s simple in theory, it’s not the case in practice. Several Scala objects are cumbersome to use in Java as Scala has had to perform ugly syntactic transformations on itself to work with the JVM, resulting in some rather ugly Java code. Furthermore, Scala collections are largely incompatible with Java, so a good deal of conversion has to be done (Scala does provide utilities for this). Finally, the greatest frustrations occur at compile time when Java and Scala sources don’t always play well. Because Java and Scala compile independently, the order of compilation can matter when one languages references another, or worse, they both reference each other. While the Scala compiler invoked through a builder like Maven, or the command line provides workarounds for this, IDE’s such as Eclipse and NetBeans don’t fare as well. Although the Eclipse Scala plugin is supposed to support Joint Compilation out of the box, this has not been my experience thus far. As long as your not married to Eclipse, I’ve heard IntelliJ and Buildr are the best IDE’s for Scala development so you may want to opt for one those if going the Scala route. If you do choose to use Eclipse, be sure to discard the slow default Scala build manager and opt for the new SBT project builder which offers far better performance. If at all possible, I would also recommend constraining your Java and Scala to uni-directional calls as this keeps the code cleaner and reduces compilation issues. In my case, I use Java for Servlets and REST via Jersey with the service and data access layers provided by Scala. This way Scala never has to call Java.

Frameworks and Toolkits
Although the number of good quality toolkits for Scala is growing, Lift and ScalaTest being two of them, it still pales in comparison to what is offered through Java. RESTEasy is not nearly as nice to work with as Jersey, and Scalaxb doesn’t perform JSON marshaling and unmarshaling like JaxB does. The limitation of Scalaxb has forced me to use JaxB over my Scala objects, which works fairly well, with the exception of Lists. Scala’s native Lists don’t convert properly during serialization so the solution is to use a Scala Buffer and write a transformation function which converts them to Java lists for writing, and back to a Buffer after reading. This isn’t a huge pain but it's an inconvenience nonetheless.

The real Achilles Heel for Scala is its compiled version fragility whereby third party tools and frameworks have to be versioned to a specific Scala compiler version. This is simply a function of Scala's continual and rapid evolution, so shy of extending release cycles I'm not sure how much can be done about it. The issue has been well detailed on the Lift blog so I won’t elaborate on it too much, other than to say that it’s real and it is a pain.

So Should You Use It?
Despite its shortcomings Scala is an expressive and enjoyable language to write in. It eliminates a lot of the pain points that Java Suffers from and provides a good deal of added functionality that will accelerate your development efforts. For those currently writing in Java, I encourage you to learn Scala as it will make for more enjoyable programming and make you a better developer overall. For others, if your already using a good language like Python then Scala is a tougher sell although still recommended. In the end, it’s a good language with a lot of great third party tools provided by Java. If you do decide to take the plunge, Programming in Scala by Martin Odersky (Scala’s creator) is a good introduction to the language.

* As a side note, if working with Redis in Scala, the scala-redis package works like a charm. 

If you liked this post please follow me on Twitter  and upvote it on Hacker News

Wednesday, November 16, 2011

Price Doesn't Always Matter

Don't get me wrong, pricing is an important part of a product strategy, particularly in the consumer goods sector, but it doesn't always matter. I see lots of startups wrestling with how to price their newest product, often pricing too low or even taking a freemium approach, all in the hope of acquiring a large initial base of customers.

Because pricing is such a large part of our daily purchasing habits (Groupon?), we have a natural inclination to believe that the it's a major decision for our own startups. The common belief is that pricing follows a traditional economic supply and demand curve, with a lower pricing yielding a higher demand and vice versa. While this is largely true, focusing on this model alone ignores a myriad of other uncertainties facing an early stage startup.

The problem with fixating on price at an early stage is that you're bound to get it wrong. Whether you're wrong on the high or low end is irrelevant, what's important is that an obsession with price can lead to wasted time and energy. Expecting to come up with an optimum price before your product reaches its first set of customers is nothing more than an exercise in futility.

Where energy needs to be expended is on discovering the true barriers to adoption. Price is only one barrier, and within a particular rage it can be a minor one at that. To come up with a list of adoption roadblocks, an intimate understanding of your target market is first needed. A study of your ideal client may reveal any of the following:
  • A high resistance to change, perhaps due to high switching costs from their existing solution
  • No clear way to reach them, perhaps leading to high acquisition costs
  • Technical knowledge barriers
  • Trust, security or privacy concerns
  • There's risk in using your product, will it be hard for them to get out?
You'll notice that if any of the above were to hold true, pricing wouldn't even become a factor in the buying decision. It's these sort of deal-breaking factors that should serve as the focus of your attention at the outset as they can be addressed through product strategy, features, and website copy. The price elasticity of your product is something that can be validated through experimentation and A/B testing once the product peaks the customers interests and any hidden concerns have been eliminated. Until that point, you're safe to choose a value based pricing strategy and move on. Resist the temptation to begin with freemium pricing (unless your type of product is highly conducive to it) as it often fails to give you an indication of your product value in the eye of the customer.

Despite the title, pricing is important for your product in the long-term, but its significance only comes to play if there are no other forces working against you. Focus your efforts on flushing out these hidden barriers to growth and leave the pricing debate for a later date.

If you liked this post please follow me on Twitter for more

Saturday, November 12, 2011

Under-Appreciated Engineers and the Curse of Usability

The life of an engineer is not an easy one. We're expected to translate ambiguous requirements into a concrete, timely, and scalable solution that satisfies a wide range of stakeholders. We venture into the unchartered territory with an ever growing array of technologies and infrastructures to choose from, never knowing what direction the product will take in the future.

While such challenges plague us on a daily basis, the really depressing part is that only a precious few people will ever appreciate the effort that went into it. Often not your boss, and certainly not the end user. 

The superficiality of human nature leads people to appreciate the physical aspects of the product rather than the beauty that lies within it. There's no better example of this than Apple products. While Apple garners constant adulation for the beauty of its products, few praise the engineering effort that went into every detail of a MacBook Air or iPhone, and bringing the designers vision to life through a physical and functioning unit. This effect transcends technology products and is equally evident in an industry such as construction. When an important or influential building is erected, it's the architect that garners all the attention while the engineer that is responsible for the lives of its inhabitants remains largely unnoticed.

From a technical product standpoint we suffer from a curse of usability. The simpler the product's interface the more muted the engineering effort appears, when in fact the opposite is true. The simpler the interface, the less work the user must do, the more work the engineer must do to yield the desired result.

That's not to say that engineers never get any attention, they do, but it's rarely the kind we want. Engineers are usually brought to the fore as soon as something goes wrong. If that very building collapses you can believe that the engineer will become the star of the show.

So what's my point? Well...

For those that are pursuing a career as an engineer of any sort, you'll have to develop a good degree of meekness. You'll have to make sure that you're pursuing it because you love it. You love the daily challenges, the ambiguity, and you're comfortable not always getting the praise you deserve.

For the companies out there, I urge you to foster a strong engineering culture where upper layers of management have the technical knowledge to appreciate the work done by your engineers. Companies like Facebook and Google attract lots of brilliant engineers for this very reason. If something goes wrong, don't be quick to blame the engineers. Remember that a majority of failures stem from a management problem rather than a technical one.

For the masses, I ask that you look beyond the surface of the product and become curious about what it took to make it work. Remember that simplicity often masks a host of technical obstacles.

For the engineers out there, I urge you to not live in a bubble, surrounded only by your own set of challenges. Reach out to your fellow engineers, ask them what they're working on and praise them for the interesting problems they've solved. You're in the unique position to understand and relate to their challenges. Remember that they'll do the same for you when you need them.

If all this fails, appreciate that you are creating something out of nothing, something that is hopefully used by and changes the lives of a large number of users. There will always be a demand for your craft, even if the appreciation of it is not always what you'd like it to be.

Cheers to all the engineers out there.

If you liked this post please follow me on Twitter for more.

Sunday, November 6, 2011

CoffeeScript Means Giving Up on JavaScript

While many of you will probably disagree with me, I find the trend towards writing in languages that compile to JavaScript somewhat alarming. The most notable of these languages CoffeeScript, and it's one that has gained a good degree of traction over the last year or so.

While I like and applaud the intention of these languages, I question their necessity and worry about the knowledge gap they create. More importantly, they all fail by requiring that you be an expert in two languages. Let's face it, you can't just program CoffeeScript without knowing JavaScript, unless you're willing to defer debugging to someone who does. If we're already willing to learn both languages and then spend time reading and debugging compiled JavaScript, why not just write good JavaScript from the start? For the extra effort you'll make learning CoffeeScript and its idiosyncrasies, why not put it towards really learning JavaScript?

The problem is that many programmers are turned-off by the lax nature of JavaScript and translate this into a shortcoming when writing large JavaScript applications. What you're really doing is giving up on a language that is brilliant for that very reason. Sure JavaScript has its share of problems, but they are all issues that are workable given enough knowledge and the use of a proper framework.

While frameworks help, some also serve to propagate this JavaScript stereotype. jQuery is a perfect example, as it does a brilliant job of eliminating cross-browser inconsistencies and makes DOM manipulation a snap, but does little to improve the overall structure of your application. A relatively small number of companies have sought out frameworks that aim to address the spaghetti problem, while the rest quickly realize that their jQuery code has become an unreadable mess. The reason these things happen - and it's the source of most problems with JavaScript - is because people simply don't know JavaScript. I've written at length about the JavaScript knowledge gap and the ad-hoc school of learning so I won't dwell on it here, but I urge you to ask yourself whether a move to CoffeeScript is sign that you've given up on learning it properly? Is it a problem with JavaScript or a lack of understanding?

As of writing this, I've written more lines of JavaScript than I care to admit. In fact our entire web front-end is written in JavaScript, and not once has our team had problems with maintaining our JavaScript code. In fact, despite our massive JS code base, we rarely have problems caused by the very things that CoffeeScript aims to eliminate. The main reason for this is that we've enlisted the help of a framework that brings structure to our application. Our choice was Dojo but you could also choose Require.js (a close relative of Dojo's class system), backbone.js, the Sencha framework, and many others that you can use in combination with jQuery (if you so desire). The other reason is that we've forced our developers to gain a deeper understanding of JavaScript and built a set of best practices that everyone follows which help to produce a consistent and high-quality result.

Before you delve into the world of "compline to JS" languages, I urge you to check out some of these structural frameworks, pick up a copy of JavaScript the Good Parts, and re-evaluate your decision. If after all this you still feel that the syntactic advantages of CoffeeScript et al. warrant the move, then by all means dive in. I simply ask that you enforce a good degree of JavaScript knowledge from your coworkers, and make the move for the right reasons, not because you're running away from JavaScript. JavaScript is the language of the web, and its understanding is further jeopardized by delegating another language to write the code for you.

If you liked this post please follow me on Twitter for more.

Saturday, October 29, 2011

AdWords Is Not A Marketing Strategy

For all the startup hopefuls expecting Google AdWords to serve as your primary marketing channel and lead you to quick and easy riches, you better think again. What you're more likely to find is high cost per clicks, low click-through rates, and even lower conversion rates. That's not to say that AdWords is all bad, it's actually a great tool for discovering what keywords your target audience is using in association with your product, but from then on it's up to you to grow through other means.

25 cent cost per clicks have grown to $2-$6, and people's natural ability to ignore advertisements result in paltry click-through rates. Running several experiments over a two week period yielded a 0% conversion rate on 200+ clicks across multiple keywords and nearly $300 spent. In comparison, over the same period, the inherent network effects of our application resulted in a 10%+ conversion rate at a cost of $0.

The key problem with AdWords is that it's a terrible tool to use for marketing a product that doesn't have an established market. If people don't know that the market exists, they can't search for a product that services that market. Fortunately for me, I used AdWords as an experiment to prove this very point, so the loss of $300 can be viewed as market research cost rather than a sunk one.

This is why it's extremely important to find what Eric Ries calls the "engines of growth" for your company. It's not enough to simply build a great product and expect that search engine traffic will do the selling for you. You need to understand the market you're entering and the best way to reach and grow your user base in that market. AdWords is also an expensive way to acquire customers, so you'll have to consider the lifetime value of a customer against the average acquisition cost to determine if it's viable. On the plus side, AdWords is great for running keyword experiments to determine the number of impressions various keywords garner and which generate the highest click-through's. The challenge is determining which clicks actually correspond to your product offering, which would typically be measured via the conversion rate. The problem here is that low volume of click-through's make for poor statistical data, and there is always the chance that your website copy fails to properly convey the value proposition. That being said, these experiments are best run once you've had a chance to perform some degree of quantitative and qualitative optimization on your landing page.

Don't get me wrong, AdWords still has value, otherwise companies wouldn't spend billions of dollars on it. Just expect to compete fiercely for clicks, pay heavily for them, and fail miserably if you're establishing a new market. So my advice for most startups is fight for organic traffic, get social, generate referrals, build virality into your applications, and use AdWords as an experiment rather than a strategy.

If you liked this post please Tweet it, or follow me on Twitter for more.

Sunday, October 23, 2011

The Lean Startup Book - Reviewed

Having been a fan and advocate of the Lean Startup movement for some time now, I've been anxiously awaiting the release of Eric Ries' book ever since its announcement. Given the high quality of Eric's blog posts, it's needless to say that my expectations for the book were quite lofty. I'm happy to state that it delivers on those expectations and brings a fresh perspective to the subject, even for long-time Lean Startup practitioners. In fact, it's not a stretch to say that the Lean Startup book will join the ranks of tech circle bibles like The Innovator's Dilemma, Crossing the Chasm, and Inside the Tornado.

For those expecting a detailed step-by-step roadmap of the Lean Startup, you're likely to be disappointed. The subject is simply too large to be covered in one book, and many of the individual concepts have already been covered in other sources (Eric does a great job of suggesting further reading). More importantly, the Lean Startup is not a laundry list of steps on the path to success, and the book never presents it as such. What it does is lay out a framework with which you should approach your startup, and some specific considerations that need to be made throughout its evolution. It succinctly ties together many of the concepts presented throughout Eric's blog, but does so in a manner that doesn't feel repetitive. Having read his blog in its entirety, I rarely found myself reading material that I'd heard before, and was often presented with ideas for the first time. Furthermore, Eric does a good job of reframing some of the more familiar material and making it clearer through context.

The most interesting idea in the book - and it's one that somehow eluded me until this day - is that of the growth hypothesis. Loyalists of the Lean Startup are no doubt familiar with the idea of the value hypothesis, which serves as the foundation for the minimum viable product, but until now, little has been written about what Eric calls "the engines of growth". Although several articles have been published about retention metrics, net promoter scores, etc, I've never seen it framed in such a clear manner. The growth hypothesis serves as a complement to the value hypothesis and aims to discover the best way to reach and grow your customer base, and to rigorously test this alongside your value proposition. These two concepts occupy a good chunk of the book and are described in detail, alongside many real-world examples which crystallize their meaning. The concept is then solidified with one of Eric's most profound and enlightening statements: "Sustainable growth is characterized by one simple rule: New customers come from the actions of past customers", the explanation of which I'll leave as a lightbulb moment to prospective readers. This is just one one of many statements that will leave you pausing and reflecting on your own situation or past decisions and seeing them in a new light.

I'll end this review by highlighting one point that is laid out in the book from the outset. An entrepreneur is not someone who is starting their own business. It's anyone that is creating a product or service under conditions of extreme uncertainty. The reason I emphasize this is that many of you may feel that "I work in a big company, these concepts don't apply to me", and skip the book entirely. If you operate under such conditions, in any company, big or small, I strongly urge you to read the book and spend time reflecting on its ideas. In fact, Eric has done a great job of providing examples of the Lean Startup in the context of large organizations such as Intuit and IGN, and devotes the last few chapters of the book to this very topic (this serves as a good complement to the Innovator's Dilemma). The book is well written, engaging, thought provoking and enjoyable, and most importantly it sheds some new light on the revolutionary concept that is the Lean Startup.

If you liked this post please Tweet it, or follow me on Twitter for more.

The book can be purchased on Amazon here.

Saturday, September 10, 2011

2 Years of Programming in 4 Months

If you're hoping for some revolutionary method to drastically accelerate your programming, I'm afraid you won't find it here. What I'd like to share is how we managed to accomplish in 4 months what previously took us 2 years, and do it much better.

Several months ago we made the decision to completely re-write and re-brand an application that we worked on for over two years. The decision came as a result of gradually adding features without a complete understanding of what was really needed and what customers actually valued. Fortunately over the last few years we learned exactly what it is that people like about our software, and what they're willing to pay for. We had a substantial user base that we built up with little to no marketing, no real brand, all in a relatively concentrated geographic area. The benefit of this was that we were able to learn and make changes without affecting too many people. Furthermore, we were able to maintain a close relationship with the clients we did have and find out what their pain points were.

Armed with a good understanding of the market and what is needed to succeed in it, we decided that it's time to begin scaling up. Despite this ambition, our existing product was not up to the task. After years of adding features on a case-by-case basis, the UI was a fragmented collection of features, usability was a concern, as was application architecture. The decision was finally made to start over, and 4 months later, a brand new product was born. While we still have a long way to go, what was accomplished in a short period of time was truly astounding, and customer feedback has been overwhelmingly positive. So without further ado, what allowed us to accelerate our development so much?

I've written before here about the advantages of building your web application atop a REST API, and I can say with strong conviction that this was a major contributing factor to our accelerated development. This approach made development more enjoyable and left us with a well structured and high performance back-back. We were able to pack a tremendous amount of functionality on each page without having to worry about how the pieces interact. Each component had it's own JavaScript objects and dealt with its own API, so each problem could be dealt with individually. The stateless nature of REST has made debugging a breeze because the path from the client side to our data access layer is clear, and consistent. Furthermore, we've been able to reduce the memory usage of our Tomcat server by a factor of 3 thanks to removal of session level data.

A Pure JavaScript Front-End
Related to our REST-centric approach is building the front-end entirely in JavaScript. Six months ago I began playing with the Dojo toolkit and fell in love with the simplicity it brings to creating rich and interactive user interfaces. When coupled with a good deal of CSS, very little JavaScript code is actually needed to create the UI components for even the most complex pages. By building the entire UI in JavaScript we no longer have to rely on ID's or classes to reference elements and instead we can maintain pointers or utilize closures to modify the state of various elements and respond to events. As I've written about before, Dojo's event handling mechanisms allow you to create well structured and highly maintainable UI classes so I highly recommend checking it out.

One of the greatest benefits of a pure JavaScript UI is the ability to create reusable components that you can drop-in wherever they're needed. Thanks to Dojo's class system, we created base classes for everything from modal dialogs, to REST communication layers, all the way to large UI elements. For example we noticed that our client has to choose users in several areas of the application, with only minor variances in each one. Before we were writing a separate user selection mechanism for each context, but this time we simply created one incredibly powerful and extensible user picker modal dialog that we reused over 10 times in the application. This has obvious usability benefits as the user only needs to learn how to use it once, and can benefit from it throughout the application. Half way through our development we amassed such an extensive set of base classes and components that it more than doubled our rate of development.

The Right Team is Everything
One huge advantage we had today as opposed to two years ago is a fantastic programming team. Each person has a unique set of strengths, a desire to learn new techniques and desire to write a high quality application. Skills on their own are great but the real acceleration occurs when those skills come together as a complete team. A team that shares the same vision, the same goals, and most importantly embraces the culture in the company. Despite working long hours and being tired, everyone was always smiling and cracking jokes, and this positive attitude was visible in the final product.

Hire a Good Designer
In the past we got by with doing our own designs and css development, not necessarily because we wanted to, but because it's not easy to find a good designer. Fortunately we were able to find one and I'm constantly amazed at how much quicker the design and implementation of a page comes together, and how much better it looks. Most developers hate fumbling around with colours, graphics, and writing CSS that works across various browsers. Freeing them from this allows them to focus on doing what they do best. While I've read several articles where it is suggested that startup owners try to do their own design at early stages, I would advise against this in all but an early prototype. If you find a good designer, hire them. It will save your developers a lot of frustration, accelerate development, and produce a much more beautiful product.

Embrace the Lean Startup
Focusing on a minimal set of features and having an understanding of where the value of your product lies is essential. Not only does it reduce the actual amount of work needed, the motivation it provides is equally important. While the value of most features that we previously developed was questionable, knowing that a specific feature is valuable to the client motivates the developer to do it well and do it fast.

Quality is a Motivator
Knowing that every feature that went into our product was valuable, we wanted to create a product of the highest quality. No corners would be cut, the user experience would never be compromised to save time, and that the look and feel be perfect. Despite this fanatic focus on quality, the pace of development only got faster. As development progressed and the product came together, we realized we were working on something special, something that looks beautiful, that's fun to use, and something that we can all be proud of. Mediocrity doesn't motivate, being a part of something unique and amazing does. Keep in mind that you should only obsess about the details and strive for perfection when you've verified that your value proposition and business model are sound. As the lean startup suggests, it's not wise to invest in perfection at the outset, just make it look decent and figure out if anyone wants it.

Embrace Agile
I shouldn't really need to mention this one but I think it's important to emphasize for those still stuck in the world of waterfall methodologies and 500 page product requirements documents. Although we knew exactly what our application needs to have, we didn't opt for a big design up front approach. We created the vision of what we want to the product to be and what it needs to have, but the design of each feature happend just before implementation. This proved extremely valuable as we learned new approaches, had new components, and continued to learn from clients and each other right up to the last day. Arm yourself with use cases, embrace Scrum, and watch your productivity soar.

Slowing Down is Speeding Up
Rapid development is not about being a slave driver. Take the time sit down and reflect with your team, toss around ideas, enjoy a coffee together, and spend lots of time on design. You'll learn a lot from each other and a good design will pay dividends during implementation. Typing away at a keyboard all day long leaves little time to think so create an atmosphere where employees feel it's ok to sit at their desk and just ponder. If they're tired one day and need to leave at 3:00, they should feel comfortable in doing so. Sometimes you just need to slow down in order to speed up.

While your situation may be different from ours, or you may find yourself at a different stage in your business, I'm confident that embracing at least some of these suggestions can help you increase the pace of development, produce a better product, and create a more enjoyable journey for your team.

If you liked this post please Tweet it, or follow me on Twitter for more.

Thursday, August 25, 2011

What We Learned From Steve Jobs

With Steve Jobs' passing of the torch, I think it's appropriate to reflect on the lessons we've learned from him and Apple over the years. Here are some of the most notable lessons that we can all use every day:

  • Good is never good enough, always strive to be great
  • Get good at saying no. Saying no is hard but it's the no's that will define the success of your business.
  • Screw featuritis.You can achieve great success without having every feature imaginable. Do what's really needed, and do it exceptionally well. 
  • Marketing and showmanship do matter. This is not to say the product can be mediocre, it can't, but how you position it is equally important. 
  • Your passion is reflected in your product, so don't do something if you're not passionate about it
  • Don't believe those that tell you something can't be done. Nobody believed Steve Jobs could get a fragmented and stubborn music industry to agree to iTunes, but his perseverance and tenacity ultimately won out. 
  • Don't just fixate on the product, your positioning, experience, and message must be consistent across everything you do. Apple feels like Apple in its hardware, software, packaging, accessories, website and stores.
  • Design matters... a lot! We live in a superficial world and people love things that look great. The practicality and durability of Apple's designs is often questionable, but people look past it and fixate on the beauty.
  • Usability is cool. I strongly believe that the recent rise in usability and user experience is largely attributed to Steve Jobs and Apple, and for this I thank them. 
  • Timing is everything. Apple didn't invent the touch screen phone, the mp3 player, or the tablet PC. What Apple did was wait until market conditions were perfect to introduce these devices. 
  • Almost every industry is ripe for change, don't believe in the status quo. Apple has become the most valuable company in the world by competing in existing industries and taking them by storm. 
  • Don't ever give up. From being ousted to cancer, to picking a company up from the brink of collapse, Steve Jobs never quit, neither should you. 
  • Have a grand vision. I have no doubt that when Steve Jobs begin working on iPod, he already planned how he would parlay its success into the Mac line and other products. Don't just think about your product, think of the big picture and the ecosystem that can flow from it. 
  • Turtle necks are cool?
I hope that Steve Jobs' legacy will carry forward not only at Apple but at more companies across the world. Even if you're not a fan of Apple or their products, the changes they've brought about have had a profound impact on our lives and transformed industries. Let's take these lessons and change the world by making products people are passionate about and love to use. We'll miss you Steve. 

If you liked this post please Tweet it, or follow me on Twitter for more.

Tuesday, August 2, 2011

These Twitter Numbers Don't Stack Up

A recent report found here announces that Twitter recently raised $800M in venture capital, $400M of which goes to the company while the other $400M will be used by employees to cash out some of their shares. While the figure raised is impressive, the claim that Twitter has revenues of $200M per year raises a number of questions. These figures are either incorrect or it makes you really wonder why they need venture capital in the first place.

Let's consider that a recent report published that the average developer salary at Twitter is $125k (found here) and the report in question claiming that Twitter now has 600 employees. Based on these figures Twitter spends roughly $75M per year on salaries. That leaves nearly $125M per year to cover the costs of increasing hardware demands, rent, and miscellaneous expenses, which seems quite high for costs that are often proportionally lower than employee salaries.

The justification is that Twitter needs to expand its workforce to expand internationally, and so it needs the injection of capital to cover the associated expenses. The problem with this claim is that given Twitters lofty valuation and increasing Tweet and user figures, you would expect that the revenues will continue to increase at a rapid rate. Since revenue is increasing it should suffice to cover the costs of an expanding workforce along with the international expansion. The better question to ask is whether Twitter actually needs more than 600 employees, does it even need 600? A look at 37 Signals shows that a great company can be maintained with a 10-20 people, while most startups have only a handful of developers. Sure Twitter has scaling issues that it needs to deal with, data that it needs to comb through, multiple client versions, but it still seems excessive. My worry with excessive funding is that it takes away the need to be lean, the need to survive dwindles, and focus often gets lost.

I'm not saying Twitter is doing the wrong thing by taking the money, but at $200M in revenue I would have to have a pretty good reason to further dilute my shares. As with most companies I suspect that Twitter simply took the money because it's being offered. There's likely no solid justification for it other than to publicize how valuable the company is, and to handsomely reward its employees with cash for their shares.

If you liked this post please Tweet it, or follow me on Twitter for more.

Thursday, July 28, 2011

The Bright Side for AirBnB

Following the destruction of a renters home, many people have questioned how AirBnB will do going forward, and view it as something of a turning point for the young company. I would argue that although the act itself is terrible, it may actually help AirBnB in the long run. While the rental industry as a whole will be at least temporarily damaged by the incident, I suspect that other rental avenues will suffer more than AirBnB. As we know AirBnB acquired a large portion of the rental inventory from Craigslist and it remains today that Craigslist hosts a good number of rental opportunities. My suspicion is that such independent rental avenues will suffer more as there is little accountability should something go wrong. AirBnB has taken a proactive approach and are working to make the situation right so renters are at least assured that if something like this does happen, the company is there to support them.

Given the rarity of these events, it also presents a new opportunity for AirBnB to provide an insurance option for renters to help further compensate them for any damages. Such an service should be in addition to their standard response of replacing belongings and bringing culprits to justice, but it would provide an additional level of comfort to renters and further add value to their service.

While we can speculate that the rental industry will never be the same, we have to remember that painful events like this find themselves in our short term memory (though certainly not for the unfortunate victim). Provided we don't see an increase in such occurrences and a successful resolution to the current situation, AirBnB and the rental industry should continue to prosper. Sad as it is, AirBnB had to go through this problem to learn how to deal with, and prepare for it in the future.

If you liked this post please Tweet it, or follow me on Twitter for more. 

Friday, July 22, 2011

The Joy of Event-Centric JavaScript

While you've no doubt used JavaScript to connect to events fired by DOM elements, I've found the idea of extending the events based model to my own objects and methods extremely useful. The concept is heavily used throughout the Dojo framework, as each Dojo widget throws its own set of custom events that other objects can connect to. I largely ignored this idea for some time, and continued to toil away by maintaining pointers between different classes and calling their respective methods when I needed them to do something. The problem with this approach is that it tightly couples the classes and makes them less re-usable. The objects must know a good amount about each other and expect to be used in certain contexts, with little opportunity for re-use. Once I began writing large, long-lived JavaScript interfaces this approach became unsustainable, thus forcing me into the event-centric model I will describe.While my examples are Dojo based, you could apply the same ideas to jQuery or even bare JavaScript by writing some non-trivial helper code (anyone know of any existing options please provide them in the comments). That being said Dojo really does an excellent job at this so you may want to consider using Dojo core, if for this reason alone (although there are many great things about Dojo).

Custom Event Basics
For starters let's look at a typical example of where custom made events are very useful. The most common case is where we have a list of items in one class, with each item in the list represented by another class.

//A simple item in a list. Extends a custom class of ours
//called EventManager which we'll talk about later
dojo.declare("my.example.Item", [my.base.EventManager], { 

  //The constructor
  constructor: function(args) { =; =;

  //Event fired when the item is deleted
  onDelete: function(item) {

  //Fired when a server request fails, let another class handle displaying errors 
  onRequestFailed: function(item, operation, error) { 
   //The list class can either connect to the onRequestFailed method, or to this pubSub
    dojo.publish("my/example/item/request/failed", [item, operation, error]);

  //Make a call to the server to delete the item 
  deleteFromServer: function(args) {
    //Make your AJAX request
    if (success);
      this.onRequestFailed(this, 'delete', response.error);

  //Build the UI for our class
  buildNode: function() {
    //Naturally your UI would be more complex than this
    var domNode = dojo.create('div', {className: 'myItem'});
    dojo.create('span', { innerHTML: }, domNode); //Add the label
    var delA = dojo.create('a', { innerHTML: 'delete', className: 'deleter' }, domNode);
    //Connect an on click event of our delete anchor
    var handle = dojo.connect(delA, 'onclick', this, function(evt) { 
      //Do some fancy stuff like adding a loading icon or message
        scope: this,
        onComplete: function() {
          dojo.destroy(domNode); //Remove the UI piece
          dojo.disconnect(handle); //Cleanup our on click handle
        } //end onComplete
    //Listen if someone calls the destroy function, in this case we remove the DOM node
    var destHandle = dojo.connect(this, 'destroy', this, function() {

  //destroy: function() {} <= defined in EventManager base class

//A class representing our list of items
dojo.declare("my.example.ItemsList", [my.base.EventManager], { 

  //The constructor for our list editor
  //To create it you'll create a new instance of my.example.ItemsList
  //Then call .startup();
  constructor: function(args) {      
    //In this case we'll use pubSub to demonstrate it
    this.subscribeTo("my/example/item/request/failed", this, function(item, op, error) {
      //Alert the user that a server update failed on an item

  //Fire up our list editor 
  startup: function(items) {

  //Add a single item to our internal storage
  _addItem: function(rawItem, insertInto) {
    var item = new my.example.Item(rawItem); //Create our Item object
    this._itemsById[] =  item;//Store the item in the hash by its id
    //When it's deleted we remove it from our store
    item.connectTo('onDelete', this, function(deleteItem) {
      delete this._itemsById[];
      deleteItem.destroy();//Call to EventManager, cleanup all event handles

    //Could have also connected to onRequestFailed here if we didn't use
    //the pubSub that you see in the constructor

  //Add the items to our object regardless of the source
  setItems: function(items) {
    this._itemsById = {}; //New hash for our items
    var that = this; 
    var frag = document.createDocumentFragment();
    dojo.forEach(items, function(item) {
      that._addItem(item, frag);

  //Grab the entries from the server
  fetchItemsFromServer: function() {
    //Use whatever method you like to fetch data from the server via an AJAX call

  //Build the necessary UI components along with a node to hold our list
  buildUI: function() {
    //Build a bunch of nodes here
    this.listNode = dojo.create('div', {}, somethingToAppendTo);

  //Overwrite the destroy method in EventManager, cleanup
  destroy: function() {
    for (i in this._itemsById) {
    } //end for
    delete this._itemsById;
    //Call to super method in EventManager, cleanup up this classes handles

Although the above example is relatively basic, and your case is sure to be more complex, it nicely demonstrates how to use custom events as well as pub/subs in an event-centric context. The great thing about this approach is that the Item class doesn't have to know anything about the class that uses it and so it can be re-used in many different contexts. I've done this in many cases, most commonly with an object and its corresponding UI being embedded in different containers such as a modal dialog versus a node on a page. The power of this approach grows exponentially with the size of your application, and the complexity of your page, so while it may not seem terribly helpful in the above example, I promise you it's a lifesaver.

The additional benefit is that it makes reasoning about problems and logic much easier. You no longer have to keep in mind multiple classes or methods when responding to a method call or state change. You merely respond to that stage change in each of the locations that are affected by it, each piece handling its own logic and nothing more. In the example below we can see how useful this is when we have a typical property setter method.

//A simple item in a list. Extends a custom class of ours called 
//EventManager which we'll talk about later
dojo.declare("my.example.SampleItem", [my.base.EventManager], { 

  //The constructor
  constructor: function(args) { 
    dojo.mixin(this, args);//Copy the arguments into our object

  //Event fired when the item is deleted
  setName: function(name) { = name; 
    //Notice set name doesn't care about anything other than setting the property

  //Build the UI for our class
  buildNode: function() {
    //Naturally your UI would be more complex than this
    var domNode = dojo.create('div', {className: 'myItem'});
    var label = dojo.create('span', { innerHTML: }, domNode); //Add the label
    this.connectTo(this, 'setName', this, function(name) {
      dojo.attr(label, 'innerHTML', name); //Update the UI thanks to the label closure
    //When the classes destroy method is called, delete the UI components
    this.connectTo(this, 'destroy', this, function() {

  //Inherited destroy method in our EventManager does the cleanup

Once again, the UI related changes are dealt with by the method that created the UI and the node pointers are reference by the closure so we don't have to store any object level node pointers that are used throughout various methods. Our code remains nice and clean, and highly readable.

Pub/Sub vs. Events
As you can see in the first example, we used a mixture of regular event connections and Pub/Subs, so the question is which one do you use and when? What I've found works best for me is to always start with a standard event connection and then consider the following:
  • Is it too onerous to maintain these event connections or do I have to setup too many of them?
  • Do I or will I have a one-to-many, or many-to-many relationship between my components?
  • Do I need to propagate an event far down a chain of connected classes where a low level class may not know that the firing object exists, or know anything about it for that matter?
  • Will multiple object types be firing this type of event, and if so, do I want my handler to know about all of them?
  • Do I want the loosest coupling possible?
The above are all good reasons for choosing pub/sub communication over maintaining event connections, so always evaluate what the easiest and most pragmatic choice is for your situation. With pub/sub communication, it is especially important to disconnect handlers as they may fire at strange times and lead to unexpected errors. For example let's say you have a modal dialog listening to various published events and the user then closes the dialog. Now if you fail to disconnect the subscribe handles and some other elements on your page begin publishing the event, the dialog object may still exist in memory (even if the dialog DOM node's are destroyed) and may try to respond to the event. In this case the DOM nodes that need to be updated no longer exist, thus leading to some unexpected errors. For this we utilize the below helper class and its subscribeTo method.

A simple event management base class
In the examples above, I've used the event manager base class to help with managing some of the event handles that result from making Pub/Sub or standard event connections. Although Dojo cleans up all handles when the page is reloaded, long running pages require manual event cleanup to help with garbage collection, and this is where our event manager comes into play. Each time we call connectTo or subscribeTo on an object that extends EventManager, the manager stores the resulting handle in an array so that it can clean them up when the item is destroyed.
dojo.declare("my.base.EventManager", null, { 

  "-chains-": { //chain the destroy method to ensure it's called by sub classes
    destroy: "before"

  //The constructor
  constructor: function() { 
    this._em_events = [];
    this._em_subscriptions = []; 
    //You can use a map here as well (see disconnectEvent) 
    //this._em_events = {};

  //Add an event or subscription to our list of events being tracked
  addEvent: function(/*Event or Subscription handle*/ eventHandle) {
    //Quick check for handle type, event handles have a length of 4, subscribes are 2 
    var ref = eventHandle.length == 4?this._em_events:this._em_subscriptions;
    return eventHandle;

  //Disconnect a specific event or subscription
  disconnectEvent: function(/*Event or Subscription handle*/ eventHandle) {
    //Quick check for handle type, event handles have a length of 4, subscribes are 2
    var ref = eventHandle.length == 4?this._em_events:this._em_subscriptions;
    //If you make frequent accesses to this method use a map instead of an array
    //for storing handles, this would obviously become a "for x in ref" instead
    for (var i = 0; i < ref.length; i++) {
      if (ref[i]=== eventHandle) {
        ref[i] = null;

  //Connect to an event that the extending object throws
  connectTo: function(/*String*/event, context, /*Callback Function*/func) {
    return this.addEvent(dojo.connect(this, event, context, func));

  //Connect to a published event and keep track of it
  subscribeTo: function(/*String*/eventName, context, /*Callback Function*/func) {
    return this.addEvent(dojo.subscribe(eventName, dojo.hitch(context, func)));

  //The important function, do the cleanup when the object is destroyed
  destroy: function() {
    //Automatically gets propagated to parents since we added it to the chain
    dojo.forEach(this._em_events, dojo.disconnect);
    dojo.forEach(this._em_subscriptions , dojo.unsubscribe);
    delete this._em_events;
    delete this._em_subscriptions;

Some closing thoughts
While your able to get away without an event-centric approach in many cases, as the scope and size of your application and components increase, you'll find it more and more difficult to keep your code organized and re-usable. While this approach is incredibly powerful, it's also important not to overuse it and begin creating connections at every turn, as debugging will start to become more difficult beyond a certain point. If you choose to adopt this approach, be sure that it's something that utilized by your whole team as it requires a very different approach to writing and debugging the code. Your team has to stop thinking in a linear fashion and understand that there are several points that can be affected by a method call, not just what's in the method itself. As a best practice, try to constrain your event connection to setter methods and any method that begins with "on" so that it becomes easier to infer which methods may have connections to them. If you're anything like me, once you've made the switch to event-centric JavaScript, you'll wonder how you ever did without it.

If you liked this post please Tweet it, or follow me on Twitter for more.