How to be an evil start-up CEO

April 1, 2014 § 3 Comments

Being the CEO of a start-up is fun. Being evil and mischievous is fun. Completely destroying one’s life dream is fun. However, reaching expertise in all three requires considerable subtlety. Here are a few notes for the day I decide to become an evil mischievous start-up CEO.

  1. I will keep in mind that my main currencies are time and credibility, both inside and outside my startup. Therefore, I will make my best to maintain that credibility and save that time.
  2. For this reason, although I pay them, I will describe my employees as trusted colleagues. I will, however, treat them as incompetent children.
  3. Conversely, to ensure credibility, I will encourage my trusted colleagues to worship me.
  4. For some reason, my relationship with trusted colleagues tends to alter when trusted colleagues realize that I lie to them. Which is why I will use threats and dissimulation to ensure that they do not.
  5. Being worthy of worship, I am the sole holder of the truth. Consequently, everything I have just told my investors or prospects is true. Trusted colleagues who fail to base their reality upon my truth will be punished.
  6. I will have trusted advisors, be they COO, CTO, CSO, CFO, GPU, tech leads, mentors, janitors, nannies or anything else. Listening to them is important. However, I know better, so there is no need to take anything they say into account.
  7. Being a CEO is all about taking decisions quickly. For this reason, I will avoid smoking pot or drinking alcohol. I will remain on coke.
  8. One of the roles of my trusted advisors is to help me differentiate the real world from my imagination. Do they wonder aloud whether my Reality Adjustment Factor is misaligned? Well, that is the sign that I should put them on coke, too.
  9. I will realize that some of my trusted advisors might be polite. Therefore, if one of them asks “er… are you really, really sure?”, I will take this as a hint that they may be politely inquiring about my being high on LSD. Since I am actually high on coke, there is nothing to worry about.
  10. If I have to divide my start-up in teams, I can ensure that teams can work in complement of each other. Of course, I can also ensure that teams will be at each other’s throat, which is much more amusing, especially if I live in a country where pitbull fighting is illegal. If I do organize my start-up as a pitbull fighting ring, this will, of course, open the possibility of taking bets to determine which team goes down first.
  11. Nothing motivates trusted colleagues quite as much as calling their colleagues “stupid”, “lazy” or “incompetent”, except perhaps calling them “stupid”, “lazy” or “incompetent” within earshot of said colleagues.
  12. Also, nothing motivates trusted colleagues quite as much as non-existent deadlines for imaginary clients on fabulous contracts. My trusted colleagues will be permitted to thank me for such managerial prowesses.
  13. I will claim that Microsoft, or Google, or Mozilla, or Apple, or Amazon, or Facebook, are a bunch of incompetent morons. They merely got to #1 in their respective sectors while I intend to do nothing less than revolutionize the world!
  14. In the spirit of encouraging team work, I will occasionally let a trusted colleague put his/her name along with mine as a co-author/inventor/creator of the work they have done. This way, in case of problem, it will be easy to find someone to take the blame.
  15. I could organize my company so that decisions are taken at the appropriate level by my trusted colleagues. However, this is clearly inefficient, so all decisions, no matter how small, must go through me. Should this be tiresome, I reserve the right to turn off my cellphone while I sip a Piña Colada in the sun.
  16. I realize that some of my trusted colleagues will be better than me at something. With time, many might end up better than me at most things. I could save face by deciding to take this as a proof of my recruiting skills, but this is hardly as satisfying as belittling their achievements and skills and then firing them.
  17. If I need to get rid of one of my trusted colleagues, I will have three options. The first one is to offer conditions to that trusted colleague for leaving. The second one is to fire the trusted colleague. The last one is to mount a cabal inside my start-up to get that trusted colleague to leave in disgust. The cabal-oriented solution will prove much more diverting, as I will be able to watch the cascade of consequences, plots and counter-plots, the consequent loss of time, productivity and morale, and I will be able to find out just exactly how much a lawyer charges for defending my company in court.
  18. At some point, my dream project will near completion. By then, I will have dreamed up tons of new features, and it only makes sense to start piling them up until requirements dwarf what has been realized so far. My trusted colleagues will certainly complete these final few features in a matter of days. Additionally, by the time my trusted colleagues are done, I can certainly have dreamed up a few new features. Ain’t that great?
  19. Also, a project approaching completion signals that I can reassign everybody to another project. The project will certainly find a way to finish itself.
  20. It may happen that my project cannot have all of the following features: working, released, everything I dreamed it to be. The first two features are not really important, so I can remove either.
  21. If a project has failed, or if the company has pivoted, I will inform my trusted employees. Of course, I might decide to keep the news for after the end of an ongoing death-march-to-finish-the-project-in-emergency. Just imagine the look on their face.
  22. This is also true for my commercially-oriented trusted colleagues. Just imagine them telling to their prospects that everything they have promised until this date is false.
  23. As a CEO, I will be approached by countless people with ideas. With a little effort, this will give me the opportunity to pivot as often as twice a week. My trusted colleagues need the exercise.
  24. Being an avid Mac user, I can do as well as Steve Jobs. Even better, being a Facebook user, I can also do as well as me Mark Zuckerberg. Where else could you find a CEO as exceptional as me?
  25. I will occasionally take breaks, or even vacations. Whenever I do go on vacation, however, I will make sure to keep this a secret. Just think how funny it will be when they realize how much time they have wasted coming by every few minutes to check if I had arrived in the office.
  26. While this is my company, not all trusted colleagues may realize that its money is mine to use as I see fit and that I can invest it in my luxury vacations. Some of them might conclude that I am abusing everybody’s trust, work and livelihood. The simplest solution is to fire them, but I should check with a lawyer whether I could also sue them.
  27. While I may have to lie to potential clients and investors, I will refrain from lying to (alleged) mobsters and secret services. My health matters too much to me.
  28. Also, should I be faced with (alleged) mobsters and secret services, and should I determine that the people in front of me are morons and/or easy milk cows, I will refrain from making this realization obvious to said idiots.
  29. Some of my colleagues will insist that we should not release a product that we have not tested. If they refuse to use our product because they hate it, it means that the product is ready for release. If I refuse to use our project because I hate it, it means that we should restart from scratch, re-implement everything in two weeks, then fire my trusted colleagues.
  30. From time to time, I will feel like taking a scapegoat among my trusted colleagues, because this is a cheap way to vent out frustration at failed projects or meetings. After all, there is no way said trusted colleague could figure out that competition would pay more and grab the experience gained at my company.
  31. If I attempt to enter a market saturated of products that are free-to-use and just as good as mine – possibly even dominated by Google, Microsoft, Apple or Mozilla – my investors and trusted colleagues should not worry, as I have a secret weapon: I am the smartest person in the world.
  32. If my product requires that user give up on their existing data, about their existing code, about their existing infrastructure, I will not be too surprised when users rather decide to give up on my product. That is because users are stupid.
  33. If potential users start describing my sole product as vaporware, I can just retort that Microsoft got around with delivering vaporware for more than 10 years. Of course, Microsoft got to #1 before doing so, but we are almost there ourselves.
  34. Occasionally, I will make mistakes and choose wrong paths for my company. The most amusing manner of getting away with mistakes is to pretend that my trusted colleagues have disobeyed me and taken bad initiatives. Doing so is, of course, a mistake and places the company on a wrong path, which makes things recursively more amusing [1].
  35. My trusted colleagues will often be occupied with non-productive trivialities such as building my product, signing paychecks or hunting for clients. I will have to remind them regularly that I am the sole efficient worker in this company.
  36. As my Reality Distortion Field can tell you, there is no difference between “clients”, “contacts” and “people who have looked at the website”. For instance, if our website gets 30,000 hits per month (or per day), we surely have 30,000 paying users.
  37. Occasionally, my trusted colleagues will reach milestones, possibly even releasable/deployable versions of our product. These milestones/versions will probably not match my dream ideas. The simplest way to deal with such imperfections is to treat these unworthy versions with disgust, refuse to give them a name or number and retroactively add some set of features that must absolutely be completed before the milestone is hit.
  38. Occasionally, I will be unhappy with some of my trusted colleagues, but not sufficiently to fire them. I will assigning them to a punishment project, designed solely for maximal pain. That will teach them!
  39. If one of my projects succeeds, I will know – and remind everybody – that I am the sole reason for this success.
  40. If one of my ideas succeeds, I will attempt to remember if, by any chance, one of my trusted colleagues may have spent some time attempting to convince me that this was a good idea, before this was my idea. If so, I will make sure that he/she understand how the first idea was bad and mine was a stroke of genius. If this is not sufficient, I will fire him/her.
  41. My main argument for selling to potential clients will be that they have been idiots to not use my product/service. With my help, however, they can become intelligent enough to know that they should buy my wares. Am I not generous?
  42. Although I may not have heard of weird concepts such as revision control systems, bug trackers or customer relationship managers, if one of my trusted colleagues informs me that they cannot work without such exotic software, I will simply dismiss my trusted colleague as incompetent. After all, I could do the work without such niceties, so they cannot be really useful, can they?
  43. Once I know of weird concepts such as revision control systems, bug trackers or customer relationship managers, I should probably build one. After all, how hard can it be? Additionally, I am so much smarter than everybody who has built one before us. The world will be so grateful that they will beg to use our product, once we have gotten around to building it.
  44. Should I decide that we need to reinvent yet another revision control systems, bug tracker or customer relationship managers and to use it, I will make sure that the product is tested, at least marginally, before it hosts our critical data. Of course, if my trusted colleagues insist that the product does not work, there is always time to ignore their feedback. Otherwise, how could I watch the revision control system lose all the source code of the revision control system?
  45. Should investors ever decide to audit my company with the perspective of buying it, I will adjust my Reality Perception Filter to ensure that the esteemed idiots rake. This will, of course, not prevent me from complaining to my trusted colleagues that all this work was for naught and for so little money. I would not want them to waste their health by envying me too much.
  46. Of course, to ensure credibility, I will make sure that said trusted colleagues will not receive one cent from the sale. Their health really is that important to me.
  47. As my company will undoubtedly be #1 soon, I will make sure that my salary corresponds to that rank. Unfortunately, trusted colleagues will have to satisfy themselves with salaries slightly below the minimum wage, to ensure the survival of the company. Remember, we are just a start-up.
  48. I might I come from a commercial background, but I know technical matters better than my trusted technical colleagues. After all, I know Excel.
  49. I might I come from a technical background, but I know commercial matters better than my trusted commercial colleagues. After all, I know Excel.
  50. It is a well-known fact that trusted colleagues are wimps and that they burnout faster than matches. I will keep vigilant for such occurrences, not only because it is fun to watch one trusted colleague turn into an improductive bag of nerves that the mere mention of my name will send into fits of dementia, but also because with the proper balance of (mis)management, such burnouts can propagate faster than forest fires.

