29 March, 2008

"bet the farm moment"

You'll recall from this post, that I had decided to mount up my trusty steed and head down the road of venture capital and angel investment hunting about 2 weeks ago. It turns out that process is far more difficult than I thought it would be. I had the idea that IT folks would be willing to take a look at the implementation of my technology and be in a position to enter into an agreement to provide a portion of the funding. It just turns out that getting eyes on your product is not easy, even in the internet age. The first worry I had was the fact that most VC's wanted to see a business plan or an executive summary before they even agree to anything. Though my executive summary was general in its description of my business ideas, the business plan is quite detailed. I kept thinking, what is to stop them from passing that plan along to a few geeks they have waiting and funding their own version of my plan idea? The internet is filled with stories that go both ways, of investors that claim their inventions were stolen by people they presented to, and by investors in the industry claiming they have no desire to do such things. I decided after all this reading that it was simply not worth it, to show them my secret sauce. Now most VC's only ask for an executive summary, and I did send out about 8 of these before I decided to quit but I still feel as if I let my genie out of the bottle a bit by having sent it to these guys.

I also considered getting a small business loan, but quickly found out that there is a catch22 in place. Most banks (though I only visited one) want to fund already profitable businesses, since mine has no profit yet I could get no small business funding from them. So that option was quickly invalidated. I also had some interest expressed by some acquantances and family members as angels but they both fell into financial straits that prevents them from contributing. I'd been so focused on development that I've done little networking in the field in the last few years so essentially, no one (anyone that would be in a position to fund the launch) knows who I am. I concluded that if anyone knows the potential of my technology it is me, and by understanding my industry and the niches that my product and services was designed to appeal to, I have a level of confidence that the VC's could never see, even in a well written executive summary. All that said, I didn't get a single bite from those 8 or so VC reach outs, but that was not the reason why I decided to self fund, the reason mainly is simply one of pride. I worked hard on the technology to make it what it is and I should reap all rewards for its success and likewise bare all responsibility should it fail. I also feel that it would be unfair to me, to cop out by having a VC fund the project at the cost of a significant loss of my ownership of something I created 100% if it succeeds. One of my strong beliefs is that being independent of the monetary concerns of any investors is critical to allowing me to cater to the needs of the customer FIRST, before any other considerations. When you go VC, no matter how much you try, there will come time to make decisions that punish the customer because the investors want to save their rumps in some way or boost profit in a way that is not aligned with the original vision of the product or service. Self funding ensures I am the only captain on the ship, and there won't be any mutinies.

So, having mulled all this, I thought to myself ...how do I self fund if I am flat out of money? I have whittled away just of $70,000 on the development process while in stealth mode for the last 6 years. That includes my living expenses, a car bought and trashed and a European vacation. I realized I might have had the funds for the self funding if I hadn't put so much money in the stock market, oh well one of my financial mistakes from the last 7 years! Regardless, I have a few thousand in cash and all my other money is untouchable in retirement savings. What to do??? Eureka! I remembered that I had two credit cards, both started when I was in college. In fact these two cards were part of my plans just before graduation to get a college loan and use it to pay for a brand new computer, that I could then employ in my post graduation job hunt. It turned out to be an excellent investment at the time and it worked! The credit card accounts were opened up to pay for the computer parts which were successfully used to land my first post graduate job, but today over 10 years later, those cards are my salvation. Fastidious attention to paying my balances in total every time I had them, allowed the credit limits on both cards to rise steadily. Combined both cards provide me with $30,000 of credit equity.

As loath as I am to fund my site launch on credit cards, it provides me several advantages that I could not otherwise get if I pursue the VC route.

  1. Time, I don't have time to spend hunting VC's and Angels down and begging for money. I need to launch the site now and start marketing. The sooner it is up, the sooner I can start taking customers and making cash. The credit cards can be used immediately, without having to wait for VC's to cut and send me a check.
  2. IP Confidentiality, since no VC's or angels are in the mix, I don't have to tell anyone about the details of my technology or marketing plans. I keep that close and eliminate the chance of anyone taking advantage of it had I been required to tell them for investment purposes.
  3. 100% ownership retained, I don't have to give 20% of my company to any investors, I don't have to change my customer focused principles to keep the investors happy and I am not pressured to "go public" to give the VC's a big payout. I can run the business at the right pace, namely, the one that benefits the customers first...outsized success for me will come down the line.
  4. Unlike a business loan or VC disbursment which I get in one lump sum, the credit card can be used incrementally. I can therefore shape the level of debt and risk I am carrying as my needs demand.

Of course the main drawback of the credit card funding route is, for the first few months I will be carrying a running balance for the first time in my credit history. The moderately high interest rate on the cards will thus ensure the companies finally get some money from me, but through their credit I will be able to launch the site and if I can acquire revenue to match operating costs within the first few months , the amount in interest I'll be paying out won't be that much at all. Unlike the late 90's when pretty much all new companies had to build their datacenters on site or pay for expensive colocation to build the servers, today , there are many managed hosting providers that allow you to literally manage as many leased servers as you require for a fee.

So here I am at the bet the farm moment, up to now I'd taken a moderate amount of risk in funding the project but it seems I need to really step into the abyss by the act of funding by credit. The amazing thing about this entire episode is how similar it is to the act I took over 10 years ago in taking a loan to get the computer. I had no idea how I would pay off the loan prior to talking it, I knew I would use the computer to fund my job hunt and was confident my skills would allow me to do that, sure enough they were. Fast forward to today, this time my skills have been poured into the distributed web framework and the applications that I will sell as services to customers, again I am stepping into debt but comparatively, I am actually taking a lower risk than I did 10 years ago as a college student on that loan. However, the potential for success is significantly beyond the goal then of getting a good job in IT. I've already signed up with a hosting service and have been working on the required code for providing service options and getting the software installed on the hosts servers. I'll be doing a lot more talking about my products and services in the next few days. Stay tuned!

25 March, 2008

start up talk

In today's daily blog hunt I came across this posting:

http://www.dmwmedia.com/news/2007/06/25/guy-kawasaki-markus-frind-founder-of-plentyoffish-is-my-hero

which has a link to a google video on some start up stories. It really is amazing how varied the stories are. Now that I've finished watching the whole thing I can say a bit more about what I think about it. First, a common sentiment that seemed to weave through most of the panel members was the claim that they started from "zero", now as much as I'd like to believe that I can't. No one starts from zero, if these kids were doing this stuff while college students, where did the money come from to pay for college, and for the ones who were already out of college , how did they acquire the capital needed to get the development software and servers? I have been developing my framework for 6 years now, in that time I needed a great deal of money just to provide for the software and hardware to fund my work. I have a hard time believing that the ones that claimed they started with "zero" really meant zero. Then there is the issue of , where did you live and how did you pay for it while you did this thing??? I was fortunate enough to set out a plan after graduating to save as much money as possible precisely because I knew I would be starting a business in 5 years. It in fact was a vow to myself as I stook in cap and gown, but that sacrifice required that I could not move out (then living at my parents home) I had to stay and pay no rent (I paid a few bills but no real rent) again, if I were to add in the true costs of living that were required to sustain me through my development period it would be a heck of a lot more than "zero", because my parents helped me doesn't allow me to discount the assistance. I am not saying that any on the panel had this invisible assistance but I think it is very likely they did.

