Anatomy of Startup Frauds

Anatomy of Software Frauds

This is an article about ethics in the tech industry.

Others in this series include, but are not limited to:

Estimated reading time is 40-50 minutes.

epub version for travel or easier reading in multiple sittings.

Here we go.

Forbes recently outlined The Ugly Unethical Underside of Silicon Valley describing the rise of objectively fraudulent tech companies. Numerous marketing-over-substance bubbles have shattered in the past few years, and there are more companies collapsing soon.

Tech frauds are built on top of three layers:

You can protect yourself from tech frauds easily. Even though it can be difficult discerning numerous bad-faith behaviors from the endless “blameless mistakes” of software development, objectively recording how your vendors lie can quickly reveal patterns of fraud in plain sight.

Build Software with Unlimited Scapegoats

Say you want to make money without the responsibility of creating working products. A good way to start is by founding a software company. Software frauds give you deniability. Software is generally considered so complex it’s basically treated as an “unknowable” quantity. You can’t be blamed for your failures because everything is just so gosh darn hard.

So, you’ve decided you can make money from software and your products don’t even have to work—great job so far! How do you end up trading your imaginary products for customer cash?

Simplest way: sell into companies where executives have big egos and big budgets1. Never sell to technical users, they’ll see through your lies2.

Avoid letting technical users get involved in sales processes too early because they may see through your product fraud before you can ingratiate yourself to those with purchase authority3.

After you convince a big company CTO they will be a literal savior of their organization by believing your product vision, you’ve tied their personal self-image to the outcome of using your product. In industry parlance, big company CTO will become your INTERNAL CHAMPION making it more difficult for them to even consider you sold them a seven figure fraud. They won’t want to entertain the fact they purchased non-working products based on schmoozing, slide shows, and ego games. They’ll never admit they got grifted.

If customers begin discovering your fraud, if they start asking why they paid seven figures for a system with daily failures and outages and data loss, just point out one or more of your built-in professional scapegoats:

It’s all okay though. You’re selling into corporate silos, so your customers will hopefully never talk to each other. Customer A, with 30 days of downtime, thinks they are just unlucky. Just try to make sure they never talk to Customer B, who also had 30 days of downtime. Multiple customers with multiple outages establishes a pattern of incompetence, not the story of blameless unforeseeable mistakes you keep pushing as explanations for errors4.

Remember: you’re selling something you know doesn’t work and will never work5.

You are selling a unified vision of productivity perfection so fragmented, if customers tried, they could prove your ideas are physically not possible. But, nobody wants to see the lies at first. Nobody wants to believe they are intentionally being defrauded, so you’re pretty safe for a few years.

If customers begin to suspect you’re lying and fraudulent, just apply some CEO-on-CEO action. Talk them down from canceling contracts early and wave away any concerns about suing you for fraud. Throw in some platitudes or even a 6 month free contract extension.

Why do Software Fraud

Why engage in direct fraud when there are real problems with real solutions you could be creating?

Creating working products is hard, let’s go sell the work of hack frauds.

You find yourself constrained by:

  • You have leadership authority, but aren’t overtly technically competent.
  • Your company’s guiding focus is a single product idea, but your single product is provably broken.
  • Your product is 5-10 years old and can’t be fixed, repaired, or made reliable in any sense.
  • You must keep your company treading water until a greater fool bails you out for billions.

We’ve seen this pattern a few times at different stages

MongoDB has been pretty fraudulent since the beginning. MongoDB’s model was lying6 about technical product features to non-technical users. “You need database? Use database! Don’t worry about our criminal negligence or inability to do anything we promise. You can always buy consulting and support to make up for broken features, sorry (not sorry) for the data loss though.”

An easy way to detect software fraud is loudness-vs-substance: when marketing always has priority over product, delusions get priority over creating better products.

Anatomy of a Software Fraud

Running a fraudulent software company is easy on one hand: hire 22 year olds and tell them to build complex systems without talking to each other. There. Now you have a giant mess of software that’ll never work, can’t be fixed, yet you’ll still have 30 independent non-integrating software packages you can put on bundled price sheets and sell to customers as “solutions.”

If you worry customers may discover your lack of expertise (or your custom made-up terminology and non-standard tech stacks) as attempts at platform lock-in, just spend a year in legal fees spinning up an independent “open source foundation” to house all your code scraps. See? There’s no lock in here because it’s all owned by a Foundation™.

Tell your customers it’s a benefit your software is “open core” with the rest being a hybrid of proprietary add-ons and hosted services.

Investors love businesses exploiting “open core” models because they give an illusion of customer freedom (and an illusion of no proprietary lock-in) while practically approximating market mechanics of addictive drugs. Sure, here’s a free sample, build your company around it. Oh, you need something fixed? You need security updates? We don’t support the “open core” of our software, but we’ll be happy to sell you our full product on a yearly recurring license. Please, step into this webinar…

Customers wanting to convert from your paid version back to the free “open core” version because you claim theres no lock-in get a rude awakening. Your customers can certainly only use the “open core” instead. After all, you don’t have any lock-in. Nope, no lock-in at all. Except, your customers will lose: security updates, user interfaces, quarterly feature updates (sorry, the “open core” version only updates features every 2 years), and access to support if anything breaks. Good luck running the “open core” version of our proprietary platform, most valued customer!

In the case of MongoDB, they simulate the appearance of open by using what is lovingly known as “the coward’s license.” Sure, you can look at the source, but anything interacting with the source in public or private, regardless of whether you distribute it or not, must also be released to the public. Business with a properly functioning legal team won’t touch AGPL code at all under punishment of having all internal trade secrets released to the public under terms of an unwanted toxic license.

It’s all okay though. Nothing else matters as long as VCs remain enamored with your marketing, vanity metrics7, and illegitimate market behavior.

Let’s break down a few more details of giant software frauds.

Minimum Requirements

Every software has minimum requirements. But, you can’t make money shipping one piece of software—you need to ship an interconnected spaghetti architecture platform.

Instead of having one set of requirements (say, 4 cores, 4 GB RAM) for one piece of software, you are a platform. You require 20 underlying bloated services, each needing 3 VMs and 32 GB RAM per VM. You are Enterprise Scale. Who cares about wasting 2 TB RAM to run an idle platform? Spending money is a sign of progress8.

Hidden Money Costs

Using a real world example, running an idle Enterprise-Ready Pivotal Cloud Foundry platform requires burning upwards of $50,000 to $200,000 per year in pay-per-instance hosting costs for an idle system with no user applications even running on it. Your platform is important because it wastes so many resources.

Those dollar figures are on top of the cost of actual system licenses, contracts, and consulting arrangements required to access the software. An idle Cloud Foundry requires over 20 VMs holding on to over 40 IP addresses just to deploy the empty management interface of your new “cloud9.”

That’s not all though: if you want to run applications, you’ll need more licenses. Please call sales and schedule a webinar. They’ll quote you yearly recurring price for “AIs” (“Application Instances”) (or “Tiles” or “Cells” or “BBS” or “Cell Rep” or “Service Brokers” or “Floating Stem Cells” or two dozen other made up terms nobody understands). You’ll have the immense privilege of paying additional fees to run your own applications on top of something you already purchased yet can’t even get running.

