Startup Weekend

16. February 2012 14:57 by Uriah in   //  Tags:   //   Comments (0)

Last weekend, I participated in Twin Cities Startup Weekend and wanted to capture a few thoughts about the process.  I went with Trent and we offered up our services as developers.  For those unfamiliar, the process basically goes like this:

  1. People pitch ideas for startup companies.  These can be all over the board, from ideas that people have been kicking around forever to spur of the moment.
  2. The ideas are voted on to pick the best by popular opinion (and coercion and cronyism in some cases).
  3. Teams form organically around skillsets and interest.
  4. Work like mad for 30+ hours getting an initial product going.
  5. Demo the product to a panel of judges and maybe win a nominal prize.
We picked a startup idea based around aggregating clearance items from local retailers so that people can bargain hunt.  It sounded fun, unique and well suited to our abilities.  I'm really happy with our choice and proud of what we are able to accomplish in such a short amount of time.  The site ended up being called Froogify but we took it back to stealth mode after the demo.  You can sign up to find out about it at www.froogify.com.
 
Some thoughts about the weekend:
 
Startup pitch versus product - The tone of the event was different than I had imagined it would be.  I came prepared to make something that could be used, but most of the focus seemed to be on making something that could be pitched to VCs.  It didn't matter if it worked or how deep the feature set worked.  In short, it was not a maker's event which I should really not have expected it to be, but it did get me wondering if there was a venue for something more about building and less about selling.  Would anyone else be interested in more of a code jam type of event?  Keep an eye out for more from me on this topic in the future.
 
I need to pitch something - I've been kicking around a lot of ideas for a long time.  It would really be fun to see one of them come to fruition through this event.  If you want to pitch something at one of these, let me know and I'd be happy to talk about it and give some strategy in advance.
 
With drive accomplishment explodes - Our team was energized and enthusiastic and we accomplished more in 36 hours of development and business work than some businesses do in a month.  Sure, we cut a lot of corners and really focused on a minimally viable product, but still it was crazy fun to be a part of.  Clearly working that amount of time in 2 days is not a sustainable rate, but if you could keep a team really jazzed about what they were doing you could harness some of that magic.  Figuring out how to motivate people to that level of intensity is a real trick though.
 
This is a different skillset - Most of my programming in the last 15 years has been in environments that valued correctness and stability over speed.  I don't have enough tools in my toolbox for these types of situations.  It was humbling to work with the amazing Eric Brandes who kept pulling quick tools out of his bag of tricks.  I really need to expand my repertoire and pull in more of these quick tools that make building things fast a lot easier.
 
Prebuild - There was some talk that the eventual winner of the competition had built most of his software beforehand.  At first, I found that a bit offensive, but then I accepted the nature of the event and the fact that creating a working product wasn't exactly the focus.  The take away is that I will come into the next event with more prework done.  I don't know what I will be building, but having a database, source control and maybe a few project templates set up beforehand wouldn't be too hard and would have saved an hour or two.
 
Overall - This was an exhausting, all consuming weekend that was an absolute blast.  I'm super excited that our business owners for the startup seem interested in carrying it forward and making it a real product.  We didn't win the competition, but these guys seem to have the drive to succeed that could make this thing work.  That would make me immensely satisfied.  Regardless though, I will be back next year to see if I can help launch someone else's dream (or maybe my own).

The Cost of Everything

31. December 2011 05:51 by Uriah in   //  Tags: , ,   //   Comments (0)

I've been thinking a lot lately about web pages that do too much in a single page or what I call the "everything page" and what it really costs to develop and maintain one. It's a topic that Trent and I have also been talking about in terms of web development being developing sites as a collection of pages (e.g. your typical shop cart checkout process) versus web applications that function more like a traditional application where a main window is represented by a single page (e.g. the Gmail interface).

It seems that in the majority of web applications I have worked on the paradigm is usually several pages that are smaller in complexity and then one or two pages that are real doozies. Often times the complex pages don't start out that way but as features get added, things have a tendency to compound. Whether they start out that way or end up that way, I'd argue that getting a handle on that complexity and finding a way to reduce or manage it is critical to keeping down the cost of development and future support. 

So how do we deal with these monster everything pages to make sure they don't cost us an arm and a leg?

One approach is to go to lengths to make sure that your page is developed in a modular way. Whether they are webparts, user controls, partial views or whatever your paradigm might call them, having some way to divide the problem space mentally is going to save a lot of trouble in the future. If you can remove dependencies from one part of your monster page on another, it might take a little more effort initially but will pay off when your page can be maintained without hours of study beforehand.  There are obviously varying levels of this approach, including the following examples: you could have each chunk of functionality include all it's necessary javascript, styles, and even submit independently, or you could have defined communication channels between your subsections.

The other approach I would mention is related but one that is often a harder sell. You should consider how you can break that page apart into multiple pages. A product owner or business stakeholder might make an assumption that having everything happen on a single page is just as easy as having a multiple step process (with all that "annoying clicking" to navigate). What is the real cost of cramming a ton of functionality into an everything page versus spreading it out into smaller pieces and do the stakeholders know? For example, if you have 4 pages that each take 5 hours done separately, would you consider putting them into a single page if it instead took 40 hours and all future maintenance took twice as long?  Depending on the UX demand, the answer might be yes, but I don't think this cost gets factored into the decision often enough.

As a side note, we should be aware of the cost of an iterative approach on web development. Iterative development is my preferred approach, and I think in most cases it proves to be quite valuable. Iterative development is dependent though on the design and tools that support it. Having modular code that is easy to change and refactor is key as well as having quality automated testing so that you can find regression problems quickly. Both of those qualities are necessary to confidently make drastic changes but are missing from web UI development. They can be achieved to some extent by using frameworks and trying to create using patterns, but it still feels too cumbersome and fragile to me. Unit testing of javascript doesn't seem to add enough value for the effort. Maybe I'm not trying the right tools, or maybe just the messy interactions with the DOM are too much to deal with easily (anyone have a different experience?)  Iterative development in this case can lead to a lot of hacks when developers are afraid to change code because of a lack of complete comprehension of the page and its interactions.  Both of the solutions above help to address this tendency by keeping things simpler and easier to change.

The most important thing you can do though is to recognize right away when you have an everything page in the works so that you can start to think about ways to manage the complexity and keep the true cost of the page under control.

Q: What did the Zen Buddhist say to the hot dog vendor?

A: Make me one with everything.

(x-a)^2 + (y-b)^2 = r^2

RecentPosts