Paradoxes In Software Development

Last Tuesday, I did an internal presentation of Redux to an audience that's primarily comprised of Angular+Spring and Drupal developers. Any backlash against a very functional approach was already expected given the strong OOP and DI predisposition. The following day, I got some (unprovoked, passive-aggressive) feedback regarding the presentation which made me realize that software development... has a lot of paradoxes.

Bleeding-edge vs stability

This one is a common paradox, especially for enterprise software. We have to update software to keep it up-to-date on bugfixes and security fixes. On the flip side, we abstain from updating to keep the software stable. The pros and cons on this one are clear: update and risk stability, or not update and risk security.

Refactor now vs refactor later

In theory, one should refactor small, early and often. This keeps rewrites small, and relatively harmless. But this puts the app at risk of breaking in places not scheduled for testing and management fears it becomes a rabbit hole. On the flip side, we abstain from refactoring and schedule it en masse later on. But a mass refactor is a big effort, one that may even involve more code, more developers, more coordination, more testing, and a near-zero business value.

Structure vs flexibility

There are developers who prefer flexibility, which is fine until code starts to form snowflakes. Now that developer has to explain what flexibility allowed them to do. On the flip side, there are developers who prefer structure, sacrificing flexibility in favor of a more standardized approach. Not the best approach in the world, but writing in a consistent manner allows for a more streamlined knowledge sharing and predictability.

Desire vs aversion of new technology

This one has bearings on both development and management. Every Tuesday, we have a developer lunch, where every developer on the floor gather and share ideas over several boxes of pizza. New ideas fly here and there, and everyone is amazed. Once everyone leaves the gathering, those ideas mentioned become grounded. Nobody wants to volunteer to try out the new technology, especially if one is already used to a workflow or train of thought or feels like its too risky.

Conclusion

If you did not understand the fix, then you have not fixed it.

The loudest critics are usually the ones who have not used it themselves. I was like that with React, until I saw the simplicity of both concept and implementation. Never be afraid to try. In fact, don't try. Just do it. I'm sticking with Redux for the forseeable future. Writing code that I can easily wrap my head around will do wonders for my skin and sleeping habits.

I don't like articles that leave it up to the reader to figure out stuff. So here's what I really do:

• I update dependencies very often. If something breaks, fix it. You will update that thing eventually, and break that thing eventually. Not updating is just running away from the problem.
• I refactor things as I see them. I fix them even though they're unrelated to what I'm currently working on. Again, you'll end up fixing that thing sooner or later anyways. Stop running away from the problem.
• I prefer code written consistently. It's code that you would have written differently, but would have written anyways. Better be consistent instead of writing it a dozen different ways.
• I ease new tech into what I work on. What's the harm in trying? If you can't ease it in and yank it out that easily, you have a bigger problem with your code.