Another interesting trait that they seemed to have in common was the realization that they could do more with less and the fact they relentlessly went after ways to do it. I think this is very important to not dreaming beyond your ability to succeed. Often we have to measure our imagination in order to ground it along with reality, you can't start out with 15 servers anticipating wild growth. The smart move is to start with the bare minimum, using as little of your financial resources as possible and through good design a great business and some marketing , ensure your chances of rapid and scalable growth. I differ on them , and many of the newer companies on the idea that you should get your idea into an implementation as soon as possible. I think this is too risky, better to master your area of focus , guarantee that you are doing it better than anyone else, protect your innovations with patents that will be difficult to get around efficiently and then come out with your product. Perfect examples of companies that didn't release the first iteration or "prototype" of their idea is one of the largest internet companies today, Google. The story of google is one of two smart guys, looking at a problem that everyone else had considered solved. Search was a veritable backwater, there were several large search engines and they all were "good enough" it seemed for user needs. Then Google comes along with their innovative page rank system, which in hindsight is one of those "of course" ideas... and sure enough that idea has allowed Google to be in a position not only to dominate search as it does today, but to have achieved enough power as to give even mighty Microsoft a bit of trepidation. So there are two polar extremes in the styles of attack for successful internet companies, one is to go the hit em hard and fast route, get the idea implemented and using first mover status and good viral marketing make it big, the other , is analyze a particular area, see what could be done better and if done better could change the game, and then do it better than anyone else is doing it or is able to do it. Then you hit a grandslam instead of just a homerun, just like google did. However this takes us back to the "zero" money point mentioned in the first section. Larry Page and Sergei Brin both were able to raise $1,000,000 to launch their site. I can tell you straight out , this is not easy to do if you don't know the right people. They had existing contacts in Yahoo and other contacts from Stanford faculty who were able to get eyes on the product and see its potential. This is the hard part for the ordinary joe entrepreneur, "getting eyes on the product". Unless you have a set of contacts who would even care to look at your product, it won't be going anywhere...the other option is to fund it yourself. As mentioned in the google story, Sergei and Larry did go into debt just building their data center at a time where site hosting services didn't really exist as they do today, you had to colocate or build your farm yourself. So on the one hand they had the difficulty of building their own datacenter but the ease of access to potential angels and investors who gave them the start up capital they needed to launch their work. I think today, the barriers to entry are smaller for technologies with great and unique implementations behind them like google's, server hosting is much cheaper than colocation or building your own data center, so money can be devoted to the actual development cycle rather than the build cycle later. This is why I say this method of attacking the problem is optimal for today's web 2.0 environment. We are in an ocean of social networks and chat communities, link aggregators and mash up sites, hundreds of flash video sites...to stand out , new players have to target a market or feature, do it better (cheaper/faster) than anyone out now and then continue to feed the beast with their passion.

As their stable and scalable system plugs along , efficiently growing with little effort due to the longer development cycle for the software; the competitors will be having lots of late nights, retooling their software , building cludges to get scalability and generally breaking their backs (and wallets) just to keep up. The classic turtle and the hair story played out. In this increasingly competitive landscape it is only by taking design view toward long term efficiency that we will see the "next google" emerge from the current ocean of web 2.0 companies.


Google story

old object models to new object models....

I've spent the last couple of days researching the hot trend in software service enablement that is made possible by the idea of web services. I remember back in 2000, when I was still working as a network and pc support technician reading a book on the emerging tool of xml. At this time, the growing needs of web sites to store and provide content thanks to the exploding number of individuals coming online to buy, trade and interact necessitated a way to stream line content creation, transformation and delivery to different locations in different formats. Xml was the magic bullet that was able to provide all these things when used cleverly. I soon found myself during my free time at work, reading the chapters on how xml worked and how to perform xsl transformations. I became convinced that xml related technologies were the future and with that conviction in mind began a secret hunt for a job while I was still working at the bank. I was able to get a job with TheStreet.com in a matter of weeks and was sufficiently enthusiastic and competent to get the job. While at TheStreet.com I got to experience first hand the revolution of xml and the power of it as weilded over the problem of controlling web content. In the system I worked on, nostalgically called "rosebud" by the designers, xml were the rails upon which the content of the site rolled. Several simple relationships between xml content blocks and pages to be rendered in the StoryServer development environment, alone with a distribution method to multiple outbound locations, file or ftp allowed the site to publish content in house and then distribute it in various forms to outside partners (for a fee) as well as to the main web sites of the company. The experience of building many of the xml feeds that brought revenue to the company convinced me further that xml was the future. I imagined a system that could be used as an xml nexus, taking in content in the form of xml , transforming it for the needs of the system and then transforming it again to desired output formats for delivery to external partners. Though we did do this to an extent at TheStreet.com it was not the jist of the companies business, which was to provide financial news and commentary, the content distribution was only a side effect of the businesses goals. I saw xml as more than just something useful for financial news content management, I saw it as something that could potentially manage any outbound or inbound data interaction between disparate systems. As I continued to work at TSC, the proposals to use xml as a lingua franca of data transmission between different platforms was born. Wrapped into the moniker of "web services", these xml grammars would allow systems to speak a common language that could be used by remote systems to authenticate, request method or object acces to various entities on remote systems and recieve the requested data in synchronous or asynchronous fashion. Since then web services as flowered with various protocols for ensuring certain tasks are performed in efficient and safe ways for their use in the enterprise. Security being chief among them as covered by the ws-security protocol.

Today, web services form the backbone of another raging buzz word in Information technology in the last few years, SOA. Web services are what make SOA's possible by providing the underlying fluid interface for mediating data and object requests between applications internally and between enterprises externally. Unfortunately, with all this new use of xml to do things that it was not originally designed to do comes one major issue, complexity. The web services protocols are not very intuitive but once it is realized that all they do is allow remote applications to talk to one another, then old dinosaurs who are familiar with older acronyms like CORBA, DCOM or COM will know just now to deal with the new parts once they are mapped to their object model equivalents. The key difference between web services and the previous object models however is how agnostic they are of the platforms that they run on. The industry has actually succeeded in providing a deep level of platform neutrality that has enabled enterprises to enable a new level of efficiency as far as remote data mediation is concerned. There are still many issues to work out in the areas of security, and still many things that are done inefficiently by the inherent nature of the use of an xml grammar to do them (like sending files) but these are finding solutions. The complexity of these new solutions must be absorbed and abstracted just as was done for the old component object models, through late nights and lots of coffee but the promise of infinitely interoperable systems free from lockin is actually palpable. Is this current round of an object model technology going to be the last one? Or in a few years, will web services be deemed old news and replaced by another new fangled technology that does the same old job in a new way? Only time will tell...

21 March, 2008

Firefox 3 gets the bugs out...

I downloaded the latest beta of Firefox 3 beta 4 a few days ago and installed it last night. What a difference an upgrade makes. True to the claims of vastly improved speed, Firefox 3 impressed me with what you can get out of a philosophy of constantly pursuing tight code. In addition to being faster, the new browser also uses memory more efficiently. You'll recall my post on the importance of an almost manic obsession with reducing the memory footprint of every object when coding for scalable distributed web applications, though firefox is not meant to scale or distribute outside of a single computer, the designers realized that the area of memory utilization could be used to affect a noticeable improvement to the user experience and sure enough that is the case in Firefox 3. Pages load in a snap, firefox developers talked up the improvements on the mozilla blog take a look for the specific improvements made.

