Building technology, bringing business to life
Building technology, bringing business to life
BACK
BLOG
Dev’s Perspective: Money vs. Happiness - Eat Your Cake and Have it!


September 12, 2017
This the first of my Dev’s Perspective articles, focusing on the current (end of 2017) career and entrepreneurial options for ambitious software engineers.
I want to be very clear from the start. Anyone ambitious and passionate about programming (practical engineering, not abstract computer science) should end up an entrepreneur. I wish I listened to this “cliche” 20 years ago, when I came to the US, or even five years prior to that, when I started my IT career in Belarus. What doesn’t break us (20 painful years in progressively “outsourced” American IT), makes us stronger. I wouldn’t be pursuing the next gen enterprise software, if I didn’t learn what to do and most importantly what not to over the last two decades.
I am going to talk about what I know: enterprise software i.e. data-centric systems with data entry UI, databases, reports, robust role-based security, complex workflows, and deciphered (intentionally convoluted) business rules e.g. of compliance nature.
It is hard, dirty, and very unsexy compared to consumer tech. A handful of top tech employers: Google, Facebook, Amazon, and others don’t want to touch always custom mission-critical business software with a 10ft pole. It also has zero hype-ability and “exit” potential for Silicon valley VCs compared to the current fad: AI and ML.
If you are looking to jump on one of those bandwagons (good luck w/o MIT credentials or money connections), or want to reinvent blogs or crypto-messengers for the 100th time, don’t waste your time on my series. Go back to reading Zuckerberg’s biography and envying Elon Musk and the rest of the “PayPal mafia”. If you however want to convert something you’ve mastered: your mad business software building skills into money, stay with me.

Dev’s Perspective: American Software Engineer Compensation.


September 12, 2017
First off, the numbers. Corporate IT (IT departments of non-tech corporations, Initech-size software sweatshops, and the members of the Great IT Consulting Food Chain: from Oracle and Deloitte down to boutique “architecture” firms) currently pays senior programmers $140-180K - essentially the same number, it paid in the 1990s ($90/hr == $180K at 2080 work hours in a year).
Inflation-adjusted (see a very conservative calculator here: it should have been double: $300-400K, which is not surprisingly Google’s Senior Staff compensation in 2017. Yes, you can go to Google, for all I care. I’ll cover it in another article. Read the first one I mentioned above for my reasons to limit the discussion to mission-critical enterprise software, Google doesn’t want to touch with a 10ft pole.
I’d also like to clarify, that I am only talking about accomplished aka “senior” and “team lead” level engineers. Junior and mythical “mid-level” compensation is not worth discussing. If you love programming, you grow to the “senior” level i.e. the ability to work w/o supervision among other things, in the matter of months. If you don’t, choose another profession. Yes, this is Sparta. The industry should employ significantly less people and pay them significantly more. Engineers used to make more than doctors. Sounds like your kind of world?
So, why and how IT sliced the wages in half (it’s a bit more complex, than just “outsourcing”) while Google increased them to maintain the 1990s level? And how one can arrive at that upper middle class income - w/o working at Google?

Dev’s Perspective: IT Job Market Supply and Demand.


September 12, 2017
The previous article explored the wages and pinpointed the problem - zero demand for capable programmers in corporate IT.
It may seem at first, that the current IT wages problem is caused by the supply. After a hungry billion-population country joined the Western job market, duh?
Not to mention that all markets: from stock exchanges to employment are heavily manipulated. Dark pools and price fixing are easier than ever in the age of internet, with the government looking the other way, as usual. You wouldn’t expect people you support with your taxes to actually help with anything, would you? Are you really hoping that the legislature mentioned above would actually pass as is? Leading to some semi-official $130K minimum wage in IT? Keep dreaming.
The job candidate supply has been manipulated in American IT forever. Tell me why rare nowadays specialties like circa-1995 (Win95) MFC, popular in the Windows-centric defense sector, don’t command $300K+ Google wages? Not only those jobs are not outsourceable “offshore”, they often require a security clearance. Is it because the “private” defense companies are hurting for money? Obviously the “decision makers” got together and decided (or silently agreed) how much those engineers are allowed to make. Where is the supply and demand? Or it is evil recruiters jacking up their markups? Come on. No one would offer an MFC dev $200/hr: $150 to make $300K annually + 30% recruiter markup.
Things like that existed long before the mass “offshore outsourcing” of the early 2000s. They did affect the wages, but it was OK for the most part in the late 90s. What’s changed - fundamentally and across the entire industry? The demand did.

Dev’s Perspective: Who Needs the “Architect”?


September 12, 2017
If, after everything I’ve told you about IT so far, a techie like you still wants to be a good corporate boy/girl, pleasing your bosses and serving the System, your only remaining option to maintain a mid to upper middle class income is to “grow” into a semi-managerial “architect”. Make no mistake. This not an engineering job. Pre-sales or post-sales, the so-called “architecture” is a client-pleasing sales activity, period.
I want my business partner Jason to master the art of boardroom architecture presentations. As for you, I’d rather have you working with me developing the next gen enterprise software Jason sells the sh-t out of. That’s in a nutshell my current success formula.
It doesn’t matter if you or I want to change the world for the better. It doesn’t matter if others make billions selling crap: meaningless consulting man-hours or AI vaporware. It doesn’t matter if VCs “foolishly” invest in the latter (no one “invests” his/her own money). Without “connections”, mortals like you and I need to do a lot of kiss-a$$ “networking” to get into the rich fraudsters club. I equally respect all tech-related activities: marketing, sales, and engineering, but born w/o a silver spoon in our mouths, we have no choice, but to offer our customers something real: the products and services they need and will pay for.
No pre-sales architects are needed to sell good working software. Google and other top-tier tech companies have none. The so called “architects” are “bodies” like bodyshop-supplied code monkeys churning out DAOs and DTOs.

Dev’s Perspective: the Myth About American Salaries.


September 12, 2017
I’ve been absent from the Belarusian software development community for quite some time, living and working in the US. My recent conversations with developers: both the seasoned ones I’ve known since college and the new generation of engineers revealed the same mindset I saw 21 year ago, when I left. Let me address those myths, which I am pretty sure are exactly the same in many other countries.
It’s been 30+ years since the narrow Soviet engineer salary range of 120-150 roubles per month - for life. Today’s Russian, Ukrainian, and Belarusian salaries range from $500 to $5000+, based on a variety of factors, the technical skills being only a part of. Trying to find some average one is entitled to is myopic. It was like that during the Soviet era of guaranteed employment and frozen prices. That era is gone, so don’t compare one meaningless average to another from a different country. Software engineers capable of juggling 10 different concepts at once (the human brain comfort level is three) should know better.
They should also know by now how the “free economy” functions expense-wide: the official taxes, mandatory insurance, compliance, and other racket: forced services, designed to enslave the powerless middle class, making it live from paycheck to paycheck.
I’ll make it simple for you. It’s perfectly normal to be curious about others’ salaries, and despite the popular belief (and draconian confidentiality agreements) Americans discuss and compare them quite often. However, when it comes to income, you should always count money in your own pocket, not somebody else’s, or worse, comparing national averages. Are you average? I don’t think so. Then research the salary you’d get in the US - at your current technical and communication skill level.

Dev’s Perspective: Any Reward for Learning New Technologies?


September 12, 2017
I am going to cut to the chase. Unless you are a total moron, an Ivy League MBA guarantees you a corner office. There was a time, when the programmer education credentials didn’t matter as much (compared to managers and lawyers). Outsourcing or something else, that time is gone. Get into CalTech, MIT, or at least Berkeley. Programmer career is no longer unique - exempt from the atrocious regalia grading of the rest of the white collar world. The CFOs dream came true. Software engineers are now the same, as mechanical and electrical ones: placed slightly above Accounts Receivable clerks. A$$-kissing politics and education regalia started to matter again in programmer’s career.
Isn’t it ironic, since the Medieval concept of an education shrine has completely lost its relevance, at least in the inherently virtual Computer Science? No one needs slots of shared mainframe time anymore to run a deck of punch cards. Any other expensive lab equipment?
No in-person mentors are needed due to vast social networks. There is plenty of guides for beginners wondering where to start. Everything needed beyond that level: API specs, well-documented open-source frameworks etc. is easy to find and free. The technical progress keeps making programming tools simpler and easier.
I still think all developers should attend a college - to test their IQ and stamina. But as far, as the college rank… I have one word for you: Coursera, if one ever needs to take a formal class to [re-]learn some fundamental.
Cutting to the chase again, you should only study something when you need it. Technologies change every year. It is impossible to memorize everything. And why? Contrary to Google and Amazon interviewer opinion, a software engineers’ job is not a continuation of midterm and final exams to test how he/she learned the new hot abbreviations.

Dev’s Perspective: Revisiting Job Hopping.


September 12, 2017
I’ve written on this topic before. Granted the true engineering-centric employers have finally emerged: yes, Google and a handful of the top consumer tech companies, one shouldn’t plan to stay even there for life. And no, infamously cheap and exploitative Microsoft wasn’t such engineering Mecca in the 1990s. Nor IBM, Oracle, SAP, and other heavy hitters of the IT Consulting Food Chain before Microsoft.
The rest of the IT, where one is likely to start an enterprise software developer career, has become one giant Initech. It’s not all bad. Sure, corporate IT paid twice as much (inflation-adjusted) before the 2002 outsourcing bonanza, but it never provided even a glimpse of the solid career path Google offers. Meaning one had to change jobs to simply get a raise.
Job-hopping is your only option at the first job. Which, let me remind you again (after earlier articles), should be the place and time for you to make a leap from a junior to senior developer within six months or less. If you cannot do it, job hopping wouldn’t help. Cut the losses short and find another occupation.
If you can acquire expert programming skills within six months, they surely won’t be appreciated by your employer, since you’d be committing a cardinal HR sin of asking for a more than 3% raise. You’ll need to leave. Job-seeking (and hopping) is a confidence-building skill of its own, that relies on communication, networking, and many other things to sell yourself. I advise to at least try it.

Dev’s Perspective: Architect and Middle Manager “Offshorability”.


September 12, 2017
I remember working at the headquarters of a well-known F100 company. Its IT was completely “outsourced” “offshore”. They brought a CIO from GE - specifically experienced in moving jobs to India. He was unceremoniously fired five years later after wasting $190M (unofficial number), but that’s a topic for another article.
I was surrounded by “discount resources” proudly displaying miniature Indian flags on their cubicles. No one bothered to speak English. But when they did, even the lowest code monkey used condescending PM lingo like “resource” and “offshorability”, trying to distance himself from the five times bigger workforce in India. The concept sunk in. Let’s talk about “offshorability” of software architecture and middle management, a senior developer may view as an outsourcing-free haven.
I’ve worn one or another architect title and a couple of managerial ones for the most of my corporate career. As you can probably tell by my opinion on the matter, I’ve been outsourced a lot.
You can read my take on “software architecture” here. I have enormous respect for Fowler and others, but if you stay in IT promoting the best of the patterns and architecture principles e.g. microservices, they’d still share the fate of Scrum - butchered by clueless PMs and hated by everyone. Have you seen microservices or Docker turn an IT department into an enjoyable workplace with fair compensation? Keep dreaming.
Solution Architects are often hired to communicate business requirements to the (always outsourced) junior coders. You may even think, that your ethnic background (Hindi-speaking for an Indian team, Russian-speaking for Russians, etc.) would be of value. Certainly. Your outsourced paycheck however would be a different story.

Dev’s Perspective: Is Google Still an Engineering Company?


September 12, 2017
Google has arguably done more for our technology-driven civilization, than IBM and Oracle combined, though those old school companies made the essential inventions Google would be impossible w/o.
Having shown the proper respect, the past and even present doesn’t matter. The future does. Not the Forbes projections of Google “quarterly earnings”, but your own future at Google.
Quora is typically the best resource for Google, Amazon, and Facebook inside stories. I am not going to repeat or even link ex-Googler concerns about the direction of the company. You can find them yourself and, yes, ask “what’s in it for me?”
I can only tell you about my own (would be) employment experience with Amazon and Google. First, there were typical sourcing misses. No, those companies are not on a lookout for smart kids to find appropriate jobs for them. Nor Google and Amazon internal (HR) recruiters are much better than typical telemarketer-level sourcers harassing you daily. Second, when the stars align: sourcers doing their job correctly, you get to the infamous algorithmic interviews. There isn’t much to say about those, other than I am too old for that sh-t.
Honestly I was too old for those coding exercises even during my third year in college (“institute” as it was called back then in Belarus) at the age of 20, when I got my first big project: to design and implement a bond trading system. Fascinated by the first graphical Windows release, I failed miserably by trying to mimic the consumer (file manager’s drag and drop) UI. I learned my lesson. That failure and all successes and failures of 20+ subsequent multi-million projects had nothing to do with algorithmic aka “competitive programming” proficiency tested by Amazon and Google at their interviews.

Dev’s Perspective: Are All Self-Funded Opportunities Gone?


September 12, 2017
If you read the previous ones, you know what to anticipate in the grand finale. There is no place for you in the outsourced corporate IT. There is no place for a passionate engineer at the academics-biased Google and Amazon. There is no place for you at “funded” Silicon Valley AI vaporware startups, unless they can hype your ex-Googler or MIT regalia.
I hate to sound like the old Soviet propaganda showed down my throat in the elementary and middle school. The industry was OK 20 years ago, but now it exists to exploit you - at best. And is slowly dying - the scary part. Not only the current System won’t reward your intellectual contribution. In most cases it won’t even know what to do with your inventions. You need to take matter in your own hands and build your own world outside of the current System.
The (seemingly) bad news is all easy niches being taken. No Yellow Pages like directory that made Elon Musk rich. It wasn’t black and white even in the tech-hungry mid-90s. Google and Salesforce were founded on true inventions, while Zip2’s sale to Compaq is yet another “exit”. Why not IBM or HP: in need of an online business directory engine too? One of heavy hitters on Zip2’s board made it happen, not Musk’s genius and charisma.
You can read the Zip2 story here. Most people prefer to talk about the more glamorous “PayPal mafia”, ignoring what made Musk rich, opening the doors to the big boys club, where financial startups are founded. We are starting exactly like him: self-funded. But the time of taking smart, ambitious, and hardworking kids, like Musk under the VC wing is gone. Unless one has an MIT diploma or Google on his/her resume; or an “industry influencer” daddy.
Startups have always played that game. I don’t think even half of “unicorns” came out of legit inventions even back then, when it was easier. Now it is simply impossible. The club of “serial entrepreneurs” and their buddy investors closed its doors long time ago. You can only start self-funded today.

Dev’s Perspective: 2017 Career Options for an Ambitious Software Engineer.


September 12, 2017
I hope you enjoyed my series. Time for a recap. What are the current (end of 2017) career options for a founder-level developer? Founding his/her own startup? Of course, but it’s not so simple and black and white. Let’s list your options from best to worst.
Option #1: Your own company should always be your ultimate career goal. Don’t be like me hoping the job market would improve or someone takes you under his/her wing. However just wanting to be your own boss or even mindlessly pivoting is not going to bring you any closer to the financial independence. You need to be ready to strike.
Option #2: How to prepare to found your software startup? That involves suffering in the decaying corporate IT for a few years. Change several projects/employers carefully choosing their markets/niches - most suitable for your future startup. Observe, network, plan. Once you feel you stumbled upon something valuable, develop the MVP part-time, find a sales-savvy partner (we can help) and leave.
If you are coming to the US on an H1B, you’ll really have no choice until you get the Green Card. Use that time wisely: exploring niches and building connections (among the clients). Not pleasing your greedy bosses, hoping for a “career” at your bodyshop.
Option #3: Your next option is joining a legit startup founded by someone like you (or us). Grow with it to become a multi-millionaire. Or graduate from it and grow on your own - see Option #1. Not sure about others, but if it is us, we will support you in your entrepreneurial endeavours.

My Entrepreneurial Journey: 2017 Recap.


August 20, 2017
I may be embarrassed of this article five years from now even more, than I am embarrassed of my 2012 entrepreneurial statements. Nevertheless I’d like to tell the inquiring minds where my LionStack partner Jason and I are today.
Here’s what I did before I met Jason:
  • Naively tried to turn huge custom ERPs into monthly-subscription SaaS.
  • Offered my partnership to a couple of people with trustworthy ideas, that needed an enterprise system, but wanted to manage a cheap freelancer.
  • Gambled on a flashy, but too disruptive (to please the industry influencers) consumer idea.
  • Saved and single-handedly rebuilt a data-heavy multi-million B2B SaaS as a private contractor - to leave that project in February to concentrate on LionStack.
Here’s what Jason and I accomplished in the last six months:
  • An equity-based three-platform professional network system for psychiatrists.
  • Several well-researched and prototyped pivots we can still return to: HRMS, high-end smart home server, and targeted CRM on steroids.
  • Dead-simple, but robust inside internal ticket system centered around developer needs.
  • Custom insurance CRM solution for a paying client.
  • Our first developer - to groom into a future technical founder.

"Visual" Software Development - Industry's Toddler-Size Lego Blocks.


November 30, 2015
Oracle Forms inspired almost all today's DIY software development techniques focused on automatically generating UI from the database schema - to remove programmers from the equation. MS Access still reigns among those tools for semi-technical power users. However like all pre-Internet desktop UI designers Access is completely foreign to the Web page paradigm.
Salesforce fixed it by developing Cloud-hosted "hyper-Access" for the Web. The second, simpler class of modern Web-centric "visual" database editors is Content Management Systems (CMS) aka Electronic CM (ECM). There are also DMS/EDM (Document Management Systems) that organize documents associated with metadata used to control simple workflow and, yes, generate Web content.
CMS are incredibly popular. Nearly half of the world's Web sites is written in WordPress, while Drupal is a common choice for small business automation. However neither Access, nor semi-DIY CMS were designed for applications over 50 screens with intricate role-based security and workflow. Should their capabilities be extended, they would lose their appeal to non-programmers - evolving beyond semi-technical person comfort zone; While remaining as dumbed down and professional programmer unfriendly, as originally designed.
CMS' focus on UI, rather than workflow automation, created demand for yet another class of big Lego blocks for non-programmers: Business Process Modeling (BPM) and Business Rule Engines (BRE). Both allow drawing pretty flowcharts and decision tree diagrams. If all you can or want to do is mouse clicks, you've got to have those "visual" tools to save you from typing if-then statements.

"Work Hard, Play Hard" and "Work/Life Balance"... Run Away!


November 10, 2015
No one will ever hear those silly statements from me at the interview. Some things are better left unspoken. People cannot openly call themselves pretty or sexy - unless it is a joke between close friends. With the exception of one cheesy movie Google doesn't advertise its work environment. Everyone knows about it. Google has worked hard to build that reputation.
So when some HR rep mentions the "work/life balance", he/she is waving a big red flag in the candidate's face. Why not simply say, "We pay well"? That's it. Pay me well, and believe me, I'll take care of my work/life balance better than anyone else in the world. I'll "play" as hard, as I can... afford.
What if my idea of "playing hard" is doing a trackday in a Lamborghini? Hell yeah, I'd work 12-hour days and weekends for that. Not so much for weekly team-building events at Dave and Busters. Am I too greedy?
Software engineers are six-figure professionals, not minimum wage workers happy about every perk. All "benefits" combined represent a rather small percentage of the senior software developer compensation package. Tacking something on looks like a cheap trick. Engineers are good at math, programming complex calculations every day.
Why to "sell" candidates the company at all? One can make tons of observations right when he/she walks into the office for an interview. Not by hip and trendy decorations, furniture, or computers. It is how people walk, talk, and smile. Do they look rested or they fought yet another 3am fire? It'd always show if they are confident and happy.

Anything Left of IT "Human Capital"?


October 3, 2015
IT hasn't always favored "buy" over "build". It employed normal engineers doing normal software development 20 years ago. That era is gone.
The first exodus of IT talent was in the late 90's during the dot-com boom. It disrupted the normal career pattern of many talented engineers, who skipped necessary steps without proper intellectual contribution to earn their move to corner offices - the inventions they could have made in their engineering, not management role.
Worse, they were expected to become the next - younger and better skilled generation of IT leaders if they “grew” in IT instead of dot-coms. What happened to young people in corporate IT anyway? The new generation of engineers - to replace those who went to dot-coms in the 90's never came: scared off by the wage drop caused by offshore outsourcing. The damage is irreversible - serious generational gap in IT.
“Offshore outsourcing” was never intended to replace "onshore" engineering creativity. Cheap labor never does. But if generals gather huge armies of riflemen, they lose incentives to improve tanks, aircraft, and other advanced robotized weaponry. All of our Civilization's technical breakthroughs were aimed to reduce low-level labor - driven by the shortage, not abundance of workforce. Not surprisingly nothing has been invented in the enterprise software industry since the last leap - 1999 Salesforce SaaS revolution.
The scarce senior engineering staff that “survived” IT outsourcing was presented with a tough choice: to accept the falling wages or move to greener pastures - joining the multi-level IT Consulting Food Chain which traditionally specializes in selling expensive third-party software and support services. No more financial reward for solving IT automation problems, only sales of something already developed, and quite frankly needed to be replaced long time ago.

Two Challenges of Today's Business Software Development.


September 10, 2015
Fighting business automation complexity is hard - way outside of the most brilliant and energetic consumer tech entrepreneur comfort zone. Otherwise we would have seen the new generation of enterprise software by now. No one wants to touch it. No one enjoys untangling redundant and convoluted government regulations - the main source of business automation complexity.
Two fundamental technical challenges continue to plague the industry. First, enterprise software is no longer a product one can build and sell multiple copies of. It would have been such in the perfect world free of convoluted government regulations. Today’s mission-critical business software is a service that primarily guarantees continuous compliance with those never ending regulations. The “initial” development never stops due to constantly changing business process and document flow.
This is the fundamental shift everyone needs to accept: designing software for change - as constantly evolving services instead of “customizable” products. And no, hosting such product online to join the “SaaS” club does not automatically turn it into a service.
The second and much bigger problem is satisfying unique customer needs. Not two businesses are alike. Generic accounting and CRM apps may only need a few "tweaks" for the particular user, but robust specialized software is custom by nature. Not “customizable” - custom. Even if the difference between two customers’ business processes is only a couple of fields or reports, at the current software development level, the amount of code (and personnel) required to support those two versions is comparable to developing two brand new systems instead.
“Customizable” is perhaps the biggest industry myth. Heavily “customized” products mean only one thing – they are generic to the point of being useless out of the box.

From 4GLs to Targeted Frameworks.


August 2, 2015
Ever since the granddaddy of "business-oriented" software development tools, 1960s COBOL, their creators felt compelled to target semi-technical (at best) power users instead of normal programmers.
Classic programming languages like C/C++ and Java are "orthogonal": allowing the programmer to express absolutely anything with a minimalistic command set. Business-oriented, data-centric and other so-called 4th Generation Languages (4GL) are the opposite - envying English with hundreds of special keywords, suffixes, prepositions, and complex grammar.
Not surprisingly those languages are extremely hard to learn. Sane "semi-technical" users stay away from such "convenient" tools, leaving them to the special class of programmers - driven by money. I refuse to believe anyone who loves programming is enthusiastic about ABAP or Apex.
What really puzzles me is... with all variable declarations, if statements, loops, and other programming features completely foreign to power users, why not just make a business-specific library for C++ or Java and offer it to programmers? Visual tools can generate C++ or Java code. Make those WYSIWYG designers IDE plugins, and the IDE will take care of the rest: compilation, deployment, versioning, etc. That is current Oracle "middleware" - Java libraries and tools developed by companies it acquired.
The problem is, the aforementioned libraries are heavy multi-purpose old-school frameworks. Even horrible 1990s 4GLs and mid-2000s BPMs could have had a chance if they weren't so generic and bloated with "just in case" features. Some technologies are better off conceived by engineers, than marketing departments. No other agenda, than helping your own staff - and no one else - to become more efficient by targeting their specific challenges within your specific domain.

"Bricks" and Pagers.


July 15, 2015
We laugh at 1980's “brick” phones, but only a fraction of the population could afford them at the time. And now everyone carries a slick touch-screen computer in his/her pocket - more powerful than multiple rooms of mainframe equipment.
Despite all the amazing advances in consumer technology, business software has been stagnating for 15 if not 20 years. Corporate IT is still in the “brick” era. Rewriting some of its software in “modern” languages changed nothing, as it is still based on 1970s mainframe architectures.
A “brick” is a “brick” - even fitted with backlit buttons and color display. What makes it a “brick”? Not the size - price. Something that still costs a fortune (in customization and support fees for enterprise software) decades after its invention is... well, a “brick”. Something that barely performs... Mainframe-conceived architectures can no longer handle increased business process complexity.
Technology stagnation affects everyone - primarily smaller companies that cannot afford “bricks”. As unreliable and feature-poor, as “brick” phones were, the only affordable mobile communication solution of that era was little pagers. That's what SMBs use today - little beepers of enterprise software: spreadsheets, simple accounting programs, and cheap CRMs.

Get Out of the Comfort Zone to Win.


June 20, 2015
I feel bad for being harsh on IT and overly negative about the current unfortunate state of the enterprise software industry. As much, as I'd like to impress the reader with breathtaking inventions or examples of 3am heroics fending off a vicious DDOS attack or otherwise riding in on the white horse to save the day (night in that case), successful software development is rather uneventful and boring. It just works... like your kidneys or liver. No one brags about his/her healthy internal organs. Now, when their efficiency decreases, it becomes a different story.
Software engineering has a lot in common with auto racing. Both are about two things: using 100% of your equipment capabilities and not making mistakes - rather than doing something dramatic to impress the spectators - IT bosses. Racing drama only happens at the back of the grid between rookies. Watching top racers leading the pack through the race is boring. They don't show off. They simply follow the racing line and concentrate on being smooth. They know when to shift, when to brake, and when to get back on the gas. Firmly, but smoothly, precise to the millisecond - lap after lap after lap...
Expert Java developers leverage powerful tools e.g. Spring Framework to the fullest - like Michael Schumacher (with hopes of full recovery after his skiing accident) operates F1 cars at their 100% capacity whether none of us, "spirited commuters" would even complete a practice lap without stalling it.
Unlike Michael Phelps, Kobe Bryant, and other athletes that possess certain genetic advantage over the rest of the population, anyone can technically become a top F1 racer like Schumacher. Operating a car does not require any special strength or agility. Schumacher wasn't born an F1 champion. He became such because others - given a chance - chose not to widen their comfort zone to calmly operate a car at higher speeds - processing the rapid stream of sensory signals: image, sound, and tactile feedback, even smell - yes, without making mistakes.

3rd Generation Data Persistence.


June 12, 2015
Data persistence is the most fundamental concept in business software. The current technology is based on the second, "relational" generation of databases. Storing data "relationally" in indexed tables was a huge leap forward compared to mainframe era flat files. The infamous Y2K crisis exposed the flaws of flat files, as changing just one field from two digits to four (storing the year as four digits) became a painful and expensive process.
Relational or not all databases share one serious flaw. They are disk-based. Even after the last mechanical HDD is replaced by fast flash storage, the "freight" block-based nature of disk I/O remains fundamentally different from frequent fine-grained RAM access - hence the need to pack and unpack small data units into those "blocks" to minimize the number of expensive round-trips to the storage.
30+ years of perfecting data transportation logistics brought us indexing, partitioning, query optimization, batching, caching, and many more amazing improvements. ORMs hide all of that from programmers making the database look “object-oriented”. That illusion however can only go so far.
Despite the most brilliant attempts to automate four fundamental data transfer operations: Create, Retrieve, Update, and Delete (CRUD), tedious CRUD plumbing still comprises 90% of conventional business software code. A much bigger problem is CRUD’s inherently procedural nature, which fundamentally conflicts with Object-Oriented Programming (OOP) used to model complex real-life objects and processes.

Initech Didn't Burn Down. It Survived Two Recessions.


May 5, 2015
Anyone who worked in IT longer than a year would have enough material for ten "Office Space" movies.
We've already had two "recessions" in this century. Recession hiring patterns are fascinating. So you, Bill Lumbergh, hired some expert "unbelievably cheap". What's next? Other than "getting your money worth" through unpaid overtime, nagging "we pay you more than anyone" and other managerial necessities. Why it always comes as surprise, when that person leaves at the first sign of economic recovery? You didn't see it coming? You expected him to politely knock on your door and ask for a raise - after countless "How much we pay you" remarks? What are his chances of getting a raise?
Of course, you feel generous today. Throw him $1K and take him to lunch. He should be happy. And if he refuses your generous offer, you'll start shopping for his replacement at the same exact rate plus $1K. Why'd anyone do it - knowing the recession is over?
If you are "lucky" and the person stays, that's even worse. It may not be immediately obvious, but you shot yourself in the foot by paying your top engineer below the market rate. From that point on you cannot hire anyone at the market rate. You'd have to raise at least one person's salary, and the chances are many more underpaid employees in your company/department would ask for a raise too. Pray, that your engineers won't miss a day at work, because they are all you are going to have.
Third case, if you are hoping to get rid of your worst employees through "attrition" by not adjusting their recession-low salaries for inflation, those will never leave. The strongest ones do. How good is your math? The cheapest completely useless Java programmer still costs above $100K with mandatory benefits and taxes. If you hired such weakling for "simple support" or "just in case" when you had the money, plan on keeping him/her forever. Those are the ones behind the worst examples of "job security" via obscure overcomplicated design and code. You didn't see it coming either, did you? Non-technical managers wouldn't catch it in time anyway. How I know you are non-technical? You are bad at math.

Malignant Glue Code: Layers, Tiers, and "Enterprise Integration".


May 3, 2015
Introduced in 1997 by Microsoft, three-tier DNA architecture was mind-blowing - a big step up from the two-tier "client-server" design pioneered by Oracle Forms in the early 1980s. Everything seemed perfectly logical: the client-side Web browser, the traditional non-Web enabled database, and the new tier - Web Server, which connected both.
Everything checks out in theory. Layering and modularization represent two fundamental OOP principles: encapsulation and separation of concerns. However in real life Object-Oriented, data normalization, and any other purism is nothing, but someone's pet peeve.
People are free to organize tools in the garage or mugs in the kitchen cabinet - by size, color, or any other way he/she feels is important. But plumbers don't "organize" water pipes "hierarchically" with different circuits for kitchen sinks, bathroom sinks, and toilets. They only distinguish between hot and cold water - striving for less piping and joints. Software plumbing needs to be simple and efficient too.
A few years ago I had a chance to compare my approach against the ubiquitous multi-tier architecture. Coincidentally one of my own project tasks was almost identical to one of my "day job" assignments: to implement a screen with seven fields: loaded, updated, and saved into the database. The screens had different purpose: global system settings and password policy enforcement, which is not important implementation-wise. It took me 10 minutes to implement and test my screen - writing just two files: the data entity with seven fields and the UI mapping for them: 15 lines of code total as I recall. The screen for my day job project took 6 hours: to write 5 new files and modify 21 more to the total of 26 files and several hundred lines of code - just for a single data entry screen with seven fields.