I am Joannes Vermorel, founder at Lokad. I am also an engineer from the Corps des Mines who initially graduated from the ENS.

I have been passionate about computer science, software matters and data mining for almost two decades. (RSS - ATOM)


Entries in software (15)


A taxonomy of the Bitcoin applicative landscape

Nothing like a good initial confusion on dialog terms to trigger hours of sterile discussions; and possibly a few hundreds of tweets as well if attempts are made to have the dialog carried through Twitter. As Bitcoin was - still is to a large extent - a rather radical innovation, its early terminology wasn't without flaws. Unfortunately, the confusion that followed turned out to be rather extreme, and was ultimately solved through a major fork: Bitcoin Cash vs Bitcoin Core. As an attempt to both clarify my own understanding of Bitcoin, and to reduce the amount Twitter-induced friction, here is my first attempt at establishing a taxonomy.

A taxonomy of the Bitcoin applicative landscape

PDF (schema) at:
PDF (full paper) at:


Good software propagates its own correctness

Writing good software code is an exercise in applied schizophrenia. You need to please two radically disctinct audiences. The first audience is the compiler and the runtime. A patient and diligent audience that takes your writing to the letter. The second audience is your peers, fellow software engineers. On the plus side, this audience tries to adhere to the spirit of your writing; on the minus side, they can misunderstand your writing entirely.

Good software propagates its own correctness (with an application to Bitcoin)

PDF at


Dismal IT usually starts with recruitment agencies

In most companies, especially non-tech companies, the IT landscape is dismal: the old ERP (vastly unmaintainable) coexists the new ERP (mostly unmaintainable). Sales figures from the ERP diverges from the ones of the Business Intelligence which also diverge from the ones of the CRM. Systems are slow and unreliable. Major evolutions take years, etc. Technical debt has not been paid for years, and interests are usurious.

Root causes of dismal IT are many. Enterprise software vendors have their share of owernship in the mess, but usually they are more a symptom of the problem rather than the cause of the problem. Indeed, had the company been more prepared, no big check would have been signed to such troublesome vendors in the first place.

Such a situation calls for a 5 whys analysis popularized by Toyota.

  • Why is there so much technical debt? Because IT relies on a couple of poorly managed enterprise vendors, with plenty of functional overlaps. Those overlaps are intensified by the respective business models of the vendors that drive each one of them to spread toward other functional areas Both CRM and Web Platform wants to track audience, etc.
  • Why are vendors so poorly chosen and managed? The road to hell is paved of good intentions. A few carefully crafted Request for Quotes (RFQ) typically ends up with a fully disfunctional selection process where one of the worst vendors gets selected. The situation could have been salvaged by hevary hands-on management capable of driving the software vendor toward more reasonable designs and architectures; but middle management is clueless about IT and keeps a low profile.
  • Why is middle-management so clueless? Middle management staff never had to bother gaining IT skills in the past. Moreover, most of them managed to climb the company hierarchy just as well. Why would they bother now with tedious software stuff? Since outrageous fees are paid to software vendors, surely vendors should be able to manage themselves.
  • Why top management made such hiring mistakes? Top management had correctly anticipated that IT was a critical ingredient for pratically every single aspect of the business. However, recruiting talents takes a lot of time. Furthermore, recruiting technical talents requires to become a bit of a technical expert to assess the technical skills. Thus, it's easier to just delegate the problem to a recruitement agency.
  • Why (almost?) recruitment agencies fail in IT? Recruiting in IT is tough. The job market has been excellent for 4 decades now, and there are about zero talents unemployed. Moreover talents don't just expect a good pay: they expect a project that makes sense. Unfortunately, there are few meetings that are less inspiring than doing a job interview with a recruitment agency. As a result, candidates flowing through agencies are invariably poor.

If you want a better IT, the journey starts by re-internalizing every single recruitement.


A buyer’s guide for enterprise software

Through a series of Big Data consulting missions that were overlapping with the entire IT landscape, data being all over the place, I have observed software purchasing processes of many large companies. Being also an enterprise software vendor myself, I have been baffled countless times by broken buying processes that lead smart people routinely choose about the worst price-quality ratio that the market has to offer.

In this post, I am trying to gather a survival kit for buying enterprise software. By enterprise, I refer to companies with over 1,000 employees.

Get rid of Requests for Quotes (RFQ)

The rational goes like this: let’s write down all our requirements, then, we identify all suitable vendors, send them the RFQ, collect the quotes, review demos, and finally select the best option. Fairly reasonable, and yet, as far software is concerned, deeply dysfunctional.

Why? Because writing an accurate specification for software you need is harder than writing the software itself. It’s somehow the Heisenberg uncertainty principle transposed to software. Just try to write a RFQ for a webmail (aka GMail) if you’re not convinced. Specifying the fine print would already takes hundreds of pages, that’s only a webmail. Enterprise software tends to be a lot more complex than webmail.