One thing that I am very happy about was a bug I noticed regarding the rendering of composed div elements that call dynamic code using AJAX. In my collaboration UI , a contacts list is displayed using composed AJAX calls, up until firefox 3, the display of the contents in this dynamically loaded section was irratic, depending on the amount of content loaded sometimes the outer call would resolve before the inner content had finished rendering. Thus, the outer call would render as if there was no code inside it, the pane displayed in a collapsed state instead of expanded. I could trick it by refreshing the page several times and get it to expand, but often the next manual page refresh would recollapse the pane. I tested the issue in IE , Opera and Safari (on an IPhone!) and none of them exhibited the pane collapse bug I encountered so I was sure it was a rendering issue that Firefox had. I am happy to report that the bug is now gone in Firefox 3, logging in to an account reveals the expanded display of the users contacts as it should, following links on the page refresh the page maintaining the expanded state of the pane exactly as it was supposed to. I am not sure what change was made by Firefox to fix this (probably some issue related to caching and rendering of dynamically populated div's) but it is indeed fixed!

Shot out to the firefox 3 team for relentlessly hunting down bugs and memory issues, I believe that well designed software should get tighter with each revision and the moz dev guys seem to follow that mantra as well. Kudos guys.


good enough redux...

In this post, I made the case that many internet companies are busy solving problems that aren't in need of solution. I wanted to differentiate the conclusion of that article from the ideas I've expressed else where that the optimal solution for a given problem over the long term involves making sure it solves the problem landscape with the largest scope possible. Over time these solutions will lead to reduced costs for the implementer in the form of maintenance and scalability issues which tend to kill projects over time as complexity (in the form of constant dam plugging and retrofitting for problems that weren't originally in the solution scope) builds to unmanageable levels.

This is a different focus from the ideas mentioned in the 'good enough' post, which were focused not on the actual solution, which in many cases in these many online business models are indeed ingenious, it is in the selection of those particular problems. In this case, the issue is that the creators of these sites chose the wrong problem to solve, even if they solved it brilliantly, the existing solutions have already been deemed "good enough" by the bulk of users making even a new brilliant solution, a not very profitable one. In my own work, many of the problems I've sought to solve have been of the type 1 variety as detailed in the previous post. They are based on incremental improvements to aspects of the problems that are already out there, for example, currently there are many dozens of companies providing "framework" or platforms for building applications online. What many people don't see are the hidden issues that can come to bite those projects as they begin to experience any level of growth, one in particular that has struck many a web 2.0 company is , the problem of scaling.

In software design scaling is something that in the past wasn't really an issue, when software ran on a single pc, the user behind the keyboard was usually the only one making the request for the resources on that pc and thus could devote all or most of those resources to the application currently given focus. Microsoft Word does not and never was designed to scale beyond the use of its features by any more than one User at a time. This is true of pretty much any stand alone software that you can install and run on your pc, the software designers focused on allowing the software to satisfy the needs of a single user in a given time, this design perspective constrains the solutions employed to solves various problems of the software design that might be at odds for issues that are encountered in web software development. Unlike web software, stand alone software pays no concern to pooling resources in order to improve allocation from multiple Users. It may pool resources between user requests but in most cases that is not needed. (since User time is much, much, much slower than a single applications execution time) Software designers that recognize the differences in the two areas are best able to employ best practices and complete designs and implementations faster. Web software in contrast as several important differences that must be catered to in the design if it is to be at all successful:

  • Web Software by definition is geared toward simultaneous use by multiple users and thus must accomodate that use between users in a transparent fashion.
  • Web Software should allow individual Users to see the software as if they are the only User and not have to pay a performance penalty to have the experience.
  • Web Software should efficiently pool common aspects of the functions and services utilizied by the Users in order to improve efficiency and scalability.
  • Web Software that is well designed for multiple users can still be inefficient if it can not extend its efficiencies over a clustered environment. One awesome piece of software on a server that goes down is no use to every User connected, even if that one server was able to support 50,000 Users simultaneously. So distributed web software is critical to scalability.
  • Web Software that is distributable still can reach a glass ceiling if the individual nodes are not designed to efficiently throttle and/or route requests between server nodes.
  • At the heighest level of scalability, entire branches of nodes separated by geographical region in many cases need to efficiently route requests between one another as load increases, this would then allow the resources of servers connected over a WAN to distribute load between regions. It gets no better than this, and if your web software doesn't take account of this level of scalability, if you hope to ever be a google or an amazon , at some point you are going to face this issue.

So, the web software engineering problems are a completely different world of issues that must be juggled by the architect in order to design a solution that works efficiently at different levels of load. There are many approaches to these issues, the network design heavily influences the scalability that can be achieved and the amount of work required to achieve it. Over the last 15 years network architectures for scalable sites have gone from mostly 3 tier architectures to 2 tier ones.

Multi-tier architectures




In my designs I prefer the monolithic two tier architecture for its simplicity and reduced cost compared to 3 tier and also because today, a two tier design allows the serving agent (the web server) to be married to the business logic and processing agent(the code that actually runs the business and mediates transactions from the database), eliminating latency issues between the two. The proliferation of application server technologies (java, .net, php) that process business logic and serve pages has allowed such designs to emerge as efficient. They allow the elimination of an entire tier of servers and associated resources and significantly change the scalability constraints. If the web server is married to the application server, intelligent routing can be designed between the nodes that older 3 tier designs didn't have. The app server can be designed to be able to determine its resource utilization and determine if it should handle or route a request to another app server. If the behavior can be dynamically modified, the architecture is flexible to sudden changes in load. This elasticity is very important in a world where DDOS attacks can assert themselves within a matter of seconds, scalable designs should efficiently handle such extreme disaster scenarios as they aren't as unlikely as some designers would like to believe. Secondarily, they ensure a design that will be robust as expected growth , or even better...unexpected growth assails the architecture.

The last few years has been a flood of web 2.0 companies that have come out offering cool technologies brainstormed , quickly pitched to acquaintances and then quickly prototyped and pitched to angels or VC's. I see these models as risking disaster as they grow, the first issue with web 2.0 companies that throw together services is their reliance on a single technology foundation to provide their service. One in particular that has formed the basis of a majority of so called web 2.0 sites is Flash. Flash technology was invented by Adobe to allow client experiences that were more like desktop experiences, it does this by having the client do more of the rendering work than the server. This is facilitated by using a language that allows the client to draw simple geometric shapes, fill them , animate them to produce games, UI elements and even video (as in youtube), Flash itself is older than the web 2.0 resurgence , which most say started after the 2001 dot com bubble burst. Back then though it was really slow on clients (all that rendering required some nice horse power), however with Moore's law still going along and the rise of multi- core processor architectures (not to be confused with software architectures previously described) clients quickly were able to do more and more complex Flash with less of a performance hiccup. It was only when this was possible that the web 2.0 companies that used Flash started to pop up all over like weeds. However, web 2.0 is not only about Flash , the other side of the trend is manned by the oft heard AJAX.

AJAX , which stands for asynchronous javascript and xml , is an umbrella term for technologies that again , bring the web client experience closer to a desktop experience but they do it by performing actions that browsers previously performed sequentially with user events in non sequential (or asynchronous) ways. The realization was that, if the browser could get some data before hand in anticipation that the user will want it, it should do it to reduce the experience of a delay when the request is actually made. The asynchronous call is done using javascript , but the heart of AJAX is one particular javascript object called the XmlHttpRequest that I've talked a little about before.

It turns out that cleverly used AJAX techniques allow very dynamic responses to be created on the browser that formerly only could be done on desktops (or with Flash or Java) Data tables could be displayed in near real time as items are selected from a list. Links could be made to dynamically fetch related definitions and other cool things. So web 2.0 owes its rise to the dual tools of AJAX and Flash, however there are major differences between these approaches. First, because of its reliance on rendering, Flash requires more of the clients processor horsepower to display its fancy interfaces or produce its video, this means that a Flash run application tends to require a lot more horsepower to give a similar experience to the same application running on AJAX.

On the other hand , AJAX can not do some things as efficiently as Flash, it can't run video for example though I am sure some one will figure that out (if they already haven't) the main hindrances being security restraints placed on the javascript that makes AJAX possible. Thus we can see a trend that will and has developed between the use of the two technologies. If you want audio and video with a responsive interface you must go stand alone client or use Flash. (Actually Microsoft also has a flash like clone called Silverlight but adoption is currently low, but picking up) The Flash runs as a plug in to browsers so it requires that the browser has the plug in already installed, this is the case with the latest generation of the most popular browsers, IE, FireFox, Opera and Apple's Safari but because Flash is so resource intensive it runs poorly if at all on wireless devices. On such devices however, AJAX interfaces have no problem at all, so long as the browsers run javascript, which is the case as javascript is a browser standard language (not a plug in) these days. So from the developer front the choice is to design for Flash or to design for AJAX, the problem to be solved and the scope of users that the developer wishes to reach must be considered. For the Flash developers, All those wireless devices that can't run flash also can't run your wiz bang flash application. For the AJAX developers , all your applications can't really do video or audio natively without some sort of plug in, so you should focus on problems that don't necessarily need native video or audio. Another key distinction between Flash and AJAX is implementation cost, AJAX involves all standard based technologies freely implemented by any one, not so with Flash which is an Adobe product. Fans of Flash will say this is a canard , that Flash is open source now, and it is...but running a Flash communication server is not. If you develop Flash applications they must be hosted on a Flash com server and that you license from one company, Adobe.

This takes us full circle , back to the problem of scalability. In the case of AJAX developed applications, the standard based element of the UI and server technologies ensures that developers can freely create their own architectures to get the best possible scalability. Flash developers are limited to the abilities of Flash com servers for scalability built by Adobe alone, this has led to the many Flash based applications not being cost effectively scalable. What's the use of all that pretty functionality if implementing it to millions of users is going to cost an arm and leg. Youtube is a notable company that gets around the problem by the fact that its business model is ad based, the revenue coming in is huge and allows it to deploy Flash com servers as needed to handle all the load of video requests coming in every second, but Youtube is paying Adobe a cart load in license fees to do that. Though there are quite a few other Flash video sites, they are no where near as scalable nor do they have as many users as the big two "google video" and "youtube".


Comparison of video sharing sites

It is clear from the graphs that even second place is ridiculously behind youtube, despite the fact they have identical back end technology the main difference is the fact that youtube had first mover status in this segment and that gave them the "eye power" that advertisers just love. That money allows them to field the servers needed to serve all that video cost effectively. Since each user gets his own stream of the flash and there is no interaction the scalability works if you have enough ad revenue to pay for the servers. Another type of scalability problem is seen when we look at another market , chat.


There are many providers of online web chat services, the proliferation pf traditional stand alone players of IM. AOL, Yahoo Messenger, ICQ , MSN in the late 90's gave way to providers of combined login capabilities, Gaim, Tribble..etc. In the web 2.0 age, the logical thing to do was to use Flash to provide chat online through a web page, great idea! New sites popped up offering such services, from meebo , to userplane to various sites in between, flash chat is all the rage , but flash chat is not scalable in the same sense of ease as flash video. The main reason is that unlike video , which plays in a silo like fashion on each clients request, chat by necessity requires interaction between the Users in a room. This requires polling of the participants in the room to find out if they are there every so often, this lets the other participants know that they can continue to chat. The polling action must be mediated by the server it can't be done on the client (well it can be but that would be extremely inefficient), the server must run a Flash server that manages the state of each room and the participants chatting in it as well as manage the polling of the users and of their messages, it must update all the Users screens every time any one of them sends a new message. These actions are all incredibly resource intensive, the server is constantly calculating who needs the message, who doesn't , who is still online who is not, to do this efficiently requires servers with big brains (powerful processor or processor cores) and deep memories (to manage the room data in real time for all the thousands of rooms that the Users might be chatting in) for this reason Flash chat services online are either expensive to run (or license to users) and offer good performance (since you are in part paying for bigger brains and deeper memories) or they are cheap with poor performance. It is a problem space that is ripe for better solutions...enter AJAX chat.


Unlike Flash chat, the first major advantage to AJAX chat is cost. AJAX chat is purely based on standards or standards mixed with proprietary technology, there are no flash com license fees in sight since the polling and room management is done by a suite of technologies , some of which themselves are free. It is possible to implement flash servers without flash com fees but those implementation require a technology that either does it for you (which in a sense leaves the scalability design to them and not you) or you build yourself which necessarily costs time and money. Thus the critical importance of developing a more scalable architecture in the first place and as well toward procurring servers with bigger brains and deeper memories. This is what has NOT happened with all the flash chat/ ajax chat options out there, they were all cobbled together quickly in the space of a few months, massive scalability being an after thought...but that decision is coming back to bite as the numbers continue to balloon. For those that chose flash due to its speed of implemenation a whole swath of mobile devices can't use it, making them off limits for their services for the time being. The same problems exist with regard to polling and room update but they can be distributed over the servers without a penalty for licensing. If your site only serves a few thousand Users at a time this is fine but if it is to scale to millions of users , the proliferation of servers (in the Flash solution) would become increasing cost ineffective especially if the chat service provided is a "free" ad revenue supported one where new users will create rooms whily nilly just for the fun of it. The AJAX solutions would in theory then be more cost effective as scalability extends into the millions of users IF those solutions are designed to scale as mentioned in the first part of the article. If you look at all the current providers you see directly in their performance a reflection of how much brain time went into developing a scalable architecture. Anyone that has used flash chat provider Userplane for even a single chat, knows how frustrating it can be when it hiccups and stutters under the strain of updating to reflect new message and user status. AJAX chat providers like Campfire have responsive interfaces but it is unknown if they can scale to millions of users , (the designers actually admit that their goal was to serve the critical needs of a few clients needs to be fair to them) Userplane is trying to allow its services to be used in a distributed fashion by licensing to commercial sites as an embedded component but I gather their attempts to diversify into paid tier services are a requirement to keep the service cost effective as well as a value add that will reap more profit. There is a much larger market here to tap that it is undetermined if any current player can access...

Userplane startup review

We should expect to soon see solutions that address the massive scalability issue as the market for online collaboration is anticipated to be nearly 3 billion dollars in revenue for business uses alone by 2010. The company or companies that can provide the needed solutions for cost efficient scaling to very large numbers of clients (including those incredibly multiplying browser enabled cell phones) will be in the drivers seat to dominate the market of rabbid cross platform consumer directed web collaboration to come.


Links:

Userplane

Adobe Flash

Ajax Chat that won't scale (dog slow even with an empty room)

20 March, 2008

How does a company keep its employees productive and happy?

I recently answered this question at the linkedin answers forum, thought it was worth reproducing here. I have some more ideas that will be forth coming.

1) Reward employees for what they know, not only for what you hired them. (yes, that is not a typo.)