It’s aways easier to sell aspiration of growth over baseline reality. You’re going to need the Super Deluxe Gym Membership for $399/month, right? Not a more realistic 3 hour a week membership for $4.99 instead.

As a sales person, always push customers into believing you are their sole path towards revolutionizing digital transformation into an agile multi-cloud native future-proof company.

As luck would have it, your platform is built on top of recurring subscription per-instance licenses, and, also as luck would have it, your platform believes “microservices” are the future, which conveniently bloats the number of instances (read: licenses) required to perform even the most trivial of tasks. Such synergy! Your vision for the future of computing is extremely monetizable by your preferred business model. What were the chances?

Clearly each service your customer wants to create will need 100 individual “microservices” underneath, and each microservice will need its own instance license. Your only task now is convincing customers their entire company will run on top of your platform. Convince customers they’ll be iterating so rapidly they’ll deploy 2,000 business-value services (each with 100 microservice dependencies) before the end of next quarter10 thanks to their new, billed per-usage and recurringly licensed, Silicon Valley state of mind.

Just hearing an idle system can cost $200,000 per year in hosting before considering the six seven or eight figure licensing fees you’re already paying should make your head asplode. Any reasonably intelligent customer would kick sales people out of the conference room and blacklist said company forever. If the efficiency of an idle system is so bad, there’s no way to, even with the most generous image you could conjure, think the system deployed to production-level traffic would be efficient, reliable, or stable in any real world sense11. The product is an evolutionary dead-end12.

As someone building a software fraud, your only remaining approach is to double down on your own confusopoly. If customers can’t understand what they’re buying, they just have to trust you. Trust is how money gets made. Trust is how you get to take advantage of customers and investors.

You can see pricing examples yourself using their PCF Sizing Tool. Enabling high availability is optional (what?!), but if you do want redundancy you’ll have to run three or more copies of everything, so just go ahead and triple all the instance numbers and their associated per-hour rates.

As a bonus, enabling high availability in poorly thought-through systems decreases overall reliability. You are adding redundancy, but each component has different untested failure scenarios in its failover/redundancy/HA system13. Cloud Foundry is made from 16+ underlying services, and each component has its own independent HA mechanism14.

We can actually prove menagerie architectures built around mindsets of “just add another dependency” are unfit for any purpose.

Every component has unique:

  • failover modes
  • failover initiation times
  • failover recovery times
  • distribution models
  • state maintenance models
  • persistence requirements
  • reliability guarantees

Each interconnected component having unique requirements means customers must retain experts in each dependency of their production platform15. Dependencies aren’t independent of each other, so adding them all together decreases reliability due to their interconnectedness and propensity to catastrophically co-fail during any innocuous network blip.

Running so many different failover models as dependencies of your system makes the system provably unreliable and mentally incomprehensible. It is impossible to reason about the current state of the system (much less any of its future states), so when a problem happens, you just have to reboot everything16.

Enjoy your downtime. It’s a one time error. Won’t happen again (until tomorrow).

Congratulations: you have created a system to sell you provably can’t understand, but this also means your customers can’t understand it. Your customers will assume you’ve got it all under control, when in reality you are just as lost as your end users. Don’t worry though, you can ride this confusion for a few years and continue raking in big contracts until customers figure out your fraud. Somebody will acquire you before it all collapses, right? You’ve got rich friends in high places. Though, you can forget any IPO—you’d have to expose too many of your unsustainable financials17 to make a go of public markets.

Hidden Time Costs

When creating a software fraud, you want to offload a lot of hidden costs onto the customer, but don’t let them realize it until later.

With MongoDB, a random company’s summer intern may deploy a new internal app, install random packages, and end up using MongoDB in an in-company production capacity out of inexperience. Intern leaves, but service remains. The service is unreliable because MongoDB is an illusion, the company lost the intern who babysat the service as it was created, so now you get to hire MongoDB consulting/support to maintain an internal app nobody has time to rewrite. The system works!

With the Cloud Foundry platform, the entire system is sold as one turn-key “it just works!” platform18, but you’ve got to spend six months training your staff how to use the thing. Plus, since nobody in the real world actually uses the thing, you’ll never be able to hire people with real world experience. If, defying the logic of experiencing daily errors and infinitely recurring downtime, you continue using the broken system, you’ll have to send every employee through six months of trail-and-error training before they are caught up with how to not break your magically unlimitedly scalable platform that can’t handle more than four requests per second.

Then, at the end of your employee’s six months of training (which were kindly added on top of your original contract at a pair-programming double-the-money hourly rate), your employees discover nothing works — the system (and the sales people and the entire organization you bought it from) claims it will do X, Y, Z, but when you engage those features, the system buckles. Nothing works. Nothing was ever going to work, but your company just burnt 6 to 18 months of employee time on a platform dead-end19.

Just hope companies aren’t smart enough to dump broken products when they prove to be broken. Companies are bad at admitting they got duped into buying software and services from vendors with absurdly high amounts of self-interest. It would be a personal hit to the ego of the CTO who thought they were the one true savior of digital transformation if they had to admit they picked a shady vendor.

Companies would rather ignore negative ROI from burning a couple million dollars on licenses, training, employee time, and all the server costs it took to discover the existence of a sales-driven software platform fraud than admit they have poor executive decision making ability.

Components

To continue your software fraud, you want to build a platform as incomprehensible as possible. Make it difficult for your company to be held liable for failures because the failures are always “just a one time problem” in some dependency. You’re going to need lots of components, including many operating at direct cross-purposes.

Using Cloud Foundry as an example, look at all the components and their required instance count (each in its own VM20) required to even start: Cloud Foundry “High” Availability.

Duplicate Components

You may also ask, why are both consul and etcd requirements? Well, in true “how to build software to never work properly” fashion, you don’t want internal teams to coordinate. Make them work in teams of two, force teams to learn and re-discover everything from scratch, then never let them work on the same task for more than a day or two.

So, Team A decided to use consul for a feature and Team B decided to use etcd for a feature, and now you have two consensus systems (each with 3+ independent VMs and failure scenarios) you need to babysit to keep your system reliable.

Requiring similar, but not the same, dependencies is a great strategy for building out your software-fraud-as-a-service company. Each new dependency increases customer confusion and increases the number of things you can blame for one-off failures to mask your intrinsically broken architecture.

Sad Components

In addition to duplicate components, you also want to re-use existing software in ways it was never meant to be used.

You want to monitor services? Use monit! Except, monit has its own failure conditions and isn’t a hands-off drop in replacement for process supervision hierarchies. That’s okay though—when monit loses touch with a process, we can just reboot the entire platform again. After all, nobody runs any of this in production and, as a customer, you’re just paying for the privilege of being a free distributed QA team for other customers with similar issues.

Just Add Layers of Abstraction (JALA)

The coup de grâce of building fraudulent software is requiring everything to provide an interface according to your own misfit abstractions. Now you get to blame failures not on your platform, not on the software running on your platform, but on the mismatched abstraction between client software and the host platform.

In Cloud Foundry land, the magic error inducing, yet blame-free, abstraction comes from Tiles.

Why “Tiles?” No popular software would rewrite itself to be “Cloud Foundry Compliant,” so Tiles are the bridge between Software and The Platform. Tiles inform how to setup instances of software (including multiple instances if software is HA), automate backups, monitor software, failover software, etc.

