Thursday, October 22, 2015

Pretend that after you check in your code (even though it is isolated in your project branch) that I will take your code and put it in production right away.

Then ask yourself if that code will break existing behaviour of your existing sites/applications. If the answer is "Yes", then you should not have checked in that code in the form it was in.

Addressing all the issues as you are coding instead of dealing with them during merging your branch back into main trunk is the right thing to do.

Basically the question is: Pay me now or pay me later?

I'd rather pay with the right mindset before you even write a line code. Obviously the mindset is not good enough; you need unit-testing and integration testing to make sure it truly does not break existing functionality . Some of us have been calling this "stubbing out your code" and more recent buzz word would be "feature toggle".

What are some typical examples?

Let's take the most simple example. You are writing a brand new method that nobody is going to use yet and you want to check in your code because it is in good shape. Basically this code is stubbed out by default; you can't break any existing functionality.

Let's consider another example. Let's say you are asked to introduce a new feature called "RankCustomer" on ONLY one of your sites called Site A. You implemented all the functionality and you also prepared the code that invokes this RankCustomer module in your order processing methods that are shared by multiple sites. Let's say you check in the code in this shape. What would happen? If I pushed this code to Production environment, all the sites would attempt to call RankCustomer module and it would break right away and cause a Severity 1 issue. Let's say RankCustomer module needed some certificates/keys installed and if I push the code without the certificates/key installed, it would break production. So how would you check in this code properly? You would introduce a flag in your code for this feature. If this flag is NULL (not existent in config file) or explicitly set to FALSE, the RankCustomer module would never be called. This means that if you literally take that compiled code to production WITHOUT even pushing any config files or installing any certificates, it will never be invoked in production. That's how stubbing out works.

This mindset is something that needs to be preached during any project; that's how issues are prevented and over time this just becomes natural when you work with your teammates longer. You just take care of each other.

Sunday, October 4, 2015

You may ask what the drivers of traditional manual-transmission cars and C/C++ programmers have anything to do with each other.

Well, I am a software engineer and I am also a car enthusiast (aka a petrolhead in UK). I am noticing certain trends in both the car industry and the software engineering community/industry; therefore, I wanted to share my opinions.

I started programming in Basic before I even owned my own computer. I remember when I first learned a for-loop in Basic, I walked over to my friend’s house and typed it up on his Commodore 64. When I was in high-school, I did more Basic (Better Basic and QuickBASIC) and also some Turing (not Turing Machine….I am talking about a language invented by University of Toronto to teach programming and it was Pascal-like). Then I switched to C/C++ and learned all about proper handling of memory and what we call “unmanaged” code these days. C/C++ were the choice if you wanted to do some low-level programming or also if you wanted to write scalable applications. Then some other programming languages started becoming more popular and these were the languages that promised developers the capability of scalable programs without worrying about the complexity that you had to deal with while programming C/C++. Java is one of those languages. Then Python, Ruby and C# (.NET) also joined Java in this group. We also have Node.js, Golang and Scala as more recent players that have proven “simplicity” and scalability.

You may say: “I like to code in C/C++ because it gives me a special satisfaction”, but as a software engineer, you have to be true to yourself and you really need to ask what the right tool is for that given job. C/C++ are the right choice if you are building something where performance is absolutely crucial or you are building some drivers where you really need C/C++. However, if you are building a simple website that is collecting customer’s input and saving it to database, then you really do not want to use C/C++. In these situations, developers are choosing C#, Java, Ruby, Node.js, and Python because they are relatively fast and much easier to maintain and expand.

What I am trying to say is that fewer and fewer programmers are using C/C++ and it will be harder to find developers in this area from year to year. C/C++ will not go away, but no high-school students would be exposed to it. Maybe even no university students would be exposed to it.

I will switch over to cars and explain how driving traditional manual-transmission cars is related to C/C++ programming.

Until automatic transmissions were invented, manual transmission was the only choice. People who liked to drive learned to drive and they enjoyed driving manual-transmission cars. A lot of people opted out of driving because it was just complex for them. Then manufacturers started putting automatic transmissions in their cars. Customers started buying cars with automatic transmission because they were more convenient (easier to drive), but these automatic transmissions were not yet efficient enough from performance nor economical point of view.

In last 10 years automatic transmissions (traditional automatics and dual-clutch automatics) started being engineered to equal and exceed the performance and economical levels of manual transmissions. Nowadays, you can buy cars with automatic transmission that will give you better MPGs and better 0–60 times than the exact cars with manual transmission. In fact, a lot of cars are stopped being manufactured with manual transmission because there is no market for them. One of these cars in the latest 991 model of Porsche 911 GT3; Porsche is only selling the model with dual-clutch automatic transmission also known as PDK; some people refer to these transmissions as “automated manuals”. This is frustrating Porsche car enthusiasts and specifically those purists. However, I understand why Porsche is doing this; they believe that manual transmission is the weakest link in the design of this car and to take this car to next level, they decided to design and manufacture 911 GT3 with dual-clutch transmission only.

As a car enthusiast I like to drive cars and with manual transmissions because there is a X-factor about them that make my driving experience more enjoyable, but at the same time I fully recognize that automatics can perform better and that needs to be well recognized; that’s why a lot of racing leagues use cars with dual-clutch sequential transmissions.

Cars with manual transmissions will not be fully extinct, but over next 10–20 years, they will be harder to find the same it will be harder to find skilled C/C++ programmers.

Disclaimer:

This is a personal blog. The opinions expressed here represent my own and not those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated. In addition, my thoughts and opinions change from time to time I consider this a necessary consequence of having an open mind. This blog disclaimer is subject to change at anytime without notifications.

Disclaimer: This is a personal blog. The opinions expressed here represent my own and not those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated. In addition, my thoughts and opinions change from time to time I consider this a necessary consequence of having an open mind. This blog disclaimer is subject to change at anytime without notifications.