2) Use your employees for what they know as well as what you hired them for. (see it all comes together. ;))

3) Allow employees to work from ...wherever. It saves you money and it saves them time...to make you more money.

4) Reward achievement on time as long as it is within project goals. ie. get rid of the time clocks.

5) Some people want to take a nap around lunch time, if you still have a physical office (I know some of you "older" businesses still do that kind of thing) provide a quite lounge precisely for this purpose.

6) If you are forced to lay off workers, offer them a reduced salary before you give em' the slip. It is the least you can do.

What are ways that you think companies can get the best out of their employees???

Ubiquity of "free" and the new online business...

http://www.edge.org/3rd_culture/kelly08/kelly08_index.html

The article linked above is an excellent analysis on the issues that attend the ubiquity of free content and free services online. It highlights the obvious truth that profitability in the long run will be found from attempting to profit from services that can not be easily copied and distributed online. It mentioned several qualities that can't be copied by the internet however it fails to mention only that the ubiquity of free is not restricted only to the ability for content to be copied online, it also involves the ability for the models of business to be copied as well. For example, "trust" is given as an example of a quality that can't be copied online but this isn't really true. If a network can be built that can harness trust between individuals that join that network it can be used to secure business from those users for having provided that service. Similar provider networks catering to the same need would also be providing this service and if enough of them are doing it online , then the value derived from facilitating the trust networks between people will also eventually go down. So as I see it, the "free" model is a bit like a virus, in that it facilitates copying not just of the content that is distributed or created online but it also reduces potential value that can be derived from a given business in at least the intangible quality of "trust". I haven't done a full analysis of the other qualities mentioned by the author in the article above but my guess they would be similarly susceptible to the same dilution of value over time. It is still a very interesting article in that it does give the general trend that we have been watching happen over the last 10 years.

19 March, 2008

less fiber more lambda's should mean lower costs...

Following article was written as a response to an email regarding the linked wired article back in 2/27/2006.


Leave it to the greedy corporations in search of endless revenue streams to satisfy their investors to come up with this idea.
I am amazed at the audacity of these telecom heads, as if the fact that people (consumers and businesses) already pay for internet access isn't enough. Now they want to chop up service on the internet to extract greater profit. Showing yet again why public corporations eventually succumb to evil by nature IMO, they can't help it. Investor driven businesses simply can not afford to have a moral compass.
God this stuff makes me mad, though I am glad that unlike other business driven initiatives which the consumer has no hope of fighting against (anything the big Oil or Tobacco companies do or say) this one has other big businesses in opposition to the plans. Namely big name sites like Yahoo, Ebay and Google. Hopefully the draconian ideas the telecoms are planning will be killed on the vine just as they deserve.
The true kicker is that anyone familiar with the technologies that the telecoms use to allocate additional bandwidth for internet traffic on their backbones knows that the telecoms are blowing hot air about the issue of having to pay for the increased bandwidth that customers are using. Just prior to the dot com burst most telecoms upgraded their infrastructures to include the latest WDM based switching technology, they also laid tons of fiber. These two actions have future proofed dramatically the entire bandwidth acquisition process. Literally, for the telecom to allocate more bandwidth involves no more than enabling a new lambda at both ends of infrastructure using add/drop WDM switches. So although it is true the original cost outlay for changing their infrastructure was highier, the long run costs will be next to nothing. The fiber in the ground now will last for a lot longer than even the best copper cable could last, and thanks to WDM never needs to be dug up to increase bandwidth. This means that they will be able to allocate the needed bandwidth very easily and routing traffic regardless of type will be easier and less likely to incur latency as a result..making the entire foundation of their argument for tiered service a huge white elephant. Of course it doesn't strike me as a coincidence that they are coming out with this idea now, they have their backs to the wall. With their traditional business being encroached upon by cable companies and independents like Vonage and Skype, the boards of these telecoms are scrambling for ways to grab a bigger piece of all the services flying around on the net. Also most of them put themselves in a huge hole during the telecom bust of 2001. No one anticipated the fact that WDM would become so cheap so soon, making all the fiber that they were laying irrelevant over night. Add to this the fact that the need for bandwidth simply did not scale as fast as everyone was predicting. Even now, tons of fiber lays in the ground unused because well..there is no need to use it..but the telecoms paid for it and now they want the consumer to pay for their provisioning mistake. I am all for them charging for access service as they already do or even increasing the charge as their costs naturally go up due to inflation, but it is the height of greed for them to create "tiers" when none will be necessary. This is a classic example of a corporation attempting to diversify a service (in this case access to the internet) in order to increase profits by selling consumers what they really don't need. Now IF they can provide the tiered service as an option and not a requirement based on how much bandwidth a particular business or customer might be using, fine..existing customers can choose to upgrade to the supposedly more reliable service if they wish. Additionally, if the telecoms can provide demand statistics for their customers indicating a customer demand for this tiered service I would be inclined to say it is fine, but if the customer is NOT demanding it and introducing it will automatically hike prices for existing high bandwidth customers (like Google, Ebay who already pay huge access fees to the telecoms) there is only one purpose to introduce it and that is to squeeze more profit out of the existing already at equilibrium cost/service matrix which to me is wrong and immoral.
What is your take on this issue?
(the reason for the telecom bust..over provisioning due to the emergence of cheap WDM and to much fiber)

