The true challenge in writing good software.
Code takes on a life of its own. As developers we pour our time and intellect into solving problems, and the manifestation of those solutions are found in the lines of code we write. Too often though, the code is controlling us as much as it is controlling the hardware it runs on. We often fail to think about how we write our code, how we structure it, or how others may view or use it. We let one line run to the next, and the code leads us.
Over the years I became frustrated with the corners that the code led me into. Frustrated with the tangle it became. Frustrated with reading other peoples tangle. So I started down the path of clean code. I researched standards, OOP, clean coding techniques, design patterns, TDD, Agile, DDD, etc. My code got cleaner, maintenance got easier, development velocity didn’t drop as rapidly as the complexity of a project increased. Things were good. There is a problem though. All these methodologies and techniques come with their own dialect. They have terminology and language that describe a complex solution, or a particular design decision in one succinct word. The problem comes in that not every developer is on this path. Many are stuck in fire fighting mode. The overtime hours stack up, any spare minute at work is spent on Facebook trying to find out what was missed while they were working late into the night. Learning new things after all the hours at the office is very low on the their hierarchy of needs. The unfortunate thing is that it is knowledge and experience that gets you out of the fire fight. Testable code, maintainable code. Prioritizing tasks. Understanding deliverables. Managing expectations. Communicating. And slowly I learned that software development is primarily about communication. The larger the project, the more apparent this becomes. Developers, designers, architects, business analysts, project managers, customers. Everybody has a role, and the way they see the project is determined by the lens that that stakeholder dons. Recently I have been leaning more toward methodologies rather than technologies and patterns. These often address the more critical aspects in a project, like communication. I have found though that a lot of my hard won lessons do not garner the immediate appreciation I have for them. The hard learned vocabulary of patterns and methodologies are meaningless when you are working in a team that does not know the terminology nor the benefits of the practices that go with the elitist vocabulary. The vocabulary is important as it allows the succinct identification of a complex idea. It is more important though to be understood by all stakeholders. So while I work on shedding my vocabulary for one with less assumptions, I will try and write about the principles that shape the code I write and the architectural decisions I make. And hopefully I will make elitist snobs out of you who have read this rambling post to the end.
Elitist snob training
Although the lines tend to blur, I have tried to categorise as best I can.
Principles
- Clean code
- SOLID
Design Patterns
- Repository
- Factory
- Command
- Decorator
- Visitor
Practices
- TDD
- DDD
Methodologies
- Agile