Hardcore Software
14 May 2025
The Most Difficult Part of Software Development
You can ask a hundred software developers what the hardest part of software development is and you are likely to get 20+ unique answers. A novice might say the hardest part must be the coding part, it is very challenging to write software after all. For recent graduates, landing a job may be the hardest part. However, something that has been stressed over and over again in my software engineering class and what I’ve personally experienced is that managing a team to ensure an efficient workflow is without a doubt the hardest part of software development.
Anyone Can Write Code
Writing code is so easy, even a robot can do it. Yes, we’ve reached a time in history where self-replicating code isn’t some secret government technology or something hidden within a highly secured lab. And no, I’m not talking about Quines, AI can now replicate itself and pretty much everything from basic to intermediate code. What stops AI from gaining consciousness and going terminator on us mortals? Well, besides needing energy that we humans produce, a complete conquest of humanity requires management and directives that can beat our hundreds of years of experience in war. There are two things fundamental to humans that AI sucks at: innovation and management. Management seems to be something that we still uphold and improve consistently, whereas innovation has somewhat lagged in recent times.
Management Beats Power
Something I found really interesting that was brought up is the mythical man-month. Conventional logic would have you believe that more manpower equals more efficiency. While this is true for repetitive, mindless work such as tasks you’d find in factories, software development itself is nothing like an assembly line. While parts of software development may seem to be repetitive, you’re always creating something new with minor tweaks. This makes it so that writing software using templates is more akin to an artist using the same canvas and brushes for two different art works, than a factory worker slapping a big hunk of metal on a chassis. But why does having more manpower actually lead to less things getting done? Well, we can refer to the old parable of the six blind men and the elephant. There are six blind men that are each touching a part of an elephant. One of them holds the trunk of the elephant and claims that it is a snake; another man touches its ears and says it’s actually a fan; another man touches its tusks and claims that it is a spear; another pushes on its side and says that it is a wall; another grasps one of its mighty legs and claims that it is a tree, while another man tugs on its tail claiming that it is a rope. They cannot agree on what exactly the subject is, thereby making the entire process of identification more inefficient with more people. Likewise, in software development, without someone to manage and direct the outputs of 6 or more different people each with their unique methods, you’d end up with a rope-snake-fan-wall-tree-spear hybrid, but never a complete elephant. Without management, each worker could build the greatest components ever, but they would never have enough cohesion to be as good as a coordinated project. So, is autonomy the answer? Definitely not, even if I’d tried, I don’t think that I would’ve been able to finish our final project even with the help of 20 different AI chat bots plus copilot. To maximize efficiency and quality, a sweet spot must be struck.
It All Boils Down to DevOps
Something that I wish we’d have discussed more in my software engineering class is the DevOps framework. Beyond the development of software, there are operations, marketing, research, etc… that are all equally as important as having a working piece of software. We are so hyperfocused on the development part that we forget about the other 80% of actually creating successful software projects. DevOps, as its name suggests is a combination of two words: development and operations. The operations aspect of software involves everything from deployment to feedback. I remember a funny experience I had as my group was trying to fix an error that we had on the deployed vercel site of our final project. I had to send multiple messages to one of our team members requesting for access to the site. I was honestly a bit frustrated because I didn’t get access until the day after in class during which I was able to see the problem. It was funny because when I actually got to troubleshooting the error, it only took me around 10 minutes, whereas getting access to the project’s deployment almost took me a day. Besides being a fault in communication, this goes on to highlight our failure in bridging development and operations in order to ensure a more efficient workflow. Had I been granted access to the deployment in a more timely manner, I would’ve been able to fix the error in around 20 minutes, and would’ve had 9 more hours to add more functionality to the site. Now, imagine this for larger groups: what if only one person was in charge of the operations and everyone’s work is suddenly bottle-necked and stopped because of an unreliable node? Hours upon hours of potential work would be wasted which would also cost a lot of money to go to waste.
Beyond Software
A lot of classes in college may seem completely unrelated to one’s major. I’ve seen business majors take classes on cybersecurity and/or AI (may god have mercy on their souls) or computer science majors taking something very niche like Chamorro dance or Filipino tribal music. While these are obviously extremities, I’ve also heard some people in computer science complain about having to take security and trust, algorithms, linear algebra, or even software engineering. I believe that taking these classes at face value without attempting to read between the lines would end up being a waste of time. People trying to get into game development might not need security and trust as much as students getting into cybersecurity; whereas those students may not need linear algebra as much as the game development students. But, as a student who is trying to get into cybersecurity, I’ve learned to appreciate these classes and apply them as much as possible to my expertise. For example, had I not taken software engineering, I would find it very hard to reverse engineer sites or find vulnerabilities for cross site scripting, SQL injections, remote code execution via log4j, etc… Classes that seem to be unrelated to my career path end up giving me new perspectives and challenge me to apply my interests beyond what I already know. Besides development, I now know what possible hierarchies there are to large organizations which would be largely beneficial for reconnaissance and social engineering, two highly fundamental things in cybersecurity. My experience in software engineering has taught me things beyond software that I could apply to life and my career.