17 March, 2008

the music of genes...

Gene Networks

The article linked above provides the latest news in the search for genes related to obesity. It turns out that genes are triggered in cascades of activity (expression) dubbed as "networks" by the researchers. I have been using the metaphor that our genes play out the music of our lives in their expression patterns and here is the proof! This research should lead to insights concerning the type of obesity that particular individuals are likely to develop should they over eat.

Great stuff.

14 March, 2008

finding problems that need solving...


Yesterday, I mentioned some of the pitfalls that attend developing complex solutions to problems that go beyond the "good enough" solutions that may already be in the wild. The internet is filled with business models that invent problems to solve that frankly no one was interested in having solved. I wanted to address in this post a bit on how to find problems that are worthy of solution. The trick is to look for problems that perform one of several things:

  1. The problem is one you encounter on a daily basis while trying to get something else done. It is to you a "minor" but recurrent annoyance that you wish could be eliminated. Many great products and services came about from noticing a need for a slight improvement in a product design or how a service is delivered and then engineering a solution that addresses this problem. I'll call this type of potential solution an incremental innovation. The internet is filled with web sites looking to score incremental innovations but as mentioned yesterday, many of these solutions suffer from the "good enough" problem.
  2. The next type of problem is similar to an incremental innovation but arises from noticing existing inefficiency in the implementation of a particular solution in order to shave time or cost off the process relative to existing methods. It is incremental but comes not from noticing an annoying issue in user space but rather engineering better solutions for internal issues in the design space of a particular product or service. This we can call engineered innovation. A good example of this was the invention of the disposable razor by Schick in order to tap into the lucrative safety razor market then pioneered and dominated by Gillette during the turn of the last century. Schick analyzed the patent and came up with an implementation that was itself also patentable and today, you'll be hard pressed to recall a third safety razor company as a result of their shared dominance of the market.
  3. Finally, the most rare opportunity can be found in engineering solutions that solve an existing problem in an entirely different way from existing solutions, so different in fact that the new solution obsoletes an entire category of previous solutions to the problem. These are the category killers. A good example of this is how the use of digital media in the form of mp3's for electronic music distribution has essentially obsoleted traditional physical media distribution models by introducing vastly different selection, cost and delivery structure than the traditional methods. In every comparable metric a category killer solution bests the traditional solutions and thus is most likely to find wild success. The invention of electric-diesel train engine is one example, putting an end to commercial steam engines.

Obviously the solutions that employ new ways of solving old problems and in so doing obsolete them are the ones which will find the wildest success. These usually come about not from an active desire to create them, usually they are the result of happy accidents. The invention of kevlar stands as a notable example. Software engineering is a place where solutions types one and two are common due to all the cogs that can be adjusted and modified between implementations to realize potentially profitable optimizations, though category killing solutions do come about they are as rare as in the physical invention world. The key is to seek solutions that answer the key questions, "does any one want this to work better?", "how can I make this work better?" and "how can I do this in a completely different way?" while solving problems and with time and effort you should run into at least one wild success in your engineering lifetime...hopefully. *wink*

13 March, 2008

good enough is sometimes all you need...

I have been quite busy the last few days, evaluating venture capitalist firms , calling colleagues to rekindle old connections and mine them for leads on prospective investors. I have been refining my business plan and last night I spent all night compiling a presentation of the business model that I wish to seek funding for. The whole affair feels much like the type of research I had to do when I was a fresh college graduate. I had the sheep skin and a brain full of engineering knowledge, some practical experience and my voice. The search for a job was a job itself, daily searches of the newspaper and internet recruitment sites, setting up appointments and refinements to my resume soon was at its end about two months after graduation before I was able to land a position for which my practical experience was suited.

The difference between then and now is that instead of having a resume and a diploma to sell myself, I have a presentation and a business plan to sell my business. The same hunt for success is afoot but this time, my quarry are the elusive angle investors and venture capitalists looking to put some cash into the next big thing. Today I came across the TechCrunch.com website which provides news, resources and forums for start ups seeking funding. I was browsing the forums when I came across a funding search from a site called twerq . I read the posting and discovered the site was already launched and was just looking for more investments to fuel further growth, however when I visited the site and used the actual product I wondered to myself. "what problem does this solve?" and I couldn't come up with an answer. Apparently the site provides the service of searching the most popular search engines simultaneously and allowing access to the results in a single pane. Sounds convenient but it has several problems that are specific to search.

  1. People tend to stick to one search engine and that is that. Since I started using google search for all web search activities about 6 years ago I haven't had a need or desire to go to Microsoft Search or Yahoo search. Often the same results show up across all the sites (more often then not) so one is as good as any. Thus any single result list is good enough, there is very rarely any need to consult another engine and therefore it is unlikely to be useful to have tabbed results from each engine.
  2. Search is a "give me" online activity. People don't go to search to do anything but get the information they are looking for, sort of like the concierge at a Hotel. You don't care to ask him what his view on politics are (unless you have time to waste) you usually just want to know how to get to your room and who is going to take your luggage up.
  3. Once I am done searching the window gets closed. I rarely ever keep a search window open for access and since the accuracy of all the search engines is pretty good these days, chances are the initial query on the initial engine will return high placed results that are satisfactory for my needs and twerk's tabbed option goes unused.
  4. Finally, these days most web browsers allow the browser to initiate the search from a field, I use this field religiously on my firefox browser and the only engine loaded in my list is google. (Just checked that isn't true...yahoo is there but it might as well not be since I didn't know it was there until now!) Regardless , twerq would have to get itself into that list if it is going to even be loaded in my browser. Who types "www.google.com" to get to start a search any more if the field is sitting there ready to select?

It is clear that search results from a single engine are good enough for needs of pretty much everyone and for the other reasons mentioned above make Twerq's tabbed collection of the results something that is nice but beyond the needs of what people want. Some times "good enough" is as perfect as something needs to be. As if to confirm the fact that Twerq is probably not getting much traction from this tabbed search results feature is the recent launch of a new "hive" feature. Which frankly I am still trying to understand what problem it solves. It allows you to collect search results collaboratively with other Users who might be searching for similar things on the web. In essence it allows you to refine your query for media, stories or feeds associated with the target of your hive...but this if you think about it is nothing more than a second or third google query away. If you take a look at the Hive interface that pops down next to returned Twerq search results you will see what will likely scare away "Joe Internet" , goal criteria, collaborators, quick tags ...it just strains the mind as to how it would be useful beyond simply querying separately for images, or news related to your query. (remember the major search engines all provide these abilities) Again, it might be nice to collaboratively search for things, it is still an act that is done easier or just as easily using the traditional methods and therefore was "good enough" and didn't need any new solutions.

The old saying applies here, "if it ain't broke, don't fix it."

I did some more digging and found this page, which lists the settings for the twerq searched performed. I never knew that searching could be made to be so complicated! "Joe Internet" would be hard pressed to understand why there are so many options , let alone want to use them. I wish the creators of Twerq all success but unless they find a genuine problem to solve in an area in which a "good enough" service or product is not yet available, they aren't going to be doing too well on their funding search. Design by parsimony is a critical aspect of developing web technologies ...really any technology. Finding problems that most people would like to solve or that make their current actions take less time and effort to complete is the key to engineering solutions that take off in and of themselves without the need for superfluous, dials and switches to provide options for changing things that were never desired by the bulk of users in the first place.

12 March, 2008

the increasingly telepresent workforce...

The following ideas were written in email on 12/16/2006, I thought it an interesting topic to start are post on here. Any thoughts? How do you think technology will change how we commute ???


