IT Meritocracy. Part 11: The Holy Grail of Enterprise Software Development.

How would you build a Google-quality enterprise system, since Google doesn’t have a “developer’s guide” for unscientific enterprise software it avoids like a plague? By using Google and/or Facebook tech, right? Are you already? Using Google Maps API and storing data in a Facebook-originated Cassandra database? Great! May I ask how you access Cassandra? Through the same DAO, DTO, and Facade “J2EE patterns”, code monkeys use for old-school SQL? You saw it coming, didn’t you?

Using the latest software development tech, whether from Google or some unknown GitHub repo, is implied. I am asking about quality programming. Do you write object-oriented and functional code of Google’s quality: minimalistic, neat, robust, orthogonal, and easy to extend? When was the last time you used OOP to model business logic? Am I talking gibberish? C++ and its successor Java were invented to model complex real life entities and processes — not to write structs with functions.

Do you know exactly what your application’s business logic is?

Read this if you don’t. Let me give you a hint. It is not the DAOs, DTOs, and other dumb database passthrough code in your “middle tier”. It’s workflows, navigation rules, security, document management, and many other things Google won’t touch with a 10ft pole. Nor freelancers scripting Wordpress websites.

Which doesn’t make business rules implementation any less programmatic — to benefit from meticulous OO abstraction. It sounds straightforward, but organizing thousands of conflicting business rules and convoluted government regulations is anything, but. It requires a significantly longer attention span, than algorithmically-minded Googlers are comfortable with.

Nothing’s impossible. It’s another acquired skill for a thorough and logical person, a true programmer always is. I am sorry, since Google wants to stay away from always custom business process automation, and the Great IT Consulting Food Chain is busy fixing spaghetti code or drawing pre-sales ”architecture diagrams”, looks like it is your responsibility to apply quality programming to your domain’s business logic.

The Newcomer Always Wins.

Google is not going to help you. Nor Silicon Valley accelerators. You are on your own. Like Google and Facebook founders once were. Like someone out there today, working on Google and Facebook replacement. Impossible? Think again. Two guys beat the mighty Yahoo, everyone believed to be the future of the Internet in 1998. One guy beat opulent Myspace (reminiscent of current Netflix) a few years later. Why?

a) They didn’t write their code by the book, ironically including algorithmic textbooks, one needs to cram to get a job at Google today. Was Google’s original search/ranking algorithm in the professor Cormen’s “bible”? Is 100x more efficient (meaning 100x less engineers employed) business software development part of any “enterprise architecture blueprint”?

b) Speaking of which: the headcount, Google and Facebook founders didn’t have bloated “teams” of developers and even more defensive managers pushing for unneeded functionality, unnecessary tools, and more work in general to protect their job security. The initial Google and Facebook offerings were minimalistic, uncluttered, and pure: devoid of ads and other murky agenda — giving the users exactly what they needed.

c) They didn’t care about preserving business as usual and backwards compatibility.

Should I continue? The newcomer (who knows what he/she is doing) always wins, because he/she needs to do less, and customers love the minimalism, clarity, and focus.

Today’s Facebook can be easily coded and leisurely supported by an open-source team of five. See my answer here. It can be hosted in the (hate that trendy comparison, but can’t find anything closer) blockchain manner if the donations are not enough. 90% of current Facebook’s functionality: showing ads and collecting marketing data is irrelevant for its main user: the blogger. It was mandated by investors for the “revenue model”.

The mighty Google? It is losing its battle with SEOers and other scammers. Legit content gets lost in the sea of bot-generated cleverly disguised infomercials, and boosted man-made BS. It is only the matter of time, before someone devises the new robust ranking algorithm to segregate real information from marketing. Just like Larry and Sergey developed theirs — certainly not based on ML or another dignified “science”.

The Progress Is About New Products. The Cost (Reduction) Always Follows.

1980s mobile phones looked like suitcases and costed a fortune. Now everyone is carrying several rooms of 1980s mainframe equipment in his/her pocket. Cars were prohibitively expensive before the Model T. Inventions make technology both orders of magnitude better and more affordable.

With 100x less code to write (if you know how), everything free (open-source), and prehistoric data centers (together with their TechOps, DevOps, etc. personnel) replaced by dirt cheap cloud hosting, single-purpose consumer services like blog platforms (Facebook) and messengers (Snapchat) can and should be 100% free: meaning devoid of scammy privacy-invading marketing “revenue models”.

While inherently custom multi-million enterprise systems should cost 100x less — finally affordable by smaller companies with the same automation needs as their Fortune 100 “competitors”. Can someone tell me, what’s the principal difference between a local mortgage lender/broker and the big bank — business process wise?

I described the “bricks” (old school ERPs) vs. “pagers” (Excel spreadsheets and Zoho) issue here. Both were killed by an orders of magnitude better product: the smartphone. The key word is “better”. Did Apple invent the modern smartphone to be cheaper? Steve Jobs has never been bothered by his product prices.

The cost, all MBAs seem to focus on, is the byproduct of quality. Technical progress is not driven by cost reduction.

It’s engineer’s passion to invent new products and revolutionize existing ones feature-wise, that always, every single time, brings the cost down.