Thanks for the contributions of Team TGCM, Team Malsain, Team Dixous, Team HokutoNoOpa. No animals were hurt in the process, but I intend to remedy this in part 2, to be released soon.


[1] Or coinductively more amusing, if you want to be precise.

First look at Google Dart

October 13, 2011 § 4 Comments

A few weeks ago, the browser and web development communities started wondering about this mysterious new web language that Google was about to unveil: Dart. Part of the interrogation was technical – what would that language look like? how would a new language justify its existence? what problems would it solve? – and part was more strategic – what was Google doing preparing a web language in secret? where the leaked memos that seemed to imply a web-standards-breaking stance something that Google would indeed pursue? was Google trying to solve web-related problems, Google-related problems or Oracle-related problems?

Now, Google has unveiled the specifications of Dart, as well as library documentation. Neither will be sufficient to answer all questions, but they give us an opportunity to look at some of the technical sides of the problem. As a programming language researcher/designer and a member of the web browser community, I just had to spend some quality time with the Dart specifications.

So, how’s Dart? Well, let’s look at it.

What Dart is

Dart is a programming language and a Virtual Machine. As a programming language, Dart positions itself somewhere in the scope between scripting/web development and application development. From the world of application development, Dart brings

  • clean concurrency primitives that would feel at home in Scala, Clojure or Erlang – including a level of concurrent error reporting;
  • a clean module mechanism, including a notion of privacy;
  • a type system offering genericity, interfaces and classes;
  • compilation and a virtual machine;
  • a library of data structures;
  • no eval();
  • data structures that do not change shape with time.