Increasingly businesses are seeing the power of decentralizing their businesses so that expensive large monolithic central offices will no longer be required. We have the pieces coming into place, secure remote access to business locations, instant communication in the form of cell/IM/conferencing, pending high bandwidth pipes (FTTP) to people's homes and nearly ubiquitous wireless access and increasingly electronically run business processes in all types of businesses. All these factors when fully employed in the business world will mean a much lower need for physical office locations and workers AT those locations, which means cut costs on maintaining such properties, paying rent, paying utilities and hiring repair and maintenance folks. This means vast reductions in commuting workers and reduced electrical demand at least over small regions (you'll still increase it over the larger metropolitan area but larger areas tend to be serviced by multiple power grids, reducing the likelyhood of peak collapse for the collection.) 10 years ago the birth of the purely internet driven business inspired the concept of businesses mostly run online, this allowed the early players to rapidly become revenue competitive with their brick and mortar counter parts. However traditional brick and mortar businesses had not begun to move in the opposite direction (toward the internet model) the continued rise of the distributed internet business in the form of web services/SOA/ssl VPN driven initiatives will make the need for big office towers significantly reduced. Even as businesses grow in employees the need to provide physical locations for those employees will dwindle and I predict essentially disappear. (Imagine the day you go for an interview and a prerequisite of the job is that you work from home but that you dont' have to worry about having a pc and pda, the company will provide it FOR you.) There will be a time when the top brass of businesses actually come to work (ironically) more often than the lesser employees, everyone else will be mandated to work from home all or part of the time to save money. (Such people will alternately share an office or cubicles when coming in to further save money.) So in response to the pure internet players of a decade ago who showed that corporations could thrive without huge investments in physical offices, brick and mortar companies will move slowly to be less brick and mortar and more pure from an internet perspective. Of course there will be exceptions to this trend, companies that require the physical presence of people (manufacturing, utilities, construction, human services, food,dry cleaning..etc.) will continue on with their marginal growth curves (relative to what is predicted for knowledge workers) but I don't think they will change the outcome as the city has been on a downward spiral for such jobs for decades now.

I think existing brick and mortar businesses are going to see this change over to a telepresent work force as viable and cost effective within the next 5 - 10 years, the transition being facilitated by increased broadband penetration to homes and the aforementioned building of agile secure distributed business systems that do not require physical presence for knowledge workers to do their jobs. (Edit: 3/14/2008 Businesses starting out today can already take advantage of these economies if they have the facilitating software to ensure every aspect of business can be managed and performed in a secure and distributed fashion. Collaboration needs to be integrated with workflow in currently non commercialized ways to open up a new category of hyper efficient run businesses. ) What does this have to do with NYC growth? Well , the window for the predicted choking of our city on people is well beyond 10 years time, for the reasons mentioned I don't think as many people (those that currently commute to work) will need to live IN the city as the projections in the article indicate. I assume (without data to support the claim) that most workers in the city are indeed knowledge workers as opposed to people that prepare goods for sale or who's physical presence is required for rendering a service. Knowledge workers will simply need to have access TO the city and it's businesses and that will become increasingly possible for the reasons described before. Still there are people that need to come to the city, those that keep the city (first responders, utilities, infrastructure supporters) these people will use the infrastructure regularly but the growth in their numbers will be tied to the size of the city and if businesses aren't building any more towers , there will be a reduced need for the city to provide the infrastructure conduits to get the people that man the towers to the towers.

statistics and the perception of merit...

http://www.gladwell.com/2006/2006_05_29_a_game.html

Very interesting article, I've noticed the tendency for people to give more relevance to the wrong data points in all sorts of problems I've come across in my life, school and work experience..precisely as described in this writing. It is very interesting how people applying the wrong algorithm of choices to their lives, end up making the wrong choices. It would be interesting if the researchers could apply their "win score" algorithm to other complex relationships and interactions to make predictive projections. Imagine running the algorithm in a hypothetical but possible complex problem space and then letting the predicted win score for a given course of actions in that problem space determine a real world response to the problem should it ever materialize. In computer science research, scientists have been doing something very similar to solve complex problems for years called "genetic algorithms", basically they use stochastic processes on autonomous programs to allow the interactions of these programs over time to "evolve" efficient solutions to a given problem. These algorithms have been put to good use by some investors in the field of quantitative analysis, the brokers that use such tools to buy and sell stocks are called "quants" and have made consistent success using their tools. It would be interesting to see these ideas and algorithms applied to the social domain.

Links:

Genetic Algorithms


Quantative Analysis

Incremental truth and Wikipedia

Update: 3/17/2008

I was made aware by a reader that this post might be taken as acceptance of the practice of using wikipedia as citation for research work. I am not making this point, I am simply highlighting the vector toward more truthful , that all articles on wikipedia tend to be directed as time and contributors increases. In the most mature wikipedia articles, one will note a plethora of valid technical first source citations at the bottom of the article that can be used for academic sources. Again, the post below is simply illustrating the trend toward "incremental truth" that attends wikipedia articles.

I originally commented on this article in an email to my brother, the entire comment in transcribed below.


http://www.nytimes.com/2007/02/21/education/21wikipedia.html (may require free registration to access)


This article is a perfect example of why Wikipedia is soo cool! On one hand I agree with professors that say it shouldn't be used as a citation source , the reasons for this are simple.

a) An article still in open edit mode (ie. anyone on the net can edit it semi-anonymously) can be edited by anyone. I know I've edited several dozen wikipedia articles myself. However not everyone providing edits is pledged to apply the wikipedia mantra's of POV free input along with citations for the source of the knowledge provided. In open edit articles this ends up with the possibility that a crack pot or two can edit an article with bad information, in wikipedia parlance vandalize it.

b) Even when the participants agree, if they are only a subset of the persons that have expertise in a subject they article quality is still poor , even if it has few "edit wars" behind it's history. Low number of participants tend to correlate to lower quality articles.

c) Kids can edit an article to include ideas they feel should be in there instead of what was actually in history. Thus an article used as citation could be fluffed up by students looking for material on their papers. This problem though is correlated with the first two points as such articles are soon viewed by more knowledgeable wikipedians who sound the alarm and soon revert changes and the quality of such articles go way up again.

That said, the opposite side of the coin allows all of these weak points to be mitigated against. First, if an article suffers frequent vandalism or edit wars it can be clamped down to future editing or restricted by a removal of open edits. (only users with accounts can edit) Many "mature" articles in fact are in this state, I've found these articles to be the most citation filled and accurate of all on the site. Thus it seems quality is directly correlated with time. So wikipedia article histories start out with large swings in quality, as a low number of participants contribute to it...but over time the quality line approaches not just a consensus of the participants but a correlation with the actual facts of the subject in question as more participants go up and the article itself is viewed by more users. Also, as the number of participants to an article increases , edit wars tend to go up but the quality of the article goes up as well. POV references are quickly flagged and removed. Also, the editors tend to include experts in the field. The overall picture is that as more time goes by, Wikipedia articles *always* tend to get better and this is the power of the medium.

As soon as I started the article I realized the folly of the writer, as he stated the historical error regarding the Jesuits. I thought "I bet it isn't wrong now." , sure enough by the end of the article the author felt confident enough to assert:

"And yes, back at Wikipedia, the Jesuits are still credited as supporting the Shimabara Rebellion."

I thought to myself, "and this is why Wikipedia is so cool." as I typed in the article for Japan. As sure as I expected the disputed passage was changed (possibly in response to the authors very article!) between the time the NYT published it (2 days ago!) and the time I read the article.

http://en.wikipedia.org/wiki/Shimabara_Rebellion

http://en.wikipedia.org/wiki/Kirishitan

http://en.wikipedia.org/wiki/Talk:Shimabara_Rebellion

Any direct statement that the Jesuits aided the rebellion is gone in the first article, the second goes so far as to state that the Catholic Church didn't consider the rebels who died martyrs because they used violence to achieve their aim. Lastly, the "discussion" page of the Shimabara article shows the actual reference to this NYT article by Noam Cohen (only 2 days ago!), and mentions the controversy of the Jesuits (which was deleted) and requests contribution by the historian mentioned in the article to vet the edited version!!! Awesome!!! This is something that simply can't happen with traditional encyclopedias where publicly revealed non factual knowledge remains stale for *years* before it is corrected in the next edition. No amount of "current" debate on the mistakes can force an update of the edition, for this amazing expedience of updates Wikipedia gets my vote. The magnitude of error in peer reviewed articles is lower but the correction time is much longer than a wikipedia article which tends to have highier magnitudes of error but blindlingly fast correction tmes. Over time both achieve similar quality.

Still for the error magnitude problem mentioned above, I would be cautious about using a wikipedia article as a citation for a paper if I were still in college, simply following a couple of rules of thought can ensure the veracity of the information extracted. Ensuring a long edit history with many citations, with many participants and a discussion page with few "running" controversies or edit wars will ensure the articles chosen are mature. These are the articles I tend to give more credence to, like anything one shouldn't accept it on the face of what it states, critical analysis should always be employed!

IT Labor shortage?

