“Software development is a mysterious trade full of myths and legends,” said nobody ever.
Nevertheless, some misconceptions regarding the software industry persist. No wonder; the software development industry has achieved things unheard of in other trades. Let’s not get ahead of ourselves, though. Many of these customs and beliefs are not that wondrous at all.
Let’s see if we can address some myths and debunk them.
1. IT Projects End With a Happily Ever After
It’s only human to believe that life is made up of stories with a beginning, a middle, and an end. Software projects are no different. People involved have a tendency to believe that their software development project will end one day. That they will cross some sort of finish line, receive a medal, and move on, never looking back again. People who believe this, may as well believe in fairytales.
It may be true in some rare cases, but the vast majority of software development projects will infinitely evolve and change. This is not a bad thing; it’s only natural.
So why do we still persist in wanting to do a job, finish it, and be done with it?
Think about it. Nothing is perfect. There will always be elements to improve or change because it isn’t to your liking or because it doesn’t quite work the way you intended it to, or simply because circumstances changed. Circumstances will always change because the world will always evolve. IT systems that don’t keep up with changing conditions will become faulty, deficient, and eventually obsolete.
Look at an IT project as a garden. Every year you have to plant new vegetation, remove dead or sick plants and bushes, prune trees, add fresh soil, even change the overall design every once in a while because you want to add a sitting area or because you want to let more sunlight in. You don’t have to do all these things. You might as well let things run their natural course. But if you do, you will find in a few years’ time that what was once a neat and cozy garden has turned into an impenetrable jungle.
People tend to think of software as an inanimate object. It actually isn’t. The fact that software is continually being used and altered by people makes it very much alive.
2. The Dreadful Curse of Legacy Code
Everybody dreads it: legacy code holding back new development. This is another myth. In fact, no code is legacy, or all code is legacy. “Legacy” is just a name we decided to give to neglected code that hasn’t been taken care of properly. In that sense, this myth is closely related to the first myth we discussed.
It’s important to keep in mind that so-called legacy code is not a bad thing in itself. Think of it like the pyramids. They are outdated and not of use to us anymore, but they are still beautiful and a testament to their time. They were designed and built according to the knowledge and customs of that age. You can look at them through 21st-century goggles, but you would only be projecting current wisdom on the past. The same goes for software code. It was designed with contemporary knowledge for use at that time. It wasn’t built to last forever. Developers of the past couldn’t have predicted what software demands of these days would be like, just like we can’t develop software for ten years from now.
3. The Technical Debt Phenomenon
While we’re at it, let’s talk about technical debt. Can we all agree that this is a silly name? If you need a name for this phenomenon at all, it should be called “technical neglect” because it is caused by a lack of time or budget, or through plain old laziness. In my opinion, if you can create something, you can also solve it. Therefore, it is not a debt. If you aren’t willing to solve problems now, why should you do so later?
Let me explain.
We all know the final little chores that need to be done after having moved into a new house, right? Hanging that lamp in the shed, fixing the skirting in the spare bedroom, that sort of thing. These issues can be solved immediately or in the future, but they only become problematic when the situation becomes unworkable. For instance, when the lack of light in the shed makes it so you can’t fix a bicycle tire. Would you call this technical debt? Or just negligence? Either way, you can always choose to solve it.
4. The Crystal Ball of Estimation
We all think we can make estimations. We cannot. Time and time again, people try to estimate how long a project will take and fail. Sure, there are methods to mitigate risks. Knowing sooner in the process whether a project is still on track or not is the reason why Agile exists in the first place. The same goes for other methods, by the way.
Software is kind of the opposite of the saying “one picture says more than a thousand words”. In software, one word can introduce a thousand new issues, variations, or complexities. I like to remind people that a simple Boolean is easy in theory, but for software, it translates to exponentially more complex code and more test cases. If you want to prove the correctness of one Boolean, you need two test cases, for two Booleans you need four test cases, and for three Booleans you already need eight test cases. As you can see, testing the correctness of one simple function is growing like the famous rice on the chessboard story.
5. Low-code and/or No-code Is the Hero or the Villain
It never ceases to amaze me how people tend to look at low-code and no-code from a better/worse-than perspective. In my opinion, it’s simply the next abstraction, like assembly was for bits, and high-code was for assembly. It is basically the next step of software development. It meets our current needs of speeding up the process, eliminating unnecessary handwork and making the process less abstract and more visible.
Low-code/no-code has changed the software development process from a mysterious expert’s craft to a democratic process, exactly what is needed in this time of fast and widespread digitalization.
Myths Busted?
I hope that we can all be open to embracing change again and get rid of these silly myths that are just shrouding software development in mystery. However, we should not abandon the reasons why these myths exist in the first place. Like fairy tales, they have a base in reality and there are important lessons to be learned.
Software will forever evolve. If we don’t tend to it, our software will become unmanageable. We have to be its active caretaker because nothing lasts forever, especially software. The world is changing faster every day. Why we won’t let software and software development evolve with it is confusing to me. Especially because software is made for change and flexibility, as opposed to hardware.
It may not feel like it, but we are still in the early stages of software development, evolution-wise. We still need to figure a lot of things out, which I personally consider one of the best parts of being a developer. Embrace the change, embrace the future.
By the way, this was made by me. Not by some bot.
Original posted by Joost Landgraf, CTO, CoolProfs, on LinkedIn