Creating a viable Tile interface often needs just as much complexity as the underlying software itself, which breaks the central tenant of hands-off, zero-knowledge-required platform promises21.

Creating a viable Tile requires intimate domain knowledge of the software, systems, distribution, failover, backup, and disk patterns being Tile’d. Except, you, as a fraudulent software provider, don’t believe in “experience” or anything more detailed than a part time one-off, pair-programming22, sprint-the-backlog, chill-with-beach-bros, copy-answers-from-google task, so your complex abstraction interfaces end up with extremely low levels of reliability23.

Would you trust those results24? Hecks no.

Customers buy your fraudulent platform to enable high reliability of complex operations, but instead they get low reliability of everything. It’s okay though—customers already paid and signed multi-year recurring contracts, so your company can just coast on actually implementing working features for years.

You want to deploy an HA database cluster? Sorry, the Tile for that database only supports one deployment on one server as a singleton across your entire platform.

You want automatic backups for your database? Great! Just ignore when the Tile runs mysqldump over unencrypted netcat and pipes the result somewhere into the network. You didn’t care about your data or PCI or HIPPA anyway, did you? Adversaries have never installed themselves inside a network before. Nope, never. Don’t need to even consider encrypting network connections because all our networks are perfectly safe.

As with multiple conflicting dependencies, Tiles are great for one reason: each abstracted Tile interface increases platform complexity and decreases your ability to reason about the state of your running systems. The platform provider can just wave away “oops, another one time error” each time their abstractions failover and over again. After all, things are so complicated, how can anybody possibly have predicted those errors you experienced?

You’re not going to throw away this seven figure system your CTO bought, are you? The next bug fix will be the last one for sure25.

Education, Lacking

As in all good companies, you want to hire and promote based on personal relationships and by measuring n-degrees-of-friendship from the CEO’s social network.

Filling your company with 80% low-information programmers26 also helps you hide behind shields of “we didn’t see these failures as possibilities! We are blameless for our incompetence!”

As an employee, when you hear the people in charge discuss distributed engineering, you’ll think you’ve landed in bizarro land. You’ll hear things like “We’re highly available as long as network partitions don’t happen” or “We only support single datacenter deployments because you can’t have network partitions in one data center” or “We don’t need encryption because we only support one datacenter.”

When employees in charge of your product make unstable or outright nonsensical architecture decisions, what hope does your product have?

If you look through the Cloud Foundry HA docs you’ll notice signs of architecture-by-ego. The entire system is predicated on the existence of your network always being low latency and never failing or even degrading. The design constraint for your platform is: the network must never fail27. They say multi-AZ is okay, but don’t you dare try to deploy this mess in more than one datacenter or region. If any part of your network fails, you’ll have to reboot the entire platform so all the underlying components re-sync to a consistent state28.

You can build provably unstable systems while retaining plausible deniability over failures by letting agile pair-programming-above-all-else cultists who specialize in low value/high markup Rails CRUD consulting build your critical systems. You’ll end up with exactly the level of stability you’d expect from merging a couple dozen stackoverflow copy/paste answers together.

Overall

The simplest way to sell fraudulent software: establish a historical timeline of your software just existing.

Customers tend to think software gets more stable the longer it exists, so if you can’t sell your software as fast as you’d like in the first year, just hold off a little. Over the next few years, continue pushing “proof of just existing” as a proxy for product quality and customer value. Customers will naturally think since your company still exists, you must be trustworthy.

For example, Cloud Foundry is 6 to 10 years old29, originally created at VMware then handed off to a new company, yet has the reliability you’d expect from a 6 month old system still in beta testing. This hasn’t seemed to deter global-scale clients from being duped into buying a non-working platform overlay and derailing internal system architectures for quarters at a time.

Just keep your customers happy playing “forward-deployed QA in production30” against a platform they already expected to be working. If you’re lucky, they won’t have the gall to suspect you’re an outright software fraud.

S.C.R.E.A.M. (Sales and Consulting Rule Everything Around Me)

How to Sell Broken Software: A Primer

How do you make money off creating provably broken highly complex systems?

Lie Cheat Sell

Here’s a quick guide to selling high margin unreliable software for millions of dollars over a short time frame. It’s what drove a lot of over-valuations in the 90s and it has resurfaced as a popular business model leaving nothing of value behind after executives and investors cash out31.

The secret to selling broken software is: sell your broken software. Customers aren’t as sophisticated as you think. Sales teams can sell anything if they are persistent enough. High-value (multi-million dollar) sales is a game of relationships and grit with little to no concern for product quality.

You can basically run a pump-n-dump scam on your entire company. You drive the sales figures as high as possible by playing a numbers game: sales “success” or “wins” are directly related to how much you try to sell. You can sell anything if you hire sales people and set them lose on the world with plenty of incentives and no scruples.

Hire aggressive32 sales people and incentivize them on unbelievably generous commissions. They will beg, cheat, and lie to customers about anything to close a sale. Platform doesn’t have feature X? It does during a sale! Platform can’t work under conditions Y and Z? It does during a sale!

Sales behavior is aligned to personal incentives, all in service of a sales person hitting their million dollar take home commission targets. Never you mind your product creators aren’t similarly incentivized. Just ignore how your product quality has no reason to improve in the face of sales people making 10x more than product people. Enjoy your fixed salary, dumb programmers. If you were able to lie on command, you’d be invited to the executive retreats and be making real money up in sales.

Remember: your company-wide financial vanity metrics are only sales based. Financially it makes sense to ignore product quality as long as selling least common denominator features churned out by fungible labor continues to ride. You can cheat on product quality for years. Just keep pushing sales as much as possible. Nobody will notice your fraud as long as sales continue. If somebody is buying it, it must be good, right?

If anybody questions you, reaffirm you have big clients and big clients are never wrong. Big clients could never be tricked into buying architectures just from a slideshow and lies. Big clients know they need web scale and durability is a historical relic from the old days. Don’t let your customers notice most of your big clients are also your big investors and have conflicts of interest with being associated with you at all.

Sell, sell, sell. Only sell matters.

The 90s dot-com era had many companies organized around pushing sales as hard as they could then cashing out at the top, even though no working products really existed. The exact same fake-it-and-never-make-it game still works.

As your sales people contact 10,000 companies and end up with 500 sales, your product gets sold. Only sales matter. There’s a sucker born every minute. Your company value goes up, your sales continue (even if it takes 1,000 attempts for one sale—just keep calling) until you saturate every phone number you can call.

Until, one day, your fraud breaks33.

Until You Can’t No More

Report the health of your fraud-based company using expected sales flow first, actual sales second, marketing third, thoughts from your thought leaders fourth, paid customer testimonials (who may also be your investors) fifth, and then any residual product updates sixth or tenth.

You need to maintain illusions of stability as customers and media question your viability.

Remember: your customers are scared and looking for answers. Your job is to be confident and pretend to have all the answers. Build up corporate trust and high-level understanding over what goals to accomplish. At no point will customers extensively evaluate your product until after they’ve gotten so brainwashed the blindly agree your product is salvation of digital transformation in a modern era of having a Silicon Valley state of mind.

Eventually though, your fraud will be discovered. It will start slowly, then collapse all at once. Customers will see what they bought doesn’t work34. They won’t renew their renewable contracts. They won’t consume their consumable licenses. They will kick you out in the middle of your six month on-site training seminar. Word gets out. Your fraud starts to crack35.