I originally wrote this as commentary to an article from last year, regarding the so called IT labor shortage. I transcribe the article in its entirety for discussion here.

http://www.eweek.com/article2/0,1895,2111347,00.asp

I agree with a comment made in one of the talkback posts, there is no IT labor shortage (well not yet a real one is anticipated in the next few years), only a shortage of cheap IT labor. However there is a dual statement that can be made that I feel is also necessarily true, namely that US IT workers will need to differentiate their knowledge above and beyond the "cookie cutter" knowledge that is provided to recently graduated IT workers to improve their value relative to the foreign workers and command higher salaries while receiving first dibs on the available jobs. This additional knowledge provides value above what is otherwise comparable knowledge coming from the same cookie cutter IT workers graduating from the best Chinese and Indian universities.

Of course this really shouldn't be a surprise, globalization opens the field to more people with similar skills and by economic necessity that is going to reduce prices (in this case, the price that businesses will be willing to pay for the workers with these fixed skills) only the stand outs with the additional value added skills mentioned before continue to command the higher salaries. I think this is where the US universities are failing us, not in failure to graduate the numbers of IT workers required as indicated by this study, but instead they are failing to provide the diversity of value added knowledge and practical experience necessary to give the Microsoft's of the country a real reason to pay more for an American engineer when they can hire a Chinese or Indian who is just as knowledgeable but is willing to work for 20% less than the American and maybe work 10% longer while doing it.

US institutions I fear are inadequate at combining the book knowledge with the practical hands on, real world needs of business. Where often times it is (unfortunately for the business) more important that something just works than that it works as efficiently as possible, we certainly can attest to this pattern in our worker bee experiences. In this age of deep business tie in's into IT, large scale distributed web applications and emerging service oriented architectures however, the areas and levels of IT competence required by business of each individual employee (not just IT employees as well) have dramatically gone up, yet the Universities aren't training Americans to master these different areas. (at least not as undergrads) For example, do any of you guys know of a university that has a "computers 101" mandatory course for all majors? Similar to what is required for basic writing and math? I think it is long past time that all colleges start making it mandatory for people (not just prospective IT grads) to have certain basic pc skills. We all have experienced the state of utter shock it is to see some one in front of a pc and not know what the "desktop" is.

In my personal experience I can say that when I was a "worker bee" I always made sure to continually acquire skills beyond my employees need in order to stand out, that tactic allowed me to demand compensation commensurate to my talent and receive it every time I asked. I noticed though that many of my peers (excluding present company of course) either did not keep their knowledge levels above the requirements of their positions or they were not confident in asserting their value added skills to command skill commensurate compensation from their employers. I've always believed that you should demand payment for what you KNOW not for what you DO, if your employee isn't fully milking your formidable skills tank that is THEIR fault. If they aren't paying you for your additional skills, even if they don't use them, that is YOUR fault. In the environment of global competition it is going to be even more difficult for Americans who lack in both areas mentioned above to rank competitively with the foreign talent coming in.

11 March, 2008

Nortals...

A few weeks ago I was having an IM chat with an old friend and as is usually the case, I started talking about some aspect of my work and off hand mentioned the fact that to me , fun is working on a hard problem. It can also be incredibly frustrating when a problem evades solution but that only makes me want to solve it more. I realized that this way of looking at problems is very rare, this was something I noticed not in software engineering but in art. When I was a child I had a bit more talent than my peers when it came to line rendering, it was something I enjoyed and practiced by reading comic books and then drawing the characters in them by eye. As I got into my teens and entered HS I became more interested in under standing the mechanics of drawing. As I've mentioned in past posts , skill at any thing can be learned, it is only a matter of figuring out the necessary object interactions and mastering them to the point that we can visualize and create arbitrary configurations of them. Around this time of growing interest in art technique I was learning about the master of art illusions, MC Escher. I had perused one of his books in my HS library (go Brooklyn Tech!) and was stunned by his ability to not only create the incredible illusions and tessellations but to render them as an expert illustrator. I set myself the task of studying and practiced rendering the human figure using construction methods of my own design, these were partially successful in improving my free rendering capability and kept my confidence strong that I was getting better, and then I met Bernard...

In my second year of HS, I was introduced to a fellow student Bernard. We met one day in the school lunch room, I immediately noticed the open drawing pad he was doodling in. In the pad was a partial rendering of Batman and Robin colored with colored pencils. The instant I saw the rendering I knew that Bernard was better than me and the feeling of mixed anguish and envy that went through my body is hard to describe but this feeling is one I've had only a few times since that day over 20 years ago. The anguish came from the fact that in that moment I felt all my work to get better (for an instant) was nothing. It may not have been true, since I did improve greatly but the fact that I felt it was not a good feeling. The envy of course was an expression of how far I felt I was from the talent I saw being expressed by Bernard in that pad. I sat down and looked at his work, I observed his style to understand his "mechanism" and I noticed important differences in his approach that I saw could contribute to my getting better. I left his lunch table not sad but angry, angry that I had not been as good as him. I know it sounds nuts, how could I possibly expect to be as good as every one who does what I do even if I've never met them?, but that is I think, a distinguishing characteristic of those with a rage to master a given subject. The anger was not a destructive anger, it had no target in Bernard...it's target was in me.

As I walked away from the table I resolved myself to redouble my efforts, to continue to study, to spend more time learning construction techniques. I bought an excellent art anatomy handbook, the classic by Stephen Rogers Peck "Human Anatomy for the Artist" (today I have both my old tattered soft cover and the bound hard cover version) I spent the next few years focused on learning human anatomy so as to render human and non human characters more convincingly. In 1989 I graduated and aside from seeing Bernard in the days leading up to the graduation ceremony I never saw him again, but he was always in my mind when I drew. I kept in mind the possibility I would see him again so we could compare skills (though he never even knew that I was making such a comparison) this drove me to continue learning and perfecting my craft. To this day I have a bit of a paranoia about it...so if you are out there Bernard, let me see what you can do. The piece below is sketch I did in digital circuit design class, over 10 years ago:



Since that early experience, I noticed that most people do not thrive on implied competition in the same way that I do, I've only met a few other individuals that compete with themselves or with others even when , well those others don't even realize it. I coined the phrase Nortal ("normal - mortal") to describe the mindset that many have that they are unable to do a given task and on the basis of the belief , fail to even try. The minute I tell myself I can't do something I use that as a goal to prove myself wrong. I know that had I not had the rage to master I would have never improved as I did, never derived the benefits. Since then I've applied the same rage to master various topics and through out have encountered Nortals that are easily beaten by a problem into being convinced that they can't solve it. The difference between Nortals and those with a rage to master is not magical, it is simply desire, will , drive and hard work. It just so happens that a few weeks ago a paper was released that came to the same conclusion, the belief in ones ability to succeed coupled with the practice perfect the ability is the overriding determinant of ones success at a given endeavor, so I guess my crazy hyper competitive way of looking at things is not that far off after all. ;)

10 March, 2008

VC hunt day 1

Today I finally got started on researching , compiling and contacting venture capitalists for the purpose of securing funding for launch of my business plan. I was thinking today just how amazing it is that the resources to so many firms are literally at my fingertips. If this were 20 years ago I'd have to be doing some serious leg work just to get the chance of being in contact with these firms , today many are just an email away.

The online VC funding business is alive with incredible diversity as far as resources that can be used to get in touch with the right firms. The very first search landed the go big network, this seems like an excellent place for a company with a product can go to be connected with investors with the funding. I was all excited about signing up and eagerly hit the "join us" button, I was taken through the task of specifying my company and personal details and detailing a loose description of my funding needs. The hook didn't come until the very end of the sign up process, the site mentions the ability to send funding requests to all their member funding firms but it doesn't mention that this is a pay service until the very end. No problem with the payment for such a service (it is an invaluable time saver to have them send the requests to their list of firms) but I paused from the sign up process and went back to do some more searching. Sure enough the next interesting link I clicked on took me to venture capital update and this seems to be the mother load. It provides a daily update of news in the funding industry (not really my thing since I want funding I am not starting a firm) but it also provides a free directory of venture capital firms. The cool thing here is that all the contact information is also provided, so I decided to simply go through the list and methodically contact the firms that grant funding for internet and technology companies. Since this list is a list of funds that may not be on the go big network as well as funds which have, I may be exposed to a larger field of prospective firms. Sure, I still have to manually contact each firm but I have the time...if I don't get the response rate I want I will probably pay for a fund request at the go big network but for now it is phone and email time. I went back to the go big network and noticed they also allow access to their investor contacts directory without pay ...so now I have to lists to mine.

09 March, 2008

closures, Ajax, javascript and the hard easy....

