What I Wanted to Know About Software Engineering Twenty Years Before
What I wish to tell my younger self about software engineering if I have a chance.
It’s been 20 years since I started working professionally as a software developer. Twenty work years means incredibly a lot of time spent with the source code, invested energy, and opportunities to gain skill by creating the software “in the trenches.” Sometimes when I look back to the past, I imagine a meeting between my younger self and me — what my two decades older version tells about my profession? I will pat my younger myself on the shoulder and tell: hey boy, software engineering is about three things — technology, processes, and the people. They are like three elements of the universe with its own rules. You can follow the rules or ignore them and then most likely fail. When you have enough experience and think about them more deeply, you will identify these recurring patterns between critical decisions and software creation outcomes. Let’s look at them in detail.
Technology
Technologies expire, some sooner, some later. It doesn’t matter if it is an application, library, programming language, or any new shiny “the thing” described by well-known buzzwords. Choosing the right technology for the project is not a simple task and considers many non-technical aspects. Will we find enough developers willing to work with it? How fast will we master it to be productive? Have the invested effort economic sense for the company? How quickly will the new developers be able to get in? And so on.
It’s all even more challenging to consider these aspects’ time dimension because the maintenance period of serious projects usually takes years or decades. Therefore, choosing the right technology is like playing roulette. You can miss miserably, and you will notice it only when it is too late.
One of my former colleagues working in the TELCO domain tells me the following story. “One day, two CEOs of the two big TELCO companies meet together. During lunch, one of them tells the other: Hey, do you know, we are now using the Java platform, and it’s amazing. The next day second CEO rams into his IT department hits the table, and shouts: Let’s re-do everything in Java!” Besides, I like Java a lot; I find this story very ridiculous. For me, it looks like a navigation of the most modern aircraft carrier by hand compass, but it happens very often. People with no or minimal technical background make decisions, which should be made by the most battle-tested programmers and technology leaders. So, rule number 1. is: Leave the technical choices to the most experienced technical experts. It has to be programmers who work and fight hard with technology stacks, not software consultants with no practice, managers, or even salespeople. Results can be overwhelming — exponentially better quality of the final product and exponentially lower development and maintenance costs.
Processes
Processes help your software to grow. You can do it without them, but your project will never grow up to a bigger scale. On the other side, you can overdose your project with processes making it an ill, fat bully terrorizing your team. Therefore, choosing the right dose is like a prescription for the real patient — very subjective per every case. Honestly, I have met some talented developers, who usually get up close to lunchtime and work hard in the late evening. But I have also met managers obsessed with the Scrum approach to software engineering, who persists in every day early morning meetups of the whole team. Probably they also similarly manage their personal life. Nevertheless, combine this manager and developer, and you will see it from the first day — it will never work.
So rule number 2. is: Always adapt processes to people and the situation, don’t try to do in reverse — it will not work optimally. During the last fifty years, smart people have armed our toolbox with many genuine and useful software development paradigms, methodologies, and practices such as Iterative Model, Agile, Kanban, Scrum, DevOps, Continuous Integration / Delivery, Test Driven Development, Pair Programming, etc. Don’t be close-minded to use only one approach. Combine parts of them, but mix up the cocktail wisely to satisfy everyone around — users, coworkers, stakeholders, company owners, and of course you. Usually, using common sense is far better than the authoritative following of one practice. Every method was invented in different circumstances than yours. Every project is unique in the universe. Therefore, a unique combination of techniques for your project is a valid and viable option. For example, intuitively, you will take a different approach in development workflow with a bunch of junior developers than with experienced senior developers.
People
Will ten rookie laborers dig a canal faster and cheaper than 5 experienced one? This type of question concerns the people for probably several thousand years. We tackle them in everyday life, often without realizing it. Will I buy a cheaper or more expensive service? The response is not always apparent; therefore, some people have a lifetime job to answer these questions. Project managers face this dilemma in everyday work, knowing it very well to maximize profit. But looking for the fastest route to the project finish with the lowest cost often tends to think about software creation like a manufacturing process. Using an analogy with cooking, it looks like this:
- get the new pot for the project,
- think a little bit about needed ingredients and create the cooking plan
- throw the elements — these unshaved, stinking programmer nerds — into the pot in the correct order
- stir and mash them continuously enough time
- voila — new software product is cooked
- if you are not satisfied, throw them back to the pot and repeat the process
If “the ingredients” — the programmers have luck, they will survive this process unharmed. If the managers are lucky, they choose the right people and finish the project successfully. More than often, I experienced in software projects that the quantity replaces the quality. So the critical question to answer is — How many junior developers is worth one highly experienced programming expert?
Response from the people thinking about software creation as the manufacturing process will be a finite number. Reaction from all the others will be an infinite number. To understand it, let’s look more deeply into what programmers do. Programmers write code for the computers, right? No. Programmers write code for computers and other programmers. Without the possibility of working in a team and understanding each other’s code, no significant project will succeed or even continue.
When you read a lot of code during the years, you will realize that your colleagues’ readable and understandable code has a more significant value than its cryptic version — perfectly optimized for the processor. In other words, a computer with exponentially increasing power is more capable of sanitizing your imperfect code than human counterparts can understand it’s over-complicated and deceitful version. The code is written once but read hundreds of times. Therefore, real expert programmers write it like storytellers — it will be readily interpretable by everyone, sometimes even non-programmers. The value of “the source code” grows up with everyday usage of the product. The ability to understand and modify code easily goes together with the elimination of bugs and preserving robustness. This model is economically more sustainable in the long run than the “rocket science” code, which no one dares to touch.
Returning to our question, let’s think a little bit about how Michelangelo painted the Sistine Chapel ceiling in Rome. He undoubtedly used state of the art technologies of its time — finest workshop methods and the best available innovations. Michelangelo uniquely set up the painting procedure to support his work utilizing a specially invented scaffold — used only for this case. He chose the right technology and set up the processes, and finally, the man with the vision and the expertise create the masterpiece. Now imagine that the work had not been assigned to him, but the two hundred inexperienced apprentices.
Virtually unlimited resources for the project don’t automatically make it successful without key people making correct vital decisions. Without them, you can still fail miserably. Therefore, rule number 3 is: The most experienced developers are the key to success, never trade them for anything.
Thank you for reading.