Your company needs to enter a protective phase. Sales-driven company values are only disconnected from product value in the beginning. After about 3-5 years, the jig is up and fraud-driven software firms begin to falter. Customers notice you’re bilking them without anything working, their ROI has flopped triple digit percentage negative, and they rip you out of their infrastructure. At least your sales people got their million dollar sales commissions along the way though, so that’s good. They did their jobs. They followed orders.

The protective phase of your fraudulent startup is a shake-up phase: move some executives around36, try to impress customers by having your CEO participate on sales calls, get your CEO involved in support issues to give the appearance of “serious attention this time,” and rotate some other CxOs around to give the appearance of moving in a better direction.

Goose your numbers by blurring the line between your investors and clients. Brag about having big clients, even though your big clients are investors financially bound to you37.

Don’t let your customers realize big clients with big front-of-site testimonials are also investors protecting their investment. Build up paper thin credibility then shout it from the rooftops.

Embrace poor typographical choices and meaningless platitudes.

Forget how commas work. Re-establish your buzzword-heavy position in industry as the only gateway to the future. You are the only company enabling cloud native transformation after all. Nobody else dares compete with you.

As the fraud surfaces, your priorities become:

  • Increase Sales At Any Cost
    • implement seven figure take-home commissions for dozens of sales employees! sell sell sell even if you have to lie lie lie your way to the bank.
      • what about the lies? don’t worry, post-sales consulting will eventually get feature requests back to product developers 3-9 months after customer is acquired. then it’ll only take another 18-72 months for the features to make it into a release. customer won’t fight back too strongly, they already paid after all.
    • release PR only using non-standard accounting you can manipulate in your favor38
      • “annualized recurring revenue”
      • “annual bookings run-rate”
  • CEO happiness
    • gotta work your way up to that 5th $10 million house with even more horse farms
  • Executive happiness
    • give up, go live in Hawaii, remain on org chart as a valued member of the executive team
  • Manager happiness
    • exclusive bonus programs for all managers! (employees not eligible)
  • something about employees who do actual product work

As far as sales go, double down on a triple pronged approach:

  • sell the product
    • where sell means “convince companies to rent limited-term recurring licenses”
  • sell on-site consulting/training for product
    • mandatory, since product doesn’t make sense and uses wacko made up terminology
  • sell subscription support for product
    • mandatory, since product doesn’t work and requires routine platform developer intervention

Let your product become just one part of an entire synergy garden of other recurring high-value consulting “solutions” leveraging your provably broken platform.

Every priority will become a mix of Sales and Consulting with actual Product being a distant 5th in any decision making (until the customer is screaming in your face to fix their 10th downtime in a month). If you play your cards right, you can make your platform so complicated it’ll requires a seven figure consulting agreement in addition to a seven figure licensing agreement.

You never want to sell simple, easy to understand, self-contained, and working software because then customers won’t need you anymore. You want to sell 60% working software then spackle over broken corners with co-bundled 6 to 24 month consulting “solutions engineering” packages.

You want the MongoDB model: simple to deploy, but intimately broken software needing recurring support and consulting from the developing company itself to maintain any sort of business value SLA.

Why sell just once when you can sell three times at 300% the price?

Throw your ethics out the window. You are now a company intentionally deciding it’s perfectly legal and ethical to sell broken software requiring months of consulting before customers can even figure out if what they bought works for them. It’s a Silicon Valley state of mind.

Found Your Way to Foundering

Now you’ve decided you want easy money without needing to put in professional effort behind creating working products. How do you get started?

The quickest shortcuts for easy sales while also misdirecting customers are:

  • start from an established brand
    • exploiting a pre-existing brand will solve some social proof catch-22s
  • get big name investors
    • everybody trusts decisions of big companies and/or rich people
  • consult in areas not related to your product
    • have your consultants build “solutions” using your in-house products the customer will also end up needing to buy/purchase/acquire/license as added costs on top of the consulting hourly rates39.
  • have investors act as customers (product)
    • investors acting as customers can also help fudge revenue numbers
      • if your numbers are weak, just ask your investors to buy more products and services—bingo bango—increased revenue and they helped protect their investment!
  • have investors act as customers (consulting / service / bizdev)
    • accept investment in return for your company customizing products/services to suit the investor’s needs.
      • these arrangements can also be pre-acquisition trial runs — you become an outsourced division for your big customers and if they want services to continue, they may have to acquire you.
        • this can easily backfire if your services are too weak/fraudulent though, since your new bizdev partners will gain first hand knowledge of your inability to provide any value whatsoever. this results in negative signaling when even investors-qua-potential-acquirers refuse to be associated with your fraud anymore.

Let’s look at how the progenitor of the nonviable Cloud Foundry platform managed to establish a founded-to-fail system.

What was Pivotal?

The company name of “Pivotal” is basically meaningless now. Three incarnations of “Pivotal” have existed and nobody seems to notice the differences.

In the 90s/00s, there was “Pivotal Labs,” which failed to be a standalone success and got bought out by EMC. EMC combined unwanted parts of itself, VMware, and the remaining Pivotal assets into GoPivotal. Then GoPivotal re-branded itself back to Pivotal, which still, confusingly, had “Pivotal Labs” as a division inside of itself.

What was Pivotal Labs?

Pivotal Labs was a software consultancy which grew around a gimmick of “agile pair programming.”

You wanted to hire them to consult? Great! But, they only worked in Pairs, so you would have to buy twice the people for twice the price to do half the work. It’s a great scam if you can swing it.

Their model of programming was fairly basic. They’d consult in areas requiring the experience of self-taught teenage Ruby developers. Yet, they found a profitable (for the CEO) niche selling extremely low effort Rails customizations to clients with deep pockets.

Pivotal Labs went on to quite mediocre success. They could sell lightly customized Rails Scaffolding better than anybody else. Have a problem? Slap some Rails on it, never mind how to maintain it. Never mind it can’t scale past 4 requests per second, just come back and pay for more consulting again real soon now40.

You can see how Pivotal Labs was a basic low effort/high margin software bodyshop: you only generate revenue when you’re billing directly worked hours. In no sense was Pivotal Labs a software company with a scalable revenue stream41.

What was GoPivotal?

In 2012, somehow42, EMC acquired Pivotal Labs, the “we only work in pairs, so you’ve gotta pay us twice as much,” Ruby on Rails consulting company. Welcome to a declining corporate hierarchy already in progress.

EMC called all their acquired companies “the federation,” which included EMC itself, VMware, RSA, then Pivotal Labs.

In 2013, EMC created a new company “inspired” by Pivotal Labs. They named it GoPivotal.

Why “GoPivotal?” Well, they couldn’t seem to afford a flat “pivotal” domain name, so they decided gopivotal.com was the next best thing instead.

GoPivotal became a proud owner of the dregs of EMC, VMWare, and Pivotal Labs. The launch PR for GoPivotal was typical trite corporate platitudes:

Note the (weak) social/authority proof already in play: “spun out of … two tech companies each with billions in revenue.” We’re big, you can trust us!

GoPivotal was positioning itself as “a competitor to AWS” except, it had no hardware, no viable platform, and seemingly nobody who had ever run thousands of servers in data centers before, but sure, go ahead and ‘compete’ with AWS43.