As anecdotal evidence, writing and managing an RFQ is so time consuming and complex that many companies throw consultants at the problem, increasing costs even further.

Then, when the whole process is in place, guess what happens? All decent vendors walk away. Indeed, if you have a decent product that sells by itself (think Microsoft Excel), why would you bother paying an army of account managers to walk through broken RFQs? In the end, the only vendors left are either the ones so outrageously expensive that they can afford whatever it takes, or the ones selling crappy products that would never get sold without the active contribution of dysfunctional (yet widespread) processes.

My advice: Take your favorite search engine and forge yourself an opinion. It’s easier than you think, and in less than 3h, you're likely to have already a convincing shortlist of vendors. A few tips:

  • If all you find about a software is happy talk, software is worthless or vaporware.
  • If you can’t find screenshots of the software, then it means that the user interface, and probably the user experience as well, is abysmal.
  • If the web documentation is awful or absent, then whatever private documentation exists, it won’t be better.
  • If there is no public pricing, then, you will face somebody who’s professionally trained in reverse engineering the exact budget you have. That's going to be a time sink.
  • If the company does open source, then bonus points. They are not afraid that other people might have a look at the software code they produce.

Customizing Off-the-shelf Software is deadly

Joel Spolsky stated that it takes 10 years to write good software, and looking at the development curve of my own company I tend to agree. Well, it took us 5 years to realize that we were not even solving the correct problem (but this will be the subject for another post).

Software is (mostly) a take it or leave it business. Yes, you can request tiny adjustments, but asking for anything substantial is like swimming in molasses, mostly because of hidden costs. Generic upgrades won't work, support staff will be incompetent, design balance will be thrown out of whack, etc. As a result, good software companies, where people truly care and dedicate a good portion of their lifespan in carefully crafting truly valuable products, will actually decline such requests.

In contrast, vendors who will gladly accept customization requests are the one putting little value on the integrity of their product; which has already degenerated into some byzantine architecture through the acceptance of disparate customization requests over time.

My advice: choose your battles wisely. If a feature gives you an edge against the competition then internalize it and treat it as a core asset. Otherwise, it’s easier and cheaper to adjust your own organization to whatever software which reflects the dominant practice - as long the new practice offers a tangible improvement over the old one.

Bargaining over the price is against your interest

Bill Gates said that you don’t get what you deserve: you get what you negotiate. True enough but you should wisely choose what you want to negotiate. Negotiating over the software pricing is enormously expensive for the vending party. It takes a highly talented workforce, with employees both technically savvy and yet having all the smooth skills it takes to interact with large organizations. In most Western countries, the yearly total cost of a seasoned account manager is above $150k.

When you start bargaining with software companies, you also start an adverse selection process. Only the companies willing to afford an expensive sales force remains while others walk away. The vendors who stay are the ones where the business model is geared toward an ever increasing sales force. However, you want to put your money on a vendor that invest the bulk of her revenue in developing good software, not funding an army of people that specializes in reverse engineering budgets.

My advice: negotiating the price downward is usually a dead end. If it's out of budget, then discard the vendor and move to the next one.

Instead of focusing on price, you should try is to capture as much attention as you can from the core development team. Since you are an enterprise (hence a large prospect), you already got an edge here. For example, you can negotiate a small case study against a series of meetings with whoever are in charge of the core product development.

By making sure that the people in charge of the product are familiar with your business, you are vastly improving the odds that the future developments will be aligned to your company needs. Furthermore, you won’t even need to fund or think about those enhancements, the people you’ve met will do this free of charge; because it’s a natural thing engineers do when learning about client's problems.

More is less and stay clear of platforms

The inevitable corollary of RFQ is that the more advertised features the better. Furthermore, the impression is amplified by the vendors themselves who promote an ongoing stream of new features to sustain a form of recurring business (even for SaaS).

In the context of enterprise software, more features raise a very specific problem: soon enough supposedly distinct products start to overlap.

  • Both CRM and CMS (Content Management System) want to capture web leads.
  • Both the inventory management system and the accounting system want to manage suppliers.
  • Both BI and Web Analytics want to analyze the sales channels.
  • ...

Overlapping is deadly because data flows within the IT landscape start to look like the Tokyo subway map. Indeed, each time, on both ends of the overlap, divisions want to use their software, and consequently IT gets forced into moving the data around, struggling with inconsistent domain models.

Platforms are the worst offender here, because platforms are bound to overlap with practically everything else in the company. Worse, platforms create rampant dependencies making it quasi-impossible to get rid of the platform vendor later on.