A key aspect of AJAX based development is the use of javascript to provide the A in the Jax, all the buzz over web 2.0 is boiled down to one single javascript object now implemented in all major browsers that was first conceived (amazingly) by Microsoft.

XmlHttpRequest

This object allows the set up of an asynchronous http request, essentially a request that is not tied to the state of the currently requested page resource by the users. Allowing separating of requests from the resource allows us to retrieve resources at different times , hence the that Asynchronous word. Anyway , the object is great , has simple methods for passing in the url and does what it was made to do but because javascript forces some interesting issues to crop up.

Closures:

In javascript the closures allow a function declaration to persists the current state of a calling function in order to await a response from another objects execution. Since XHR objects process asynchronously they are tailor made to be used with closures in order to perform important functions. (Like allow background updates to sections of an html page without refreshing the whole page) There you go, all of web 2.0 bubbles out of clever use of this object to provide the illusion of more responsive web applications. Unfortunately, closures are not very elegant programming constructs and as implemented in javascript , they can lead to the leaking of resources (memory) especially when periodic polling using the XHR object of server resources continue to await asynchronous results. Since the reference to the XHR object is always contingent on a previous asynchronous result being returned they (more specifically the associated resources for any variables defined in the XHR asynchronous call object scope) end up piling up in the memory of the browser and in time reduce the responsiveness of the application.

I spent all day today trying to come up with a solution for the slow leak that results from the necessary use of closures and XHR objects in my management UI, what struck me is just how many articles there are online that have a mistaken understanding of what is going on. There are a few great sources and then a ton of misnomers, many believed that simply setting objects after use would solve the problem but the particular invocation steps taken by javascript thwarts that potential solution. This brings me to a funny truth, the media is all in a tizzy sometimes over making a distinction between AJAX and javascript and anyone who has done AJAX knows you do it with javascript (that's the "J" ) It is funny how often this mistake is made in the trade magazines that are supposed to keep technology professionals aware of the latest trends. It just underscores an observation I've made since I was an undergraduate electrical engineering student.

Things are a lot easier than most people believe them to be.

Learning a thing always brings it from the stratospheric realm of the impossible to the trivial the difference in perceptions lies in how much relative work is done by individuals to get to a given level of understanding of the topic, but once that knowledge is had ..what was hard or impossible, many times looks exceedingly easy.



effective public speaking

..I was spending some time surfing and came across the always informative 37signals weblog. An article there referenced this link to a set of video tutorials made a Harvard professor on how to give effective presentations and talks. Always useful for those of us that feel that our oratory skills could use a bit of brushing up!

Enjoy

verbose link:

http://isites.harvard.edu/fs/html/icb.topic58703/winston1.html

07 March, 2008

the butterfly effect and green coding

Optimization of code is for me one of the most fun parts of development, at the same time it tends to be one of the most fleeting. The reason is that if you take care to ensure that your design is optimal for the problem scope encountered during the application life time, you reduce the need in a general sense for optimizations that require design changes. This minimizes a class of optimizations that tend to be the most costly to repair, which is a good thing. Still though, you are likely to need several rounds of optimization that involves the elements that are not directly made more efficient even when you have selected the optimal overall design, these elements show up in the minutia of the actual code, inside the classes and methods. The Java language has various gotchas that can affect code and reduce performance even while the code itself looks fine. Circular object references can pop up and despite judicious attempts by the automatic garbage collector , memory leaks will result as those circular references prevent proper and total object cleanup for objects no longer in use.

This post isn't about the details of garbage collection it is more about the little things that we can do to optimize code by ensuring we are executing minimal code in memory. Often developers fail to realize how much performance improvement they can get simply by naming a commonly requested object or variable with a long name like twicethelengthofi to the more minimal 2timesle, these hypothetical examples are used to illustrate a point. Let us say that the code for the object is instanced quite frequently in the application for performing a common action for all User sessions say, assume that the Server node running the operation has a nice 4 Gigabytes of ram, assume also that the executing code is a total of 50kb without the name and references the object 5 times in it , how many more User sessions can be fit in that 4 Gigaytes of ram using 2timeslen as the object name than using twicethelengthofit , with the shorter label only 8 bits shorter than the first, it doesn't seem like much, one byte saved for each reference of the name , per 50kb code section loaded into memory.


So that is:

1 byte X 5 object name references = 5 bytes per code chunk for name of 2timeslen

making each User session require 55kb out of that 4 Gigs which through simple division supports
72727.27272 User code chunks loaded in our available 4 Gb space.


Now if we double the name reference size (note only the name) we require 2 bytes per references.

making each User session require 10kb , which brings per User code to 60kb and that reduces our simultaneous User count to:

66666.666

A difference of over 6060 Users.

Now as a fraction of the total ram using the long name reference, 6060 is only ~8% of 72,727 but that is 8% loss in the usefulness of our memory to a whole bunch (6060) of Users. For an application to run under scaled conditions , every drop of memory must be conserved and if cutting a simple object name reference in half will allow support of 6,000 more Users then why not consciously think about the affects of loaded memory size for our code. Now, one key issue that must be recognized is the fact that we assumed that the reference to the object in the code was only limited to 5, in OO code because of how methods are invoked it could be possible that for a given piece of a code the name is referenced a lot more times than 5 in the code. Thus depending on how many name references are in the loaded code chunk the number of Users lost could go up quite a bit more. This is particularly true for multi threaded code that requires that each reference must be unique (say to ensure some persistence of state for each User), these areas of the application are the ones that are memory inefficient in object references and should be targeted for this type of optimization, the savings realized could be quite surprising. In my own testing on optimizations made to my framework code I have been able to save great deals of memory because the design is heavy on multi-threaded principles. The use of multi-threading allows us to press objects or classes into service and then time invoke them as they are requested by Users, we then retire them after use this design is great for ensuring a scalable system but it is subject to the mentioned memory efficiency issues. I went through the code that is invoked in this way and reduced unnecessary object and parameter labels to their barest minimum while preserving comprehension and was able to realize a noticeable improvement in performance and a slower ramp of memory over time under scaled conditions.

If for example we had 10 references , again we have one byte per reference, at 20 bytes (2 bytes per reference times 10) that brings our code chunk per User to 70kb and reduces simultaneous chunks in RAM to:

57142.85 , a full loss of over 13,000 Users. Now this example is hypothetical, we didn't for example account for any other code that might be needed per User so that we could see the effects of just changing the object allocation names by small amounts a single byte! to see how those changes eat into our available memory as large numbers of requests are made to the system. It might seem like an academic exercise, a warning that paying attention to minimal labels in our code is important but it directly affects the bottom line once that code is on a server.
The ability to serve 13,000 more Users can make the difference between software that is cost efficient to run versus one that simply wastes resources and requires either more ram or more servers to accommodate a given number of Users. The business end only cares if they can fit as many Users as possible using a given set of machines and resources. The developer tends to only care about optimization from the birds eye view of overall architecture but tends to ignore the importance of "little things" like optimizing object names. Imagine a simple task, going through your code and reducing object names by bits at a time could significantly boost the performance of your application while simultaneously getting the business side of the company to see you as a God by allowing a greater level of scalability for a given expenditure to acquire the hardware and memory /disk resources to accommodate the application. More users per server , means less memory per server, which means less cost for memory to support a given number of Users, which means cheaper procurement costs per server , which means either more servers for a given cost (to support more users) or less servers and less operating costs to support a given set of Users and that means a leaner business with a better ability to redeploy that money to other aspects of the business like say making the product or service provided more cost competitive with other providers. Another important advantage of this relentless efficiency seeking view on coding is the savings in operating costs for the required servers, if it costs less power to provide a service it means less effect on the environment, less power means less stress on the power generation infrastructure which is heavy on carbon based fuels to allow it. The computers themselves are an actual green house source in the ozone effects that accompany electric power conversion. Like the effects of tiny wind currents generated about the wings of a butterfly , the distortions ripple their energy through out the atmosphere triggering or exacerbating climate conditions in completely different parts of the world. Similarly, the effects of our code practices ripple in often unrealized ways into the efficiency of the over all business. The term "think global act local" comes time mind to explain how we should be looking at the effects of our code in order to make it both faster and tighter and reduce our impact on the business and the businesses impact on the world. I call this way of coding, green coding for obvious reasons.

So think about how you can go through your code, analyze it for references that are called often in memory and reduce their label size (could performance improvement be any easier!)...you might see a bigger boost in performance than you could have ever realized just by doing this simple task and your boss might be more loose with his wallet when bonus time comes around. ;)

Links:


concurrency (multi threading) in java

butterfly effect