See? It is, again, a 100% technical problem. “Big tech” would have never happened, if MBAs ran the show at Googles.

Software engineers are frustrated with existing technology because its inefficient. Our MBA bosses? Because it’s “expensive”. What engineers do? Invent ways to make software development more efficient. Non-technical efforts to make it cheaper? Only by dumbing it down.

How else can one make the product less expensive without reengineering it? Which requires an engineering degree, for starters. Imagine coming to a BMW dealership and shopping for something you cannot afford. How would non-engineers working there fulfill your need? “Here. Buy this nice used Corolla someone traded in yesterday. Still too expensive? We can sell you our janitor’s bicycle. Can’t afford that? Here’s the skateboard someone found in the dumpster.”

Reminds you of something? Three decades of attempts to replace programming with mythical DIY tools, because programmers are too damn “expensive”. Followed by dumbing down the industrial (e.g. Java) programming itself to give it to third-world code monkeys.

I am all for simplifying things i.e. reducing the number of moving parts. Through robust (meaning complex) automation. The enterprise software industry needs to make just a bit of an effort and develop complex professional tools to effortlessly build better and less expensive products with. It’s classic engineering, isn’t it? Investing into a tool? Do they teach that in business schools?

Google wasn’t brought to us from above. It spawned off the 1990s software industry, which is now split into two distinct ones: the space age consumer tech ran by engineers, and decaying corporate IT led by aging MBAs.

The industry should have stayed whole. B2C inventions should have spilled into enterprise software around mid-2000s, when the “big tech” emerged.

It didn’t happen. Mesmerized by “chasing the sun” and other managerial “innovations”, IT CIOs were busy reducing costs through outsourcing. The Great IT Consulting Food Chain was busy maximizing its man-hour revenue. No one needed productivity. Still doesn’t. Only the customers.

Hence, after the 20-year stagnation in the enterprise part of the industry, nothing exists there to compare with the projects given to L6 engineers at Google. What’d be the closest IT equivalent technology-wise? Not the code mindlessly typed by you know who. So called Enterprise Architecture “deliverables”: vague “J2EE” (that’s Java v.2 Enterprise Edition vs. the current v.9 of normal Java) advise or glorified Kafka tutorials presented to technically illiterate C-level audience as POCs?

Suppose someone goes beyond a POC and builds something. Where would it fit within the Great IT Consulting Food Chain? I came to terms with not being welcome at B2C “big tech”, since I reek of unglamorous IT, and my Px100 Platform is not algorithmic and scientific enough for Google. Where would I take it? To Oracle or Salesforce? They stopped being software companies (in the true, Google sense) long time ago, not different now from Deloitte and the rest of the Consulting Food Chain, living off man-hours. I doubt Oracle would want 100x efficiency robbing it of the man-hour revenue stream, let alone cannibalizing sales/support of the ancient junk it keeps buying.

The Holy Grail of Enterprise Software Development.

Am I alone? Others must have developed similar things — rejected by Googles and the IT Consulting Food Chain. How much it is worth w/o buyers?

Can one put a price on getting closer, than anyone could ever imagine to the Holy Grail of inherently custom business process automation: turning complex mission-critical systems into developed once, sold millions copies of consumer software?

I’ve been in the industry long enough to witness all kinds of crusades.

Semi-DIY tools? Never touched by the “power users”.

Configurability? No user wants to go through a thousand of checkboxes controlling features requested by every previous customer, yet missing the critical ones for the new client. Eventually added to that list.

“Customizable” and “integratable” ERP “packages”? A poorly disguised custom programming in awkward COBOLish “business-oriented” languages, one could do 100x faster with industrial-grade custom programming e.g. in Java.

What hasn’t been tried? Quality programming. Fewer programmers armed with state of the art power tools — doing 100x more. Enough to make a difference? Retiring thousand of checkboxes, “business-oriented” languages, “integration”, and the rest of the stuff that turn old-school ERPs into multi-million (70–90%) failures. No longer needed, since unique features can be added instantly — giving every SaaS subscriber an illusion of a dedicated team working just of them.

A team of five supporting infinite number of those clients within a single vertical. Not single-minded Facebook or Candy Crush users. Lawyers, doctors, auto dealers, and insurance agents to name a few — all with unique business processes and quite complex needs. A pipe dream? Mobile phones once were.

Almost forgot. That stuff will work. How much the mere reversal of the infamous 70–90% IT project failure rate is worth? I am talking about $10–100M projects. Is making or saving those millions worth pre-outsourcing wages: $400K in 2018 money — Google pays its L6 engineers?

The Return of the Engineer.

Did I Prove the Theorem? That the true programming, only the few are capable of, has never been a commodity occupation.

Isn’t software supposed to be built by… diligently programming computers? Instead of DIY mouse clicks, customization, integration, or dumb third world brute force? Consulting? Architecture? facilitation, mitigation, and other “management”? What they have to do with programming? There are no “architects”, let alone functional managers at Google. No “buy vs. build”. It’s about one thing: engineering. Why today’s B2B software development is about anything, but? It needs the return of the Engineer.