The Software Engineering profession is one of the most misunderstood disciplines. Many folks consider it as engineering; some tell it's like painting—an art, a few think it as a creative journey full of flaws. While engineering and painting may look different, they are similar in software engineering. Both start with empty hands, requires discipline, repetition, and knowing the fundamentals.
However, they differ in their approach to the problem. While painting can point out a problem, it rarely solves it. The engineering looks at an existing issue to find a solution. On the one hand, software engineering tries to achieve both with a single shot. On the other hand, it rarely succeeds because it's neither an established engineering discipline nor an accepted art trend.
If we look at other engineering disciplines such as civil engineering and mechanical engineering, software engineering falls short as a discipline. It doesn't have the defined quality standards and the legislation to enforce any standard. That's why there are a lot of crappy software systems all around us.
When we compare software engineering with painting, both often create new trends. In painting, new trends need time to establish and accepted by people. In software, we reinvent one trend after another without taking the time to establish the existing one. Being in the hype mode prevents bringing out creativity and blocks innovation.
If the software is not engineering and not art, what is it?
What is Software Engineering?
Software engineering is thinking that we can build Sagrada Família, combining the art and the engineering but failing miserably. Sagrada Família is unique because numerous architects worked on it after the initial architect (Gaudi). Each architect faced the challenge of keeping the original design but applying new trends, technologies, and own ideas. These days, each software engineer faces a similar challenge but takes a different path.
Unlike Sagrada Família, every software engineer who adds a piece of code tries to put their ideas and style by ignoring or destroying what the previous engineer has built. We think we are so good that we can quickly build Sagrada Família. But we don't have discipline, we don't know the fundamentals, and we often forget a foundation we should consider first.
A while ago, we talked with a friend, and he said the good software is boring, reminding me of Dan McKinley's post. Software engineering is actually to have a big enough tool belt, knowing each tool well, solving the problem, and using high-quality standards to measure the impact. And, this whole system is boring.
It's boring because the focus is on solving the problem with the boring tools that are established and producing a high-quality result. If we're trying to reinvent the wheel every time, the chances are that we are moving away from the actual problem and/or sacrificing quality. Boring technology keeps our focus on the problem.
Take Spring Framework, for example, it has many features, and it's established. And I think it's boring. Many things come out of the box and have guidelines to do certain things. Whenever we're stuck in any technicality, we can find an answer on Google.
Using Spring in a project is more close to engineering. We don't think about how we should implement dependency injection or caching. It's there and ready to use. We just need to decide how to apply it in our use case.
With using boring technology, the mindset shifts; we move the focus from technology to the domain—the goal changes from using new technology to solving the problem in the best way. The shift accentuates creativity and innovation.
Creativity and Innovation in Software Engineering
There is often confusion between being creative and being innovative. Being innovative encapsulates creativity, but not every creative activity is innovative.
Almost all engineering process is creative. The goal is to bring out what's in our heads. When we're planning, we plan how we work on small pieces to bring out the masterpiece. When we're coding, we start with an empty text editor, a small section of the bigger piece. Every time we code, we become creators, not innovators.
The innovation comes from combining both engineering and art. Building Siri, World Wide Web, multi-use rockets, blockchain, etc., are all innovations. These technologies advance our race. The problem is that we often praise innovation more than boring engineering.
We often ignore the reality of innovation: The innovation rises from knowing the ground rules well enough that we know which ones we can bend or demolish.
Take Tim Berners-Lee, for example. Before implementing the first HTTP, he worked in telecommunication companies, did many projects in computer networking for years. He learned the fundamentals well enough that later he was able to connect TCP and DNS to set the foundation of the World Wide Web (WWW).
On a lower scale than WWW, let's take Uber (or any other big tech company) as an example. They have built their own mobile architecture (RIBs) after they learned the ground rules and used the boring ones. Until it didn't fulfill their need, they used what was there. They learned the technology, needs, and business so well that they knew what they had to do to invent a new framework.
The major problem of becoming an innovator, artist, and engineer, we have to do the boring work first. Without having the fundamentals in place and knowing the ground rules, innovation cannot emerge.
I'm not saying that we have to learn how to use punch cards or write code in FORTRAN. We should choose our own boring technology that is established and won't require us to reinvent a new way to solve the same problems.
Many people always pick the latest technology, and many companies promote them. If we keep focusing on learning the latest technology before the boring ones, we can be neither an engineer nor an artist; I'm not even counting on being an innovator.
To get better at software engineering, we should pick a part in it and do it over and over again. Once we learned and mastered one side, we can look for new ones around it. If we don't learn one thing well enough, our foundation will be weak, it will crack, or we will spend enormous time solving the problems that were solved years ago.