From the world of scripting/web development, Dart brings:

  • usability in any standards-compliant browser, without any plug-in (although it will work better in a plug-in and/or in Chrome);
  • DOM access;
  • emphasis on fast start-up;
  • a liberal approach to typing (i.e. types are optional and the type system is incorrect, according to the specifications);
  • dynamic errors;
  • closures (which are actually not scripting/web development related, but until Java 8 lands or until Scala, F# or Haskell gain popularity, most developers will believe that they are).

Where Dart might help

Web development has a number of big problems. I have trolled written about some of them in previous posts, and Dart was definitely designed to help, at least a little.

Security

JavaScript is interpreted, can be written inline in html and supports eval(). By opposition, Dart code is compiled. Dart does not have eval() and Dart code is not written inline in html. Consequently, Dart itself offers a smaller attack surface for cross-site scripting.  Note that Dart can still be used as a component for a XSS targeting the document itself, and that using Dart does not prevent an attacker from using JavaScript to inject XSS in the page.

Safety and Code Hygiene

Out-of-the-box, JavaScript does not offer any static or hybrid typing. Dart offers (optional, hybrid) typing. This is a very useful tool for helping developers and developer groups find errors in their code quickly.

JavaScript offers prototype-based object-oriented programming, without explicit private methods/fields. By opposition, Dart offers modules, classes (with support for private methods/fields) and interfaces. Again, very useful for providing abstractions that do not leak [too much].

For historical reasons, JavaScript offers weird and error-prone scoping and will let developers get away without realizing that they are dereferencing undefined variables. Dart does away with this. Again, this is a good way to find errors quickly.

Libraries

Out-of-the-box, JavaScript does not provide data structures, or much in the way of libraries. By opposition, Dart provides a few data structures and libraries.

Exceptions

For a long time, JavaScript exceptions were not extensible. Eventually, it became possible to define new kinds of exceptions. However, JavaScript still doesn’t support matching the exception constructor, by opposition to what almost all other programming languages do. Dart makes no exception and allows matching upon the exception constructor. This makes exception-handling a little nicer and debugging exception traces a little more robust.

Concurrency

For a long time, JavaScript did not provide any form of concurrency primitive. Recent versions of JavaScript do offer Workers. Similarly, Dart offers Isolates, with a paradigm very similar to Workers. Where Workers are always concurrent, Isolates can also be made non-concurrent, for better performance at the expense of reactivity. Initialization and error-reporting are also a little different, but otherwise, Isolates and Workers are quite comparable.

Speed

Dart promises better speed than JavaScript. I cannot judge about it.

Niceties

Dart offers “string interpolation” to insert a value in a string. Nice but not life-altering. Also, out-of-the-box, JavaScript DOM access is quite verbose. By opposition, Dart provides syntactic sugar that makes it a little nicer.

Where Dart might hinder

Vendor control/adoption

The single biggest problem with Dart is, of course, its source. To get the VM in the browsers, Google will have to convince both developers and other browser vendors to either reimplement the VM by themselves or use a Google-issued VM. This is possible, but this will be difficult for Google.

The open vehicle for this is to convince developers to us Dart for server-side programming – where Dart will be competing with Java, Scala, C#, F#, Python, JavaScript, Erlang and even Google’s Go – and for client-side programming by getting through JavaScript – which will severely hinder performance, safety and security.

The vendor controlled vehicle will be to integrate the VM in Chrome and Android and encourage developers targeting the Chrome Market and Android Market to use Dart. Some speculate that this is a manner for Google to get rid of the Java dependency on the Android Market. In this case, of course, there will be little competition.

Libraries and documentation

JavaScript has a host of libraries and considerable documentation. I will admit that much of the documentation one may find around the web is not good (hint: use Mozilla’s documentation, it is the only reliable source I have found), but that is still infinitely more than what Dart can provide at the moment.

In other words, for the moment, Dart cannot take advantage of the special effects, the game-building libraries, the streaming libraries, etc. that have been developed for JavaScript. This, of course, is something that Google has the resources to change relatively fast, but, by experience, I can tell that many developers are averse to relearning.

Doing it without Dart

Security

We’re not going to get rid of XSS without some effort, even with Dart. However, making sure that JavaScript offers an attack surface no larger than Dart is easy: forbid eval() and forbid any inline JavaScript. It would be quite easy to add an option to HTML documents to ensure that this is the case. Note that this option remains necessary even if all the code is written in Dart, as Dart does not prevent from injecting JavaScript.

Code Hygiene

Out-of-the-box, JavaScript does not offer any support for static/hybrid typing. However, Google has demonstrated how to add static typing with the Google Closure Compiler and Mozilla has demonstrated how to add hybrid typing with Dynamic Type Inference. Both projects indicate that we can obtain something at least as good as Dart in JavaScript, without altering/reinventing the language.

Out-of-the-box, JavaScript does not offer modules. However, Mozilla has been offering a module system for JavaScript for years and new versions of the language are in the process of standardizing this.

Also, while classes and private fields are probably the least surprising techniques for application developers coming to the web, developers used to dynamic or functional languages know that closures and prototypes are essentially equivalent. So, this is essentially a matter of taste.

Finally, clean, lexical scoping will be welcomed by all developers who know what these words mean and quite a few others. Fortunately, it is also coming to JavaScript with recent versions of the language.

Concurrency

Isolates are nice. Workers are nice. Isolates are a little easier to set-up, so I would like to see an Isolate-like API for Workers. Other than that, they are essentially equivalent.

Speed

So far, Google has always managed to deliver on speed promises with V8, so I would tend to believe them. However, recent improvements in JavaScript analysis also promise to analyze away all the cases that can make JavaScript slower than Java, and I also tend to believe these promises. Consequently, I will venture no guess about it.

Libraries

It is a shame that JavaScript does not come with more libraries. However, many frameworks are available that implement standard data structures and more.

Exceptions

Dart exceptions are a little nicer than JavaScript exceptions, there no doubt about that. However, making JavaScript exceptions as good as Dart exceptions would be quite simple. The only difficulty is getting this improvement into the standard.

Niceties

String interpolations are nice to have, but not really life-altering. If necessary, they can trivially be implemented by a pre-processor. CoffeeScript might already do it, I’m not sure. Adding this to the JS standard might be tricky, for reasons of backwards compatibility, but there is not much to it.

Dart-style DOM access is nice, too. However, adding this to JavaScript would be quite trivial, in particular with next-generation DOM implementations such as dom.js.

The result

I admit that I am a little disappointed. When Dart was announced, I was hoping something truly evolutionary. So far, what I have found out is a nice language, certainly, but not much more. While Dart is definitely better in many aspects than today’s JavaScript, given the current evolution of JavaScript, none of these aspects is a deal-breaker. However, several aspects of Dart (in particular, typing and exceptions) indicate a good direction in which I believe JavaScript should evolve, and I hope that the presence of Dart can get JavaScript standardization moving faster.

If we consider I my opinion, there are three ways that Google can get Dart adopted on the web:

  • make it the default choice for Android & Chrome development;
  • provide a set of killer libraries for the web, that work on all browsers but are truly usable only with Dart (DirectX anyone? something Cocoa-style, perhaps?);
  • spend Google-sized budgets on adoption (PR, marketing, GSoC, open-source projects, etc.).

Nevertheless, for the moment, I will keep far away from Dart and look hopefully at Scala-GWT, WebSharper or Ocsigen.

Goodbye MLstate, goodbye Opa

September 6, 2011 § 6 Comments

Tides come and tides go.

Two years ago, I accepted to join MLstate, to take lead of the R&D group, and turn Opa from a promising early-stage demo into a world-class technology. And I am happy to say that we succeeded. Certainly, there are still many things that we would like to improve in Opa, but looking back on those two years, I am proud of the work we have accomplished, of the number of topics upon which we have pushed forward the state of the art, and even of many of the mistakes we have made, because they have expanded our understanding so much.

Now, after two years at MLstate, I am leaving. Our work is accomplished and I do not feel that I can contribute in any meaningful way to what MLstate has now become, nor that today’s MLstate can keep me excited and interested any longer. In the past few days, Opa has been featured on Lambda the Ultimate, on Hacker News and on Slashdot. Small and large high-tech companies have tried and enjoyed the technology. What better time than this to set sail and say goodbye to these two exciting years of my life?

As of today, I am not the Head of Research & Development, Chief Scientific Officer or Technological Evangelist at MLstate anymore. I will keep a distant eye on Opa, but I will not design or supervise its future versions. Mathieu Baudet, our COO, is replacing me as the supervisor for the development of Opa, while Adam Koprowski is replacing me as Technological Evangelist. Mathieu is a very intelligent security researcher and I am sure that he will impose a new style to the Opa team, and Adam is a bright and enthusiastic researcher/developer, and certainly the best person at MLstate to carry on Opa advocacy.

I would like to thank my University for supporting this foray into the exciting world of start-ups. I would like to thank our CEO for recruiting such a talented team. I would also like to thank Mehdi Ben Soltane, our CFO/HR director, who managed to do his job with a nice and welcome pinch of humor, even in the toughest of times. And mostly, I would like to thank all the R&D team: Maxime Audouin, Mathieu Barbin, Vincent Benayoun, Anthonin Bonnefoy, Raja Boujbel, Quentin Bourgerie, Sébastien Briais, Valentin Gatien-Baron, Louis Gesbert, Nicolas Glondu, Hugo Heuzard, Adrien Jonquet, Mikolaj Konarski, Adam Koprowski, Laurent LeBrun, Sarah Maarek, Grégoire Makridis, François Pessaux, Guillem Rieu, Pascal Rigaux, Norman Scaife, Rudy Sicard, François-Régis Sinot, Cédric Soulas, Quickie Squeaky, Hugo Venturini, Frédéric Ye, and all our successive generations of interns[1]: you are the best team I have ever had the chance to join, it really was an honor and a pleasure working with you all and I hope that those among you who have chosen to remain in MLstate have as much fun working under Mathieu’s leadership as I had working with you all.

Time to set sail! My next missive should arrive from the next port.

[1] Sorry, I do not have the list of interns at hand. But do not worry, I enjoyed working with you, too :)