My advice: favor highly focused app over jack-of-all trade apps. If you get it wrong, it will fail fast, and you will have ample possibility to try again. Most enterprises incorrectly think that managing many vendors is a problem, hence favoring Big Systems. However, dealing with hundreds of apps is quasi-painless - well, for a large company - as long as apps remain decoupled, and as long as you’re not bargaining with an army of vendors. In contrast, it only takes two overlapping platforms to create an IT integration nightmare.

Time is of the essence

In the world of enterprise software, vendor lock-in is all over the place; and yet, all enterprises I met had supposedly everything in place to avoid those lock-ins: contractual reversibility (to be able to revert to back to the previous system), contractual migration support (to be able to move forward to a new system), favorable termination clauses, etc. On the surface, extensive safeguards were in place against any vendor lock-in.

How could the reality be so different from the theory? It’s because time is the strongest and most widely underestimated vendor lock-in mechanism. What’s the point of being able to terminate a contract any day if it takes years to de-entangle operations from the vendor? As a rule of thumb, phasing out an enterprise vendor take about 3x as long as phasing the vendor in; and if it’s a platform, then you can reasonably consider your company locked on the platform forever.

Indeed, don’t expect vendors to be overly motivated by the prospect of having their products being phased out. At best, the legacy vendor will be slow but ultimately responsive to whatever problems which will necessarily arise during the transition. But that's the best case ...

My advice: Internet was a revolution. SaaS was a revolution. Cloud computing was a revolution. Mobile internet was a revolution. Software is a fast-paced industry, even more than consumer electronics. Would you buy a tablet and consider it’s an asset to be amortized over the next decade? Certainly not, it’s the same for enterprise software. No matter what software you are considering, if you can’t roll out in a matter of weeks, then move on to the next vendor. Otherwise, by the time your company is done with its acquisition, the software industry will have moved to its next revolution, you will be left with a freshly obsolete technology.

Your data is your DNA, take ownership

There is one area where COTS (commercial off-the-shelf software) works poorly for large enterprises: it’s the orchestration of the data. By orchestration the data, I am not referring to databases, ESB (Enterprise Service Bus) or equivalent low-level generic data system; I am referring to the layer on top that unify the IT landscape. This layer typically involves a mix of people and some middleware to carry on with the changes.

Indeed, COTS necessarily carry strong domain models, that it, the abstract software representation adopted to model the business itself. However, there is (almost) not a single chance that any of those predesigned models would fit a large company made of fusions, acquisitions, restructurings and possibly somewhat heterogeneous branches. Some software, notoriously SAP, can be made to fit practically the domain any large company, but there are so many developments involved, that it hardly counts as off-the-shelf software.

My advice: if there is one area where every large company should have a small team of software developers, it’s its own private data platform: an entity dedicated to the collection and the service all the data generated within the IT landscape. Here I strongly favor in-house software developers, because business data is always core business, no matter what your company is doing.

Furthermore, for most enterprises, a small tiger team of software developers in charge of the data would typically vastly reduce IT spendings compared to vast teams of recycled IT workforce. Indeed, great control over your data grants you the capability to swiftly phase software in and out, and speed is decisive. In practice, it does not take many people, but it takes talented people.


Continous migration in software development

New (and soon to be deprecated) technologies are just flowing in the Software industry. Some people pointed out that you can't stop improving your product just to keep the pace with the release flow (that's the fire and motion theory). Yet, being an ISV, your options are quite limited. You have to rely on the latest (yet stable) technologies in order to maintain a highly competitive productivity.

Rewriting from scratch your application to support the latest Foo.NET release is a bad idea; no question asked. Yet, it must be taken into account that

  • getting people interested (worse, training them) on deprecated technologies (let's say Classic ASP) is both hard and depressing.

  • not beneficing from the latest tools means lower productivity. Ex: Classic ASP => ASP.Net 1.1 => ASP.Net 2.0, each new version being a huge time-saver compared to the previous one). has been existing for less than a year and, we have already performed quite a lot of migrations.

  • SQL Server 2000 => SQL Server 2005

  • ASP.Net website => ASP.Net web application

  • No AJAX => ATLAS (betas) => ASP.Net AJAX Extensions

  • NAnt => MsBuild (when the MsBuild Community Tasks have been released)

  • VS 2005 Setup Project => WiX 2.0

  • Command Line => PowerShell (for our command-line tools)

  • IE6 => IE7 and FF1.5 => FF2.0 (for javascripts and CSS)

Among the next planned migrations

  • Visual Studio 2005 => Orcas

  • WiX 2.0 => WiX 3.0

  • Inline SQL in C# => LINQ

  • NDoc => SandCastle

  • NuSoap => PHP5 Web Services

  • osCommerce 2.2 => osC 3.0 (currently alpha) => osC 3.1 (for the plugin framework)

Our processes at Lokad involve continuous migrations toward new technologies. Upgrading take time and efforts, yet this process seems quite necessary to maintain optimal development conditions.