Why developers are scarce?

Because they’re busy doing stupid things instead of developing stuff.

If we take a look at how you’re supposed to develop stuff today, you’ll find that the entire process is built to fail. Too many specifications and standards to choose from that you must conform to.

Don’t believe me? Let’s pick an example, something simple, let’s say: “How to version your software”. Any human being with common sense would think: Easy! Your first version is 1, when you update it is 2, and so on; basically a no-brainer and not that important. Well, that’s not the case in the development world. First, you must learn how to version your software properly, and for that: Google throws 3 billion results to that query… but hey, who goes beyond page one of google? Let’s pick the first 2 or 3. Wikipedia? An entire page with 48 references on software versioning. Let's pick a standard! (funny we have different standards to choose from) semantic versioning v1…. semantic versioning v2... So, if you learnt about semantic versioning v1, then you’re doing it wrong and you must learn it again.

Developers will say proudly: we organized several long meetings trying to define the best scheme for our versioning. While whomever pays their wages will see how production capacity reaches zero.

Now, replicate this to every step on software development. Let me share another example: It is good practice today to have every line of code tested by an automatic program. Neat!, you’ll think. Truth is: automatic program testing that line of code requires the same developer to type several lines of code, and instructed to not apply common sense in the process.

As an example: If I code: var a = 1

Specifications (written by the most experienced developer in your company, the CTO with the help of the lead dev) say “unit testing should be above 95%, you must test that a equals to 1”

That means… I need to write a few lines of code that test that the value of a is actually 1. Converting a 5 seconds task to a task of at least 15 minutes. Double that if you’re doing peer programming (which is two developers doing the work of one, another good idea in the development world…). Multiply that result by 4 if your company is also doing code-review, which is: at least two other developers checking your code before going into production. And by 8 now, as it is understood that no code review is good if it wasn’t bounced at least once.

So, the code reviewers will inevitably come up with something like ~taking from real experiences~ “ok, you test it equals to 1, but are you checking if it equals 2?”, then you can start explaining basic logic and start arguing… asynchronously… and forget your little piece of code reach production sometime soon or just invest another 10 minutes writing a test that a isn’t 2 just for the sake of it.

 Funny part is: While we use fancy terms as continuous integration, we somehow manage to convert 5 seconds tasks to at least 1 hour, and involve 4 developers in the process of writing 1 line of code. Meanwhile, we usually have a QA team which only purpose is to test that when we say "a equals to 1" effectively a should be equal to 1.

So, how do we solve the problem of lack of developers? That’s easy: Stop thinking that the developer with the most experience is the one who should be calling all the shots. Involve one person with common sense in the decision making process AND DON’T BE AFRAID OF DEVELOPERS QUITTING! As those who argue against new methods and dig their hills into the old ways, just because “this is the way it has always been” or “this is how everyone else does it”, are probably the reason why your development will fail.