Opa advocacy

August 28, 2011 § Leave a comment

Opa advocacy and tutorials have moved to their own, dedicated blog. The topics are now covered by Adam Koprowski. Thanks for handling this, Adam!

Opa on Lambda the Ultimate (and now Slashdot)

August 28, 2011 § Leave a comment

There is a nice discussion on Opa on Lambda the Ultimate forums. If you are not familiar with Lambda the Ultimate, know that this is the place for discussing new and exotic programming languages and programming concepts, so the simple fact of seeing a thread on LtU is something of an honor for us.

See also

Edit Added the Slashdot thread.

Edit Gasp, Slashdot is down. Hey, GeekNet, if you need a scalable programming language for the next version of Slashcode, just ping us :)

Listing Opa applications

June 7, 2011 § Leave a comment

Short update The opalang website now lists applications developed in Opa (registration required – part of the closed preview). If you are developing an application in Opa, please consider submitting this to the list.

Crowdsourcing the syntax

May 30, 2011 § 18 Comments

Feedback from Opa testers suggests that we can improve the syntax and make it easier for developers new to Opa to read and write code. We have spent some time both inside the Opa team and with the testers designing two possible revisions to the syntax. Feedback on both possible revisions, as well as alternative ideas, are welcome.

A few days ago, we announced the Opa platform, and I’m happy to announce that things are going very well. We have received numerous applications for the closed preview – we now have onboard people from Mozilla, Google and Twitter, to quote but a few, from many startups, and even from famous defense contractors – and I’d like to start this post by thanking all the applicants. It’s really great to have you guys & gals and your feedback. We are still accepting applications, by the way.

Speaking of feedback, we got plenty of it, too, on just about everything Opa, much of it on the syntax. This focus on syntax is only fair, as syntax is both the first thing a new developer sees of a language and something that they have to live with daily. And feedback on the syntax indicates rather clearly that our syntax, while being extremely concise, was perceived as too exotic by many developers.

Well, we aim to please, so we have spent some time with our testers working on possible syntax revisions, and we have converged on two possible syntaxes. In this post, I will walk you through syntax changes. Please keep in mind that we are very much interested in feedback, so do not hesitate to contact us, either by leaving comments on this blog, by IRC, or at feedback@opalang.org .

Important note: that we will continue supporting the previous syntax for some time and we will provide tools to automatically convert from the previous syntax to the revised syntax.

Let me walk you through syntax changes.

« Read the rest of this entry »

Where Am I?

You are currently browsing the OPA category at Il y a du thé renversé au bord de la table.

Follow

Get every new post delivered to your Inbox.

Join 32 other followers