The 5 Stages to Software Darwinism – And how to cure your OCD!

You might be a software developer, who like many others in that profession, has got an OCD! The kind of OCD that makes you want to redesign and make clean classes and homogeneous interfaces. You learned a lot about software engineering and design patterns in school (or from the internet?). It formed an ideal perfect image for how software architecture should be like. The role model that got stuck in your mind that drives your dream of refactoring one day! So first, …

You come into the world with innocent views. You think that in the “professional world” developers respect design patterns and make clean, reusable, and modular software. And that there’s a common theme and coding style that everyone is following. It might even seem so when you’re new to a project. But once you go deeper, you notice a lot of inconsistencies and what looks like violations to what you learned in the design patterns class. Sometimes modules are not modular. They might exceed their roles and scopes. You notice some redundancies that could have been put in a separate module. You think something is wrong and you wanna use your school design patterns skills to fix it. So …

You live on the hope of refactoring one day. There’s probably something wrong and you have got tons of ideas to make the software more modular and scalable. More reusable and portable. You assume that things look the way they look because whoever wrote it didn’t have the time to do it right. Or because there was already a software written in the past but we can’t get rid of it now because it’s stable. And you’d assume that the developers who wrote it were cavemen who didn’t know how to write a neat code and only cared about making it work! You start getting frustrated and assume that’s how things are in your project or in your firm because they are not good enough. Maybe that’s just a local problem. So …

You think the grass is greener on the other side. You start thinking that in other tech companies, there are “real architects”. You think people there are encouraged to invest time in cleaning up things and making a nice software design that satisfies your OCD! Maybe you’ll find your dream job there! Perhaps you’ll live on the hope of joining one of these and finally get to use your skills. But once you get exposed to enough projects or jobs, you start realizing that it’s the same everywhere. So …

You learn to let it go. Actually at this point you might have lost your passion already. You’re less motivated if not motivated at all. You’re also at the stage of life where this is “just a job” and you just wanna get paid and go home. You’re not enjoying it anymore. You start complaining about Mondays and start hating “morning people” who talk to you before you have your coffee! You think at this stage that you’re finally an adult and you have reached maturity. Some people stay for a while in this stage. But you don’t really reach maturity until …

You realize that this is the nature of things. There is no such thing as “Intelligent Design” in the human world or in Engineering. Machines and Software are not intelligently designed but evolved! No one figures out everything at once. Things take time and people build on top of what other people achieved. You start believing in “Software Darwinism“.

You now know that software evolves and goes through natural selection (or customer selection?). The software might go through different changes. And the ones who satisfied the customer and adapted to its environment, survives. That’s what we call a stable software. When the requirements change, the software changes with it too. It doesn’t start from scratch. The stable parts are already carried over as long as it can still survive and no other alternative shows that it’s better at survival. Starting things from scratch, a.k.a refactoring, is not always a good idea. As long as it can survive it’ll still be there. Refactoring will only happen when that piece of software goes extinct because it’s impossible for it to adapt anymore making the only way to save it is to refactor it.

You might even take it to a further step and realize that a more evolved software doesn’t mean better. It’s simply more suitable for its environment and circumstances. Sometimes more evolved means more complex. Sometimes you get more complex then you realize you don’t need that complexity anymore so you simplify things then make them complex again. You might as well call yourself a software “adapter” rather than “developer” that looks like it’s only going for a general better.

You start acquiring a new skill for understanding how a software works. Not by the usual class hierarchies and design patterns, but more through software fossil records! And if you’re lucky enough, these fossil records requires no archaeology if you already have a recorded history for it, a.k.a version control!

So if you ever see any imperfections or inconsistencies, it shouldn’t bother you anymore. You now understand that that’s the way of the things. The way of the force!