Pivotal marketing and executives ran full speed ahead into delusional promotional behavior. They claimed Pivotal would out-compete AWS, while simultaneously claiming they didn’t compete with AWS, and in fact, their company was so unique there were no other companies to even compete with—they had the entire market to themselves!

Customers can’t compare your fraud to other solutions if you claim to be unique and incomparable across the entire trillion dollar tech industry.

GoPivotal’s launch PR continually repeated claims of “startup,” but on day 1, GoPivotal had over 1,000 employees across a dozen countries. We don’t call that a startup, it’s just an unmanageable cluster of communication overhead, pre-established political rivalries, personal fiefdoms, and unruly multinational corporate procedures—all from day 1.

Remember to carefully manage your news-speak when spinning up a company under questionable founding conditions.

Founded on grounds of investor-investee synergy: “clouds rich in EMC and VMware products,” GoPivotal’s founding software gambit, this “Cloud Foundry” thing, was primarily built to consume hundreds of cores of giant VMware installs.

Except, it turned out nobody was running the multi-hundred core, multi-hundred GB RAM, VMware clusters required for a minimum Cloud Foundry install. Nobody wanted to buy into VMware lock-in either. Ooops. Sometimes your original attempts at enterprise money extraction fail and you’ve gotta move down market.

After 4-6 years Cloud Foundry attempted to change architecture from “something on top of VMware” to a generic abstraction layer for every other platform host in existence: aws, azure, google cloud, custom hardware, anything and everything (multi-cloud).

Except properly supporting each of those targets would be just about an entire company’s worth of work itself. Ain’t nobody got time for that, so just slap some pair programming here and there then try to fake it til’ you make it.

Overall, the claims of a working general abstraction layer44 were greatly exaggerated in functionality, reliability, and performance45.

But, GoPivotal was never going to buy hardware or datacenters, so the equivalence of GoPivotal to AWS never made sense outside of marketing and CEO bravado delusions. Since original founding, [Go]Pivotal went fully into wanting to be a component on top of AWS and other platforms. You can’t possibly be cheaper than an entire platform if you’re built on top of the underlying more expensive platform.

It would be equivalent to saying you’re going to compete with Tesla by making after-market steering wheels, then bragging your company will one day be worth more than Tesla. After all, a.) everybody has to drive and b.) people use steering wheels, q.e.d. When somebody tries to inform you self-driving cars are the future and won’t need steering wheels at all, you refuse to acknowledge medium and long-term growth as being impossible. You’re having too much fun burning investor cash and wasting the lives of employee’s in attempts to buy your 4th house and 5th horse stable.

Delusions aside, a year after founding, GoPivotal renamed itself Pivotal [dawt io] and their internal IT department rejoiced at spending months converting internal accounts to a new global domain just because.

What was Pivotal?

46

GoPivotal’s first CEO was from The Industry47, but after a year, he saw GoPivotal clearly didn’t have the fundamentals. The platform didn’t work, the original founding premise of the company was already invalid (“Big data! Platform! Open source! Consulting!”), so he noped the heck out48.

Two and a half years in, Pivotal found itself needing a new CEO. Executive turnover is the always sign of a healthy company.

The new Pivotal CEO was the ex-CEO of a consulting company. Similarly, placing a consulting company CEO in charge of building out product-driven, high-growth recurring outcomes also a sign of a healthy company.

The first order of business for New CEO was demanding everybody in New Pivotal adopt behaviors of the Old Pivotal Labs cult—the reviled pair-programming agile-backlog-the-poker-24/7-video-chat delusions. Everybody in 2015 was partying like it was 198949.

Now working 9am to 6pm became mandatory50 (after all, when your CEO’s only experience is profiting off billing-per-hour, all lemmings employees gotta work the hours to bill the hours). Employees can’t be trusted. Employees must be controlled51.

The second order of business for any incoming CEO is to double promote their personal friends inside the company. If you’re a long time friend of New CEO, congrats, now you’re uniquely eligible to sell your private shares and cash out all this failure. Offer not available company-wide. Little front line employee, please ignore the fact your manager got two promotions last year, but as a policy, the company says it doesn’t “do promotions,” so you, weak little front line employees, can’t advance. Enjoy your 1% statutory raise. Sorry, policy.

After the originally declared mission of Pivotal failed52, it fell back on a reliable, but heavily non-scalable, consulting model. Full speed ahead to growing a new bodyshop consulting firm.

As a bonus, make sure your fully Internet-based and cloud-powered company requires hundred person meetings and uncompromising 0900-1800 in-office hours. No exceptions. If you work remote, you’re now required to be on video chat all day. Don’t like it? Sorry, you’re not a culture fit, please leave. Remember: employees can’t be trusted. Employees must be controlled. After all, we’re billing by the hour. We’re not paying you to not be standing in the office 9 hours a day.

At least they became halfway decent at placing OMG so quirky lol! marketing press hits.

Pivotal got stuck in a tricky position: their founding mission53 failed a year in and they had no backup plan. The original plan was to make a resource hog cloud system to run on top of VMware, but no customers wanted that kind of system. So, they initiated layoffs at the end of 2014 and dropped entire product lines customers had previously expected to be long-lived. Whoops, where’d your big data platform go?

With an ability to ignore countless failures of product, vision, and executive decision making piling up, Pivotal doubled down in an unrelenting belief of “market opportunity.” Even though nobody wanted your products, never give up prattling on about endless big opportunities just around the corner. Always next year IPO. Always next quarter big deals close. Always next.

From initial founding, Pivotal bragged “IPO soon! We were founded to be IPO-ready! IPO-ready from day 1! We’re from EMC and VMware—we are definitely IPO ready—from day 1!” with an unspoken promise of unreasonably quick payouts. Given all the mentions of IPO IPO IPO, management was obscurely timid explaining the entire employee option pool was a minuscule percentage of the company54. After a couple years of delusions, reality stuck its foot in the door.

The flagship product didn’t work, no scalable business model existed55, and it turned out selling temporary consumable hourly consulting was easier than selling higher value (overpriced and under-performing) renewable software licenses. Ooops. Sweep all that under the rug and hope a new CFO can untangle years of male ego mistakes before she’s driven away by overt unethical toxic off-gassing from The Male Management Menagerie.

56

If you can’t sell your products because a.) they don’t work and b.) nobody wants them (see ‘a’), what do you do? Well, you notice your very shiny double-the-price-half-the-work consulting division still exists.

New Pivotal decided to be more like Old Pivotal and go full speed ahead into consulting above all else. New boss same as the old boss, literally. Pivotal commenced opening dozens of physical offices around the world enabling closer direct access to clients57.

How does the product get improved if everybody is consulting and nobody is product-working? Just have your consultants with downtime take a few random hours per week to “work” on the software platform in a zero-knowledge piecemeal fashion58.

Protip: If you hire a software company who says they must open a new office near you to be effective, you’re falling down a money pit. You may never see the light of day again. Also, that’s no software company.

In addition to consulting, Pivotal’s secondary mission became a front for hiring out programmers as long-term temps in other companies—or, in modern parlance—“staff augmentation.” Enjoy working in Idaho from Monday to Thursday on internal CRUD apps for 8 months. Also a sign of not-a-software-company.

