WAIT: Do you like your alphabet soup?

Once upon a time, software development was easy. You just write code. You now have more methodologies and principles than software engineers in the world.

Once upon a time, software development was easy. You just write code. You now have more methodologies and principles than software engineers in the world. So, let’s play a game. How many of these do you understand well?

Please add yourself a point if you know what it is, two points if you believe you understand it well, and five points if you understand it and used it (in production).

Programming paradigms

• OOP (Object Oriente Programming)
• Procedural
• Functional

• TDD (Test Driven Development)
• DDD (Domain Driven Design)
• BDD (Behavioural Driven Development)
• ATDD (Acceptance Test Driven Development)
• FDD (Feature Driven Development)

• KISS (Keep It Simple, Stupid)
• SOLID (ten extra points if you know the gender of Liskov :). No guesses allowed)
• DRY (Don’t Repeat Yourself)
• YAGNI (You Aren’t Going Need it)
• IOC (Inversion of Control)
• DIP ( Dependency injection principle)
  
  
  Other (got tired of categorizing them)
• AOP (Aspect Oriented Programming)
• FBP (Flow-Based Programming)
• Data-Oriented Design
• SSOT (Single Source of Truth)
  
  

And I am skipping development methodologies and architectural patterns just to keep this list sane. However, If you want to earn even more points, please feel free to visit this page (which contains well over fifty items): https://en.wikipedia.org/wiki/List_of_software_development_philosophies

And, now for the final round. What is the goal of writing software? I will give you a hint. It has nothing to do with anything that I was writing above.

The goal is to satisfy users’ needs.

I hope that you want to ask me by now: “Oh. Wait. What about all my points? Did I do well? Did I win?“

The answer is. We (software engineers) often get so wrapped around these tools that we are starting to believe that they are the goal (vs. a tool). This especially plagues better engineers. These tools do matter (to do things faster, cheaper, more predictable). However, again, these are just tools.

Good software engineers have more tools in their backpacks and can utilize them efficiently. And I would strongly encourage them to explore and learn. However, you don’t need to apply all tools (especially new shiny tools) in your next project. And it’s ok NOT to use some tools (even if they look promising).

There is a great book — Pragmatic Programmer. Frankly, I reread it last time quite a bit ago, so I can’t cite it by now. However, I liked the idea of pragmatism. You try different tools, learn their upside and downside, look around which tools gain adoption and which fall out of favor. And at the end, you decide what makes sense to use right here and right now.

Again, in the end, you need to keep your eyes on the prize — making customers happy.

And let me wrap it up with two personal anecdotal stories of how I applied this in life.

Unit tests and TDD

I remember when I got introduced to unit testing + TDD. I didn’t understand why it was so valuable. However, the architect I worked with back then (Mike Gaffney) asked me to try it out for a week. And oh man, I got hooked. I covered my code with unit tests since. However, I ended up being a little bit less impressed with TDD. I found that it’s a great tool when I know exactly what I need to do/how I need to do it/have a perfect understanding of the technology. I feel like using it in a discovery phase ends up being an impediment. (BTW. This subject is suitable for a separate article). I took what I found value out of TDD — think about testable design, think about interfaces, and move with small steps. I threw out a part that tests have to be ALWAYS written first. I write tests first when it suits me, and I postpone writing tests when it constrains me.

AOP

At some moment, probably about ten years ago, I learned about Aspect-Oriented Programming. I read about it, and one of my friends highly recommended it to me. I tried it, and it felt like quite an excellent way to separate concerns. However, on the other hand, I thought that understanding how the system works would be unbelievably hard (BTW. Obviously, it’s not just my observation — https://en.wikipedia.org/wiki/Aspect-oriented_programming#Criticism). On top of that, the number of people who utilized AOP was minuscule. As a result, if I write such code, it would be tough for anybody to follow. And after some consideration, I put this aside to see whether it will pick up popularity. I wasn’t eager to be an early adopter. Looking back, I think it was the right decision. It ended up being used in some particular use cases but didn’t gain wide adoption.

And a simple summary. Learn new things, apply them when necessary, but do poke holes in them and be pragmatic.