Information Technology Evolutionary Engineering

IT or information technology has been around for decades now. When Alan Turing first invented “computer” to decode the Enigma machine during the world war, the world did not know the terms Software Engineers, Data Scientists, or Network Engineers, yet. What the world knew was Mathematicians, Physicists, or maybe Civil Engineers and Architects. These professions have been around for ages, long before the internet was born, even probably longer before the electricity was invented by inventors such as Thomas Alva Edison, Tesla, Volta, and many more.

When the world started to recognize the importance of information, and started to work with information digitally, new professions were invented. New technology fields were founded, new ideas were constructed. New workflows were made, and the world started to move into a new era, called the Information Age.

IT engineering is very new. It’s broad, deep, and is unclear and unknown to everybody. The need to create a new field of engineering that deals specifically with information so that information can move freely as data and be accessible to everybody was the most powerful force that drove the world to grab the shovels and open up a whole big field of engineering where information grow. It is built on top of the basic principles of engineering, much like other engineering fields that have already existed throughout the ages. What makes this field different with other engineering fields is that it deals with the intangible nature of information, not the visible and heavy nature of construction materials or complex array of water pipes.

I said it’s really new. Probably like a newborn child. We know for good that children imitate their parents. And much like many children out there, we as IT engineers also imitate our fellow engineers. We borrow their terms to define who we are. We have architects, designers, construction workers, testers, and many more. IT projects are managed almost the same way as many other projects are managed and organised. Unfortunately, the field of information technology grows rapidly. Many principles or technologies hold true only for a few decades. This condition forces us to be the “evolutionary engineers”, that keep on learning and moving forward chasing new technologies and principles day by day. The field of civil engineering or oil and gas engineering for example, also grows. But our fellow engineers hold their principles for thousands of years while we only have this new technology called “computer” for just around 70 years.

That one thing called “computer” shaped the world. Another thing called “internet” also shaped the world. Nobody expects that this would happen. Internet or even computers were just another invention that drove businessmen and investors crazy. But then they became open technologies, free for everybody, and therefore, free for the world to use. The world is different ever since. In just a few decades the world delved into the new era and thus the IT engineering was born.

Nobody expects that it will grow so fast. It grows but it is not yet an adult. We are still young, and nobody would in their rightful mind compare our age with our fellow engineers and doctors. And because we are new how can we say that we are better than others? Or more simply, how can we say that we are good enough to be like the others? How can we even decide what is good or bad?

To be a good doctor, no I mean, to be a doctor, in Indonesia you have to study for 7 years. In England, to be an architect, you have to study for 7 years too, and all those studies are based on a solid foundation of knowledge established hundreds of years ago. As a doctor, you can get sued if you do not follow the right procedure, which means that if you do the wrong thing, you are held down by your responsibility as a doctor. As an architect, you can get sued if you give incorrect advice to civil engineers and clients. All of your actions are compared to knowledge and wisdom that have been around for a very long time. And so people are forced to be good based on a well-defined wisdom.

But as IT engineers, we try to look back and see if there is already a wisdom well-defined for us to define ourselves good or bad when doing things. We can’t find anything, and so we try to see what others do. Most people just try to make their clients happy, make “good” (which means acceptable to clients) information systems and software. The happiness of the clients is the underlying wisdom of their workflow. But if we put away our clients from this context, then what is good software? What is good system? What kind of information is good or bad? And does making the clients happy with our software products makes us good software engineers? It all depends on what we see and the issues that we need to address. And so we stuck on creating our own standards of good or bad.

One question that I like to ask to my friends, “Are we closer to doctors or civil engineers?” Most of them said we are closer to civil engineers than doctors because what we do is constructing a system for clients, and it resembles what the civil engineers do when they are building a bridge. Some of them said we are closer to doctors than civil engineers because we try to solve problems in a time-bound environment and most of the problems are unknown to us before and we have to risk something or learn more to solve them. Actually, both are true.

We are close to civil engineers when people see us as “construction workers”. We build a system from scratch, then the system is used to process information the way the clients like. But our fellow civil engineers follow strict and well-defined standard operating procedures to build a bridge. It was calculated in detail beforehand that the bridge must be a few meters long and a few meters wide. Slight mistakes can be tested and addressed quickly as they have already known what is wrong most of the time. Incorrect procedures will definitely lead to failure. Incorrect designs also lead to project failing or not finished in time.