The split between “Pivotal is a software company” vs. “No, Pivotal is a consulting company” was seemingly never settled. Factions fought between which should rule. Eventually the balance turned towards a split consulting-driven and product sales model.

A product existed, so incentivize your sales people to sell it, with commissions of 5x to 10x the yearly salary of an average employee. Stupid programmer, Mr. Sales just made your entire yearly salary in six weeks. Get back to making things Mr. Sales can sell to get richer off your labor.

Though a product existed, the product didn’t work. Even though the product didn’t work, you could make it appear like it worked by saying: No, customer, you don’t understand, the product is fine, you just need six months of training. Now your sales had an easy path for attaching consulting to all product sales.

Remember: Your company value is based on sales and consulting, not product quality. In fact, you’re practically incentivized to keep products broken products and backfill functionality gaps with consulting to custom patch fixes per-customer.

Why the overt ramping up of remote consulting offices everywhere though? Was it purely to run field interference for broken software? How would having two dozen physical offices contribute to a high-growth—nay, hypergrowth—single-platform software startup at scale? Nobody really knew why and it never made much sense.

Maybe it was all just a hedge? A hedge anticipating when New Pivotal failed, Dell/EMC/VMware would let original Consulting Company CEO personally “re-acquire” the consulting division (which had expanded globally on EMC/VMware/Dell/GE/Microsoft/Ford investor money) at a discount so the perversions of software development could continue well into the future without every having to suffer but glancing blows with our shared ground truth reality.

Assemble your own golden parachute as you destroy a company’s valuation and waste the lives of employees for years at a time—Now that’s a Silicon Valley state of mind.

Pivodendum

As for the whole EMC/VMware/Pivotal/RSA Federation, Dell ended up buying The Federation and now all those lovely products are products of Dell, Inc. Dell, the world-renowned provider of low margin plastic hardware and yet another large organization where acquired startups go to die.

The new Dell+EMC Leadership is an amazing sight to behold as well, but please don sunglasses before viewing:

59

All possible thanks to Michael Dell’s $60 million Hawaiian vacation estate located next to multiple other $60 million investment banker Hawaiian vacation estates on Hawaii’s Big Island known as a “billionaire getaway.”

Conclusion

It only takes three steps to protect your company from being duped by software frauds:

Pre-Sales: Product First

When interacting with sales people, get to live product demos as soon as possible. Sales will often attempt to push demos off until much later60. Maybe they argue live demos are difficult because the product is too big/complicated/involved. If you can’t get a demo up front, there’s a good chance you’re being sold something so complex even the creators don’t even understand it. You’re being led into a money trap of professional services, support contracts, and custom add-ons61.

If sales provides a live demo, request your own changes during the demo to verify they aren’t showing you a pre-recoded demo. You may laugh at a prospect of selling multi-million dollar software by cheating at demos, but it happens. Don’t get duped.

If the product claims to have HA/DR/Failover, require live demos of the failover working, then recovering, then continuing as normal. Then have them fail the system again. Then again. Many systems can failover once, but get stuck the second or third time. Point at a node and have them terminate it then wait for other nodes to recover. If failover never happens, their software is broken and you’re being taken for a ride.

If they claim a product is easy to install, require a demo of them installing it in front of you, from initial download to full service availability. If the product is too complex to install or requires “post-sales solutions consultants” to get the software running, you’re being led into a money trap.

Overall, verify you aren’t being sold high markup Bullshit-as-a-Service. Don’t let your executives buy software based on recommendations from other executive friends62.

Involve your technical teams in sales discussions as early as possible.

If you encounter errors during pre-sales demos, run away. Don’t assume anything is just a “one time bug” or “a demo mistake.” Always assume you are being led into a money trap. Incentives for sales people lying to customers and cheating their way into signed contracts are too big. Sales people are adversarial, so don’t benevolence.

Post-Sales: Errors are Errors

After you’ve purchased a system63, log all errors, log all failures, and record any unexpected behavior.

Don’t believe it’s okay for routine errors to require a system restart.

Don’t believe it’s okay when you’re told advertised features don’t work as advertised.

Don’t believe four requests per second is acceptable. Don’t believe “scale out” solves all problems when your system has 80% unused overhead.

If you get told “you’re not using it correctly,” inquire as to why the system is confusing to such an extent professionals can’t figure out how it should be operating.

Have every team member record each time your purchased system/platform/software fails or doesn’t perform as expected across any and all interactions.

Compile all your error reports into support requests. Require deadlines for fixes. See what comes back. If the errors you filed are truly simple mistakes and your vendor is reputable, you’ll get fixes and follow-ups promptly. If your vendor is irresponsible, your requests will be sidelined, ignored, or delayed for weeks or months or years at a time.

Complaint Procedures: Require Fixes on Deadline

When you file a support request64, demand a deadline.

On initial support requests, copy your primary sales rep and any pre-sales and post-sales technical reps you’ve interacted with during your purchase.

Define the required time frame in support requests:

We need these problems fixed within 7 days.

If your vendor fails to actually fix your problems (not just “address your concerns”) within your time frame, you’ll need to bring out the big guns. Have your upper level management and/or CEO follow up as to why software you paid for doesn’t work. The fraudulent company needs to be held accountable.

Have your management send an unequivocal notice of unsatisfactory performance along with an outline of next steps if your vendor fails to fix the software you purchased:

Concerning ticket [X], we have not received a satisfactory resolution to the issue and have escalated this issue to our management.

Continued failure to sufficiently fix the errors we encounter will result in withholding of future payments, potential termination of our current contract, and a our legal department will investigate recovering previously paid funds which, in the absence of a provably working system, we must assume were obtained fraudulently.

xoxo,
Your Deceived Customer

With vendors, only financial pressure matters. If you have a recurring license, you still hold the strings. If you have a non-recurring (“perpetual”) license, your recourse may be more limited, but you can still make plenty of noise.

If your vendor is competent, you’ll get fixes.

If your vendor is incompetent, you’ll be given the runaround. The vendor’s CEO will call your CEO asking you to just calm down and back off. You’ll be able to sniff out the fraud by that point.

The strongest position you can be in as a customer is having your company’s internal team on your side. You’ll need the support of management, executives, and legal to ferret out previously purchased frauds. If your company wants the poor software to continue existing, you don’t have many choices. Maybe the software was a tit-for-tat, maybe it was a co-venture of investors, or maybe everybody else is so checked out they’re just “doing their jobs” and don’t care enough to investigate systemic failures. You have options, but you may have to fight for them.

Only You Can Prevent Software Fraud

Software fraud only happens at scale.

Nobody buys a $5 million software package from a fly-by-night company with no history and no social proof65, but companies are good at faking social proof.

It’s up to you to rely on product proof.

Notice if products don’t have any real world usage66. Don’t trust a company’s own whitepapers or self-reporting “we’re the global industry leading standard” — look for non-compensated people who believe in the product you’re about to buy. If you can’t test the system 100% yourself before purchase or if you can’t find proof of real world system deployments, run away67.

Ideally, you can find public posts from people praising software. Something more involved and personal about helping them through difficult problems and not a handful of rote copy/paste examples or yet another slog through word count examples.

It’s easy to buy into what sales people say. You’ll feel good about being an instrument of digital transformation in your company. You’ll be a hero if it works! But, without your own independent product due diligence, you’ll get duped, fail for the next four years until you finally realize nothing can be salvaged, then wonder why your skills are 4-6 years behind everybody else on the market. Everybody else didn’t waste their time running dying software—they built the future.

Don’t outsource your trust. Don’t believe vague marketing platitudes without personal verifications.

Remember to live a Silicon Valley state of mind: everybody wants your money the fastest way possible in exchange for as little as possible. Recognize the lies as soon as they drop. Kick toxic sales people and broken technical brands to the curb before they get embedded in your platforms and stifle your company for years to come.

Only you can prevent software fraud.

  1. If you’re really good, you’ll also sell into governments: big pockets, long sales durations, but zero responsibility once you get their money. Sure, go ahead and deploy your broken software into a dozen 911 systems. Money above life after all.↩

  2. We’re highly available, as long as you only deploy in one data center with perfectly reliable low latency network links.↩

  3. Though, you’ll design your product to be so complicated as to be nigh incomprehensible. When your product does fail, they’ll never be able to figure out how to fix it or even if it’s their fault or the product’s fault. You can always claim “an unforeseeable bug in one of our 60 components.” Make sure to create so many components your customers can experience independent outage just a one time mistakes, every day, for five years, and never repeat the same error twice.↩

  4. Everything must be a one time mistake even if errors repeat. Without cross-customer communication, they’ll never realize you’re fraudulent.↩

  5. It’s like you’re selling a grand unified theory of everything using physics from the 1700s. Convince your customers you have all the answers when you don’t even realize the limitations yourself.↩

  6. or deceptively minimizing with intent to fraud↩

  7. “NoSQL database company MongoDB, on the other hand, was down 11.77% since the end of May, and a whopping 54% from the time of Fidelity’s original investment in October 2013.”↩

  8. not to mention budgeting tricks in companies where “the more you spend this year, the bigger your budget will be next year” incentivizing gross over provisioning (and, by proxy over spending) on each and every trivial component↩

  9. which is a PaaS running on an IaaS which is all one big PoS↩

  10. the customer clearly needs to purchase 200,000 AIs up front, even before they’ve evaluated your platform for usability, much less baseline stability↩

  11. A popular programming meme started around the time of Rails getting popular was: now computers are cheap, but programmers are expensive, so we should let programmers write inefficient code and just throw more hardware at their poor code. That’s a fine idea for your business-value applications, but infrastructure can’t follow that same principle! You shouldn’t need to run 80 servers to launch your Hello World app just because the platform developers also follow the “well, computers are cheap, and our dev time is valuable, so we write everything using inefficient patterns” methodology.

    If systems are built so inefficiently, then every customer of poorly written products need to burn the same money, time, and excess physical resources supporting the technical debt of upstream laziness.

    Why deploy one server to handle 10,000 requests per second when you can deploy 200 servers each handling 50 requests per second?

    Oh, you want HA too? Instead of 3 servers, just deploy 600 servers. It’s all just a button click away and clearly won’t increase your complexity or decrease your reliability with unbounded communication overhead.↩

  12. You can’t even launch a “cloud foundry” on AWS without asking Amazon’s permission first. A regular AWS account limits your total running VM count by default, but one cloud foundry instance requires more than the base AWS limit.

    Enjoy paying per-hour for your 20+ (or, with HA, 60+) VMs to sit idle waiting to run basic REST administration commands (of which, the administration backend can handle about 4 requests per second. Hope you have a few hours advance notice if you ever have to scale or your entire system will collapse and need to be globally rebooted to re-establish a consistent state).↩

  13. Just because a README on GitHub says “Software Includes Failover and Redundancy!” doesn’t mean it actually works that way↩

  14. Microservices: where distributed reliability goes to die. Just making something a dependency of your architecture doesn’t make the dependency a black-box “microservice” you can operate like an on/off circuit breaker. Nothing absolves you of needing extensive professional experience across each dependency in your architecture, even if you bought it as the bed-in-a-bag of “self-healing cloud architectures.”↩

  15. and, no, hiring support from your platform vendor doesn’t guarantee they themselves even have experts on the components of their own systems. Everything is just an open source deploy-n-go black box after all. You have a problem? Ask Google.↩

  16. You can’t treat distributed systems as black boxes with “just works, never think about it” behavior. You must treat these distributed systems as needing their own full time operational management teams. If you depend on such complexly obfuscated architectures, you need operations teams who understand performance, failover, distribution, recovery, and state management for each component.

    We call understanding the combination of software complexity and business needs: “professional experience.” You can’t buy an opaque system from hucksters to replace experience when downtime costs you money. You need traditional on call rotation duties, detailed backup procedures, recovery testing, failover testing, and everything else your purchased system cannot guarantee and does not provide to any reliable extent. i.e. the exact opposite of what sales people will admit when they’re pushing broken goods and slimy services.↩

  17. Your investors are also your highest profile customers? That’s a big red flag nobody wants your products.↩

  18. The entire system is sold as a vision of a turn-key self contained system where everything is harmonious and problems never happen. In reality, it has so many conceptually conflicting dependencies and redundant pieces of infrastructure, you can just about mathematically prove it will never be reliable or maintainable or understandable without weekly reboots of your entire infrastructure. Just keep pushing your product into greenfield industries and governments where you haven’t been found out yet.↩

  19. plus the six to seven figures your company burnt in the process trying to buy rent the entire “platform” over the duration.↩

  20. An original goal of VMware’s Cloud Foundry was to cross-sell big VMware licenses for it to run on, so, just by coincidence, it over-uses VMs for every single task because you’d clearly need to buy giant VMware licenses to maintain the system.

    Plus, let’s ignore the whole system is an architecture designed around 2010 while we’re approaching 2020. Customers need stability, but being stuck in the past is the exact opposite of what fast iteration agile dojo the backlog says it gets you away from.↩

  21. Don’t worry, customer already bought the product, so the rest is just 18 months of bug fixing before the customer fails to renew their licenses.↩

  22. Pretending programmers are interchangeable with zero experience is like having a career motorcycle mechanic build you a yacht because they both have engines inside. Knowledge of “engine” is transferable between motorcycles, cars, trucks, planes, boats, drones, generators, and spaceships, right? We’re #1 Super Good Engine Consultancy. We’re double good because we always work in pairs. We will teach you how to build motorcycles and rocket ships! (disclaimer: all our self-built motorcycles and rocket ships explode after four days, don’t worry, we can teach you better than the work we do for ourselves.)↩

  23. Don’t worry, it’s only customers paying the price of all your corner cutting, nobody actually important.↩

  24. People seem to think just because things are “software,” experience doesn’t matter, education doesn’t matter, everything is just kids typing in a screen lol we can always remote patch later SHIP IT NOW!↩

  25. Is it even a “bug” if the root cause is routine institutional incompetence and lack of experience throughout the product?↩

  26. The other 20% scream through clenched teeth, wondering at which point their lives derailed.↩

  27. The only failure model they seem to consider is when a VM crashes and reboots itself? It’s unclear the rigor by which they construct their limitations.↩

  28. Marketing materials and design promises disagree with reality regarding unattended automatic failover/recovery capability.↩

  29. The older 10 year age estimate is if you count from the old VMware product(s) is was originally extracted from, then re-branded and released as Cloud Foundry, then re-written in new fad languages years later, then re-architected every 18 months and ending up re-written again and again. Stability comes from rewriting after all.

    Cloud Foundry was already a 3-5 year old failed VMware product when GoPivotal started, and Pivotal essentially re-started from scratch because the underlying system was untenable.

    Plus, computing fads had changed. Use Go! Don’t use Ruby! But, we’re a Ruby consultancy, it’s all we know? REWRITE EVERYTHING IN GO! Customers will pay for you to learn as you go.↩

  30. Though, "production QA" only exists if you can even find one company running this in production at scale for a revenue-impacting capacity. These kinds of systems tend to spend 6-18 months in a company’s internal evaluation’ processes then get deemed too unreliable to ever go live. At least the sale went through, so that’s all that matters in the end.↩

  31. lol, employees are suckers↩

  32. Your sales people must be aggressive because nobody really wants to buy you’re selling. No customer is asking for your product. Everything is going to be hard-push cold call sales (or arm twisting by your CEO to make his other CEO buddies buy your product as favor). After all, the product doesn’t even work outside of carefully constructed 10 minute long demos, but you’ve gotta still sell it to get your millions in commissions.↩

  33. “Fidelity has cut its valuation of MongoDB in eight of the nine quarters since Fidelity made its investment in December 2013, valuing the shares 58% below what it paid.”↩

  34. rather, employees 8 levels further down on the org-chart than the person who purchased the software sees the software doesn’t work—the CTO got steak-n-strippers, their job is done, they spent other people’s money irresponsibly.↩

  35. Maybe your customers notice the only search engine results for your product are media hits and your own documentation. No users have ever written about using your product? That’s shady in this era of blog blog blog it all blog it if you’re big or small.

    Maybe there are results where people write about how bad your product is, but employee shills show up to discredit them with special knowledge of "it’ll all be much better in the future, trust me, I’m paid to believe these lies.↩

  36. I hear Hawaii is a good place to send them↩

  37. It’s difficult to explain why you pumped $100 million of investment into a company then refuse to use their products, so you’re just stuck with your poor historical decision making.↩

  38. the imitation cheese products of accounting.↩

  39. Also see the IBM Global Services model. Hey IBM, we need Services from your consultants! Oh, all your consultants exclusively use IBM products to implement their Services? How convenient for you.↩

  40. And remember: pay twice the price because all work requires two people every minute of every day.↩

  41. A basic adage of startups is: when your revenue is a linear function of your headcount, you’re not a tech company, you’re just selling a markup on human labor.↩

  42. old white guy country club chicanery↩

  43. There’s always a few of these “employers of last resort” in Silicon Valley. Employers where you go if you either don’t want to or can’t get employed by Google or Apple. They aren’t extensive talent attractors, but they can attract certain amounts of talent, which end up getting sidelined by the bulk of mediocrity running the entire organization.↩

  44. portable cloud? private cloud? multi-clouds? private portable multi-clouds? porta-cloud? honeybucket™ cloud?↩

  45. remember to launch 20 to 60 VMs, just for the management layer, that’ll cost you $50k to $200k per year in addition to all the licensing, consulting, support, on top of unmeasurable costs like weeks spent chasing after endless inexplicable downtime.↩

  46. What even is a “Silicon Valley State of Mind?”

    Silicon Valley is built on serial failures with 1-out-of-1000 projects being successful and the rest never being profitable or even remotely remembered. You want to run your company by spinning up 1,000 projects just to get one success? That’s Silicon Valley.

    Silicon Valley also seems to be the place where typography goes to die.↩

  47. From Microsoft, then CEO of VMware, then left to make a “startup,” then got re-acquired by EMC (what were the chances?!), now returned as a new CEO, who left a year later because the abysmal failure was in plain sight↩

  48. Under a guise of “I reached retirement age!” which is in the range of “I’m leaving to spend more time with my family” excuses for absolving yourself of failure.↩

  49. All we need is a reboot of Alien Nation and the timeline will be complete.↩

  50. but, let’s be quirky about it and say 9:06am, lol programmer mind control management!↩

  51. Here’s the secret that every successful software company is based on: You can domesticate programmers the way beekeepers tame bees. You can’t exactly communicate with them, but you can get them to swarm in one place and when they’re not looking, you can carry off the honey.

    From http://www.call-with-current-continuation.org/rants/how-companies-die.txt↩

  52. How does a “We will teach you how to create software” consultancy run a company that’s unable to create software themselves? Maybe they’ve been selling lies for 30 years?↩

  53. “replace AWS! big data! did we mention AWS and big data? We’re gonna replace it!”↩

  54. Gotta keep those EMC, VMware, GE investors happy, don’t give employees anything they don’t deserve. Only investors create companies and only investors deserve rewards. Oh, investors and executives. Never forget the executives. Employees though? Yeah, forget all of them.↩

  55. “We were founded to be the fastest hypergrowth startup ever to exist!”↩

  56. Half of the top line isn’t even active with the company anymore. Top left was ex-CEO who saw no future in the company; top right gave away all responsibility, stopped working, and moved to Hawaii just for the hell of it.]

    Or, as stated in the launch press coverage:

    After a few years, half those people aren’t even active in the company anymore. That’s some long-term leadership inspiration right there and certainly not a bunch of connected people bailing out early to protect themselves from an inevitable onslaught of failure.↩

  57. Much like how Microsoft opened offices in every city around the world to write code for Windows users. Wait, no, they didn’t do that, because they are a software company.↩

  58. which also explains why the product continued to never really work, including nonsensical feature conflicts and the overall lack of quality throughout releases. Gotta backlog the beach anchor dojo ninjas. Experience is a burden, you can learn anything with six minutes of online search.↩

  59. Did they align rows according to head tilt?↩

  60. You are a qualified lead after all, aren’t you?↩

  61. which you’d expect should have been standard features in the first place.↩

  62. This is more difficult when your CEO buys software recommended by another CEO friend, who just happens to own a software company, and now you’re now required to use internally even though nothing works and now you get to spend 18 months in a platform death march before you can prove to your CEO you’ve “exhausted all options” and maybe his other CEO friend is just a grifter after all.↩

  63. or you’re required to use a system somebody else purchased↩

  64. which should be more formal and more interactive than just ‘filing a bug report’—you are the customer, not their QA department↩

  65. Building up social proof can happen by sprinkling in a few hundred million dollars from “investors,” who are also your customers, who are also potential last ditch effort bail-out acquirers, who suddenly give your company a proof-of-authority legitimacy. Hopefully nobody will notice your company hasn’t been valued based on products, but only based on social financial connections.↩

  66. Look for things like conference talks about using the software, but not at a conference 100% about the software you bought.

    Any press hits not placed by the vendor directly?

    Any news at all about the company not just mentioning new funding or old layoffs or their own executives bragging about their own products?

    …and customers writing about spending six months in “internal evaluation” mode doesn’t count as “deployed,” but sales people won’t tell you about all the customers who bailed on their platform in a “hey none of this works, go away losers!” phase.↩

  67. Tech frauds are easy to detect with effort, and you must put in the effort. Sales people are your enemy — they only care about reaching their million dollar take-home pay commission goals. You are a tool, an object, a percentage of a yearly goal to them, nothing more.↩

personal
howto c (2016)py structure (2024)think you can const?aboutresume