Fullstack Programming: A Prelude To Failure

Introduction:

If you are part of this new-old fashionable “appellation” of considering yourself a “fullstack programmer”, or maintain any of the myriad of titles which places you in charge of technology (e.g. CTO, VP R&D, Technology Leader etc.) you owe it to yourselves and your company to take just a few minutes to read this article. I do apologize at the outset if you personally feel this article impugns your capabilities. However, before you fly into a rage, foam at the mouth, go bonkers and dis this whole article based upon the title and your adherence to the “fullstack” mentality — let’s first try to define and understand the actual dilemma surrounding the fullstack programming vision.

I cannot pinpoint when the term “fullstack” became widely used as a description for a programming position. It is like so many other terms out there that fade in and out with time. For instance, the term “DevOps” which has become extremely popular represents in its most basic format the eternal development, staging, production cycle. Applied carefully it is supposed to cut down time from programming to implementation. Recently, you will have noticed the term “CI/CD” as well. When I first saw it, I felt like a fool, said to myself “What the hell does that mean?”, and went to look it up. I literally bust out in laughter when I realized it stood for “Continuous Integration/Continuous Development”. YAT (Yet Another Term) for DevOps (based upon some methodology as Agile or Scrum or Kanban etc. and etc.)! It therefore should come as no surprise to any person in the technology field, that “Fullstack” has taken over in popularity and mention. Suddenly half the programmers I interview or speak with, look me straight in the face in all seriousness and say, “I am a fullstack programmer”.

And I then ask, as I did with CI/CD, “What the hell does that mean?”. The second I hear someone boasting about their fullstack capabilities, the questions come fast and furious (and yes, I admit with a bit of sarcasm as well.)

1. What stack are you referring to? What is the technology stack your company is using or intends to use?

2. You claim to know Angular, Vue, HTML & React? And know all of them perfectly?

3. You can program back-ends with NodeJS, Java/Scala, C++, PHP, Python, Golang? You know all those languages and know them well?

4. You understand JSON and how to really use it when it is deeply nested?

5. You know AWS, Azure etc. and all the components? From EC2 to NAT Gateways to all the 1001+ modules that just AWS offers you?

6. You are an expert in Redis and Memcached and know how to set up and correctly use a Redis system and what to use it for?

7. You know both IOS native and Android native as well as not using native code using React?

8. You know SQL and NoSQL? The differences between them and how to operate them? You understand MySQL, Postgre/Postgres SQL, MongoDB, Hadoop, Cassandra, Apache Spark?

9. And probably most importantly, do you know how to secure all your data, both data-at-rest and data-in-transit?

I just let the questions fly, without waiting for answers. Because one can easily turn those questions above into 25 or more. Anyone who has the temerity to tell me they know all the above and know them well, is either a fool or a charlatan. So, what “fullstack” are we talking about? First and foremost, define your fullstack. I have no clue what you mean by “fullstack”!

For the sake of understanding what a real stack is let us take as an example two of the simpler stacks in the land of lexicons and acronyms, so common in technology. Technologists know of the “LAMP” stack and the newer “MEAN” stack. LAMP stands for “Linux, Apache, MySQL, and PHP”. MEAN stands for “MongoDB, Express, Angular, NodeJS”. The MEAN stack includes a front-end within it — Angular. The LAMP stack does not.

Make no mistake there are probably hundreds of “stacks” out there. All having been created to identify and elucidate the technologies required for a specific project. They define technologies. They were never meant nor ever should be used to define the actual qualifications for one programmer in a specific job. Indeed, the whole contention of this article is that “fullstack” when applied to a programmer is a myth and horrendous mistake if success is your goal.

The Myth

I don’t think anyone can ascribe one specific reason to the advent of “fullstack” programming. I have my theories and suppositions though a mixture of them, which then perpetuated the fullstack myth is probably the best guess. I am fairly sure the idea of fullstack began with all good intentions. To combine one expertise with another in one programmer. It is logical as many excellent programmers do have the ability to handle a couple of technologies in a competent way. Yet as in all things, “fullstack” ran away with itself and has become a catch-all term demanding a huge amount of expertise over a wide range of technologies. It is a myth — though an accepted one these days of how programming should be done.

1. Limited Funds — Realistically, there is a budget. That is a given, be it in a startup or in a large company. Budgets are created to make sure the burn-rate does not create a runaway train and the company can absorb costs. This is economics 101 and those who chose to ignore the amount of money raised or made via sales guarantee disaster. Therefore, it seemed to make a great deal of sense, rather than have a programming team where each individual (or teams) were experts at one or two things, why not have people who are capable of doing it all? “Fullstack” came into its own. After all, many companies demand their CTO be “hands-on” (HO), so that they can do two jobs — one in programming and one in running the other programmers. So why not combine various “expertise” into one position? This does save on money and has the added advantage of running small and tight teams.

2. Backup to Programming Teams — Another salient point, and I give credence to this one, is that if one programmer is sick or leaves, in a true “fullstack” environment another programmer can take over until a replacement is found. After all, if everyone is “fullstack” they should all know what the other knows. There is no need for an expert in one specific area, as it is assumed that everyone is an expert at everything.

3. Ignorance of how much knowledge is required — In a recent, very open conversation with a newly appointed VP of R&D, he asked me what my thoughts were on a team of “fullstack” programmers. I answered with a question. “What is the stack?” He said, it is MongoDB, React, NodeJS stack, including micro-services, lambda and other uses of AWS technologies. I thought for a second, knowing full well that being brutally honest would cost me consideration of the job I was interviewing for. With me, “brutal honesty” always wins. I asked the VP if he understood what he was asking his programmers to know.

a. They had to understand and know NodeJS which despite popular opinion is not simply an extension of JavaScript. It is a language with so many possibilities and middleware and demands deep understanding of synchronous and asynchronous programming. Adding the correct implementation of micro-services into the mix is another level of true understanding on how NodeJS works and what should and more importantly should not be done in the programming structure.

b. MongoDB is a NoSQL data store. What many fail to realize is that it alone contains a language of over 200 possible calls. It also demands an understanding of data in a deep sense as this is not your relational, linear tables. (And even in SQL systems there needs to be a serious data person (DBA)). MongoDB and all NoSQL systems also demand knowledge of schema-less data. (See my article in Medium: “The Drastic Mistake Of Using Mongoose To Handle Your Big Data”.) This is a science in of itself. What about replication and sharding? Index use? Understanding when to use map reduce and all the other points.

c. Then there is AWS. Technologies abound in AWS. Lambda is one of them. It has become incredibly popular yet can turn into a nightmare if not implemented correctly (especially in costs to the company). And what about all the other demands on AWS? The simple AWS stack including the instances, the NAT Gateway, the use of S3, and the myriad of technologies AWS offers. This alone is a huge task and can easily get out of hand.

d. I added some other tidbits in my answer. Redis — when and where to use it? How to use it? How to expertly manipulate it and data.

e. And who will take care of data security? That in and of itself is a full-time job, and one that is so often ignored in the development cycle it is scary. (Without going deeply into this subject here see my article in Medium: “10 Initial Steps Towards Designing A Cyber Secure Technology System”).

f. If that was not enough to show, simply by description the insanity of expecting one programmer to be able to do all the above and do it excellently, I then went on to the front-end. You are telling me that one person will know everything in the above list and also be able to prepare a decent front-end with a normative UI and UX? Even if it was not React, (perhaps the hardest of all), but Angular or Vue, it is still a huge stretch of the imagination. I do not care how much of a “ninja” that programmer is.

It should be clear that any “stack” can be dissected into the most relevant parts. And once the stack is dissected carefully it will become clear what knowledge is required and what is not. To expect one or two “fullstack” programmers to have a complete and total understanding of all these moving parts is to invite disaster into your system.

4. Plain & Simple Hubris — Yes, there are some stacks (e.g. WordPress, Wix, etc.) which can be run by one person. However, any programmer or CTO which claims a fullstack knowledge, and sometimes I have heard the claim made on many programming languages and front-ends and database structures (with a mixture of SQL and NoSQL), is simply hubris at its worst.

The Reality

The reality is simple. In the proverbial cliché, “you cannot have your cake and eat it as well”. There are very few and far-between individuals who can manage a “fullstack” to even a mediocre let alone excellent degree. I am friendly with some of these exceptional people. Trust me here, these individuals are making way more money than your company is willing to pay.

The reality is that you first must define what your stack contains. If we stick to the example above, your NodeJS programmers may be able to also handle the MongoDB setup. But will they understand the needs for security? I cannot count the times I have seen a MongoDB setup, either locally or on Atlas, which was totally insecure and begged for a breech. Will these programmers know that while the data is in transit, they must apply security measures to it? Will they understand the differences between bCrypt and crypto? I could go and on and on but let us assume that all the above can be found in one person. What about the front-end? They are also going to be developing an entire front-end (Mobile and Web), while doing the above and doing it well?

The reality is that successful teams have specific jobs. In all stacks you can divide this into three main functions:

1. Front-End

2. Back-End

3. Databases

The reality is that there is a crossover of expertise. There is the need to define certain parameters especially regarding JSON and what will be sent and what side will do the computations if any are necessary.

The reality is that as your company requires more and more on the programming end, the needs must become more defined as to what you fully expect from that programmer. Putting an advertisement up in which you place a laundry list of languages, technologies and requirements and calling it “Fullstack Programmer Required” does not say a great deal about the company. Indeed, to many it should set off warning bells and red lights as to the exact expertise of the company and how it will succeed.

The reality is that you and your company need to define exactly what is required, what backup to the programmers is required and work within a realistic budget. Hiring a CTO who is HO along with 2 “fullstack” programmers is not going to cut it.

The reality is — face reality and limitations in a sane manner.

The Absurdity

Would you hire a programmer who knows Python to be a Data Scientist? I sure as hell hope the answer to that is “no”. Why? Because data scientists require a skill set of which Python or Java/Scala are just part of the pool. Why then would you think of hiring a Python programmer who knows a bit of NodeJS, to build an entire front-end, back-end and DB system? That is patently absurd.

But..but..but..you tested them! Yes, you did. They passed the Python test, the NodeJS test, a DB test and even some small front-end system. A form here, a question there, a responsive site — of course you found an excellent fullstack programmer. They are so good, that even if you change to Golang or introduce JAVA into the mix they will seamlessly make the transition.

That IOS native programmer? Well if they can do IOS they can do Android, right? Of course! They will be able to handle all the nuances in both systems including the data that will fly back and forth from the back-end. Why not?

And while you are thinking on it, the person who is on that back-end which is growing in leaps and bounds should be able to handle the entire system of data and security. I mean that is only a small extension of what they are doing.

Simple math tells you that two programmers can do the work of five. You can simply protect your budget and look like an incredible hero in the eyes of the company. You discovered the lure of “fullstack”. You also, on the by-and-by discovered the road to absurd expectations and impossible tasks. These days with the incredible IDE’s and tools out there, a programmer should be able to handle everything and anything thrown at them. Right? Wrong! Oh, so wrong.

It is like expecting a CTO to be a CEO, COO and CFO all rolled into one. No one sane out there would suggest doing such a thing. Why would you expect a programmer to do it? When all is said and done, you should never expect a “fullstack” programmer to just know and be an expert at everything. That is ludicrous.

The Prelude to Failure

For all the “Fullstack Programmers” out there:

Before you decide to ream me and this article, scream and ignore this entire article or vote it down, please just read this part. Then do what you want.

It is not you. It is the system which has thrown you into the impossibility of getting a decent job without declaring that you are a “fullstack programmer”. The amount of jobs requiring “fullstack” has grown by leaps and bounds. You need to work. You have no choice but to declare your “fullstack” capabilities and hone up on those weak points in your knowledge.

Yet the expectations made will force you into a no-win situation. You need to be able to be an expert at some things not everything. Being forced to delve into areas where your knowledge is weak, will force you to strengthen that aspect but at a cost of your other knowledge. Technological systems change every 3 months. The amount available to you in any language is almost if not well nigh impossible for one human being to keep up with. Multiply that by a “fullstack” and you will find yourself drowning.

Yet you insist and say to me: “I am a fullstack programmer. I know it all. I can handle it all. Get real. Fullstack is here to stay and move aside.”

So, I will answer with brutal honesty. Fullstack Programming is a scam. You will be a jack of all trades and a master at none. And when your DB fails to answer, or your back-end does not do the correct computations, or your front end does not present the data correctly, or when your system is hacked and breached — guess who is going to be blamed? After all you are a fullstack programmer!

For what it is worth, the companies which succeed are those who recognize the need for expertise in every single part of their stack. The companies which fall fast or run into huge amounts of trouble are those who demand their programmers know everything and can handle everything in the entire stack.

Front end programmers should not be messing with DB structures and information. Back-end programmers should never mess with the front-end. Security must be addressed in our day and age by experts with an understanding of what is going on behind the scenes.

Some technologies can and possibly should be combined into one job. That does not imply in the least sense that you have become a fullstack programmer. It simply means you have extended your expertise allowing you to demand a bigger and better job in the future.

Stay away from the lure of “fullstack”. Stay far away. Know what you do know and admit what you don’t know. Those are my favorite words in the English language. “I don’t know”. Stop trying to scam the system. In the end result it is you, the programmer, who will be blamed.