But as IT engineers, we deal with codes, digital bits, maybe some electricity components, and most importantly, information and data. Information are intangible. We cannot see it and so it is hard to measure what kind of information that we need. Because information cannot be defined in metric units, we do not know how far we have made our mistakes. Standards are made to define what quality specifications of an information technology project must meet before it can be called successful, but it all depends on who runs the project nonetheless.

What about doctors? Why are we close to their profession? When we start realizing that technology moves and grows rapidly, we start to think ourselves like a doctor. In this world, new types of medication are invented every year to fight new types of virus and bacteria. But new medications cannot be used forever. Virus strains and bacteria become immune to what the doctors have found a year ago. Problems like the Ebola virus outbreak in Africa inevitably occurs. We couldn’t do anything about the outbreak before we put the effort to do a research about it. Then one day, someone invented the Ebola vaccine. It put an end to the outbreak, but can the doctors and scientists now rest? No they can’t. Because they know that stronger virus can exist.

So are we IT doctors? What makes us look like ones? Realizing that problems always exist make humans aware and cautious. One way we as IT engineers can be aware of all upcoming problems is to wait for them to happen and tear our data centers apart. Let the unknown unknowns known, and do things as we see fit to fix them.

Another way is to be what I like to call an “Evolutionary Engineer”.

What I mean as evolutionary engineers are people that do not stop learning to see new things in the future. You can also say “Visionary Engineers”, or “Creative Engineers”, maybe “Innovative Engineers”. They are all the same. Trying to make something out of nothing is what creativity does. We keep on learning and be creative about all the unknown unknowns, trying really hard to envision the future. A thing that makes us different with doctors, is that we create our future and we study them. Doctors are of course, trying hard to study many virus and bacteria just to keep them at bay. If no virus or bacteria can ever be stronger than what we have today, they can probably rest (well, probably, because some scientists will definitely try to research more to make better medications anyway). But we create technologies so that we can use them. Almost every issue in our IT world is caused by human errors or the demands to improve something for our general humane lives. We keep on creating things based on our creativity and it drives the IT engineering field forward. We do not try to push technologies to stop growing and be still, but we make it grows even faster. And so, if we stop learning and be creative, problems will inevitably occur and we will be miserably left behind with nothing.

Just like the Darwin evolution theory, one of its primary aspect, is the natural selection. There will always be things that we leave behind and things that we create and use as brand new solutions to brand new problems. Things that we leave behind are not, probably, applicable or usable again in the era we live in. When I first came in contact with the PHP language, and got a considerably good grip on it, I thought that I would use it for a very long time. The language had already matured since more than 5 years ago. It was what many people would think as “silver bullet” to the World Wide Web. But then as time went on, problems started to pop out of the shadow, and as SLA became stricter just to meet faster response time requirements, less downtime, and probably cheaper deployment costs, PHP couldn’t keep up. So new languages and workflows were invented to address tight requirements and quality measures. And as of the time of writing, Go and Javascript are conquering the World Wide Web.

Stop searching for silver bullets. You are not going to find any. Nothing will last forever, nor will you find any technology that can be the answer to everything. And if you think PHP is your silver bullet, well, I would say that PHP would still be around for a really long time. Some of my projects were written in PHP because of its simplicity. PHP is a good solution when dealing with simple websites that work only for promotional purposes. But in some other projects where the client requires that the system has complex features, or meet certain performance requirements, I would pick Go. The team agreed to use it and so we designed many systems using microservice architecture and wrote most of the services in Go. Why don’t we just use PHP? The answer is one: we want the system to perform as best as it could to meet the requirements, one of which is performance.

But yes, you can use PHP when you are dealing with complex inventory system that has to have almost zero downtime, data replications for integrity and safety, and very low latency. But you would probably end up buying a lot of servers just to serve a lot of Apache or Nginx instances. One of our project had a very strict requirement about cost. And with PHP, it is not just inconvenient to be implemented but also unacceptable. We cannot have that many servers to meet those requirements. PHP can probably meet the requirements but Go + microservice architecture + Docker and Kubernetes are better at doing it.

I met a lot of people who asked me questions about how I ran my projects. I just told them what I did. Some people said that my workflow is wrong. Some people said that it’s right. But just like what I said earlier, we do not know what is good or bad. And I am no one to decide whether the system is good enough or not. One thing for sure is the one who decides what is good or bad is the client. But what if all solutions can satisfy the client? Is it good to drop Go compiled binaries on top of bare metal environment and run them as is? Do I probably have to use Docker to have good microservice based system? Why not LXD? What about OpenStack or Kubernetes? Those two can provision our hardware automatically and make our services more manageable right? But do our clients care about this? Not they do not. So who decides what is good or bad? The team.

If all solutions and technologies can satisfy the client, then ask yourself, which solution is the best to satisfy the team. Most of the time you are going to need a team to run your projects. You are going to probably need analysts, maybe a lot of programmers, a product manager, testers, and many more. To be able to satisfy the project requirements, you need this one obvious aspect: teamwork. Unfortunately, I tend to meet a lot of people around me that is hard to work in a team. It is okay to work alone but most of the time you won’t get far. Because you are going to inevitably need helping hands to deal with complex problem if you want to reach for more in this IT world, probably in life too. As engineers we are used to do analysis, or breaking things into smaller, more manageable pieces. Each team member can then take a few pieces and deal with them separately. This is how things work in a team. Breaking a single problem into smaller pieces is not that beneficial if you are going to work alone, it is going to make things easier to be managed still, however.

If you are already working in a team, then it’s good for you. And if you have already been a part of it for a really long time, then I would have to admit that you are part of a good team, a family perhaps. A good team would also have to be evolutionary too. A solid team has a workflow that is agreed upon, probably some conventions or standards. These agreements would have to be renewed again some day. Not just the code, the workflow of the team would have to be updated if things do not fit anymore. It does not have to be updated so often, and you don’t have to change the workflow of the team as a whole, only some parts of it, and they need to be updated only if things go wrong. Because changing the workflow or the principles of the team can be problematic at times. The key here is to learn from mistakes and explore improvement opportunities, and see if there are some lessons to be learned. The team itself should not stop being evolutionary and creative.

Occasionally take a good time and let the team try something new. This is what I see in a lot of successful organisations. They do not stop on what they have already had but keep on exploring new problems and solutions, and of course, they do it as a team. You can see that Kubernetes was created based on years of experience in Google. The team members collect their experiences and together they shape the world of cloud computing. You can also see that many projects are ran with the Agile method and not the Waterfall method nowadays. The Agile method is relatively new compared to Waterfall and with today’s generation, the Waterfall method does not fit that much. Originally, Agile was designed to be used with a small to medium-sized group of programmers. But due to some innovative Mr. Know-it-all working in a know-it-all team succeeded to implement Agile in a group of more than 100 programmers, a lot of organisations moved from Waterfall to Agile just to have themselves a good fit in the new era. Some teams succeeded in the transition, some did not. Maybe a few years from now, the Agile method does not fit but who knows, creativity comes with a risk and everybody knows it. It all depends on the team and how far the team wants to evolve. But nevertheless, even for the team to work, it will have to grow and move forward in this era of the digital world.

I’m not saying that you must be like what I said before, an evolutionary engineer. I’m not saying that your team must change every year to adopt new technology stacks. Like I said before, we are new compared to other fields of engineering and so we do not currently understand how far do we have to be good at this subject. So I’m not someone who decides that your way of thinking is right or wrong. Most of the time people will just say “as long as it works”, so if your way of thinking works, then it is right for you.

Creativity is what many people need in the field of evolutionary engineering. Because not everything is well-defined or structured, we could be stuck at creating our own solutions sometimes. Instead of using existing well-defined solutions, we can also try to create new and better solutions. This is what makes it evolutionary. All it takes to be creative, visionary, or evolutionary is just a willingness to learn and try out things without having to worry too much about mistakes, bad critics, or peer pressures. People make mistakes and creativity does not make you make less mistakes. But you will surely go to different places with different kind of success.

If you didn’t, then try to start again. You were taken here because you clicked a link or read an overview of my post online and you found that my post was interesting. I said, it is not for everybody, you don’t have to agree with all of my points. Feel free to enjoy more in the life of IT engineering if you feel like you have already got all of my points even before you read all of the paragraphs. But if you do agree with all of my points, then I am certainly grateful for that.

Related posts:

As part of our New Year’s celebration, for a limited time we are offering free SHE tokens via an AIRDROP reward to all of our supporters that vote for SHE on HADAX (a sub-brand of Huobi) 1.Visit…

A recent survey discovered that fewer than half of employees have “a great deal of trust” in their boss, team, or their employer.

The above video from the Greater Good Science Center at UC Berkeley is raising a very important issue. Kids need to feel loved. They do their best when their emotional account is full. They need to…