I was working in both small businesses and big companies so far. On my path I met different kind of programmers and had a lot of conversations about how to write good code, how should we structure files in projects and what's the purpose of specific design pattern. It's really great that developers have this urge to discuss ideas with each other - this is developing everyone!

Programmers talk very often about code design in general. I've met people with whom I could discuss about this for hours and hours and we were leaving table knowing, that we're both smarter. The thing I was struggling the most to understand, was people who didn't feel the need to exchange ideas and approaches. Not only that! Very often when I said "Nice code, but, you know, maybe split this into two classes, so it could be more readable, make smaller functions and change some names", they response was "It works and you can clearly see what this code does when you read it, why should I spend more time on this?". And, of course, they didn't.

I guess it's fair to say, that this actually is a valid question. I mean - why do we all care so much about design if our software works. Sure, maintaining it is a real pain, but it generates revenue, our product owner is happy and salary is on our account on time. I have to say, that this kind of thinking is actually logical. This approach is absolutely okay in some circumstances. For example when you have new idea and your goal is to put your product on market as fast as possible to validate it. This is actually very good definition of technical debt. I don't care about how my code looks like if it's readable and manageable I just need it to work as fast as possible. To do so I need to trade quality for faster development. I think it's okay to put code quality aside, because if this idea will turn out to be good, we will have time and purpose to refactor. Although if this product will fail we will know this fast, before we invested much resources into it.

Let's ask ourselves a question - how many of us actually work with really new products, that need to be out there super fast? I would say majority of programmers work for well established and profitable companies. In this case it's almost certain that project we're working on will last years after we resign. How many times you were working with code, really struggling to understand what it does and at some point you had to ask about it person, that actually wrote it? It's fine if he or she still works in the company... Wouldn't your work be easier if every piece of code was exactly where you would expect it to be? If every method would do exactly what it's name says?

It's hard to achieve that just like that. Good code requires not only very broad knowledge about software architecture but also communicating with other programmers. How you can know if code you just committed is readable or not? For you it will always be, since it was created in your head. You violated SRP in this class. How can you know if you won't have to refactor it at some point in the future if you don't have enough experience or don't know project too well. If you do, how can you know, that you're just not simply wrong?

For me answer to question whether we should or should not care about code design is simple - we should. Although there is no answer without "but", right? I think we should, but sometimes we should care more and sometimes less. If we're building start up it's okay not to have well designed and thought through architecture. Let's earn some money first, then we will invest into our product to make it maintainable.

On the other hand, if we're working on crucial piece of our system, would it really make that big difference if we will finish this task tomorrow and not today? I think that there is already too much mediocrity around us, that we really should find time for quality. We like to call ourselves specialists, but are we real experts if we only deliver software and not caring about it's quality? I mean - would you rather buy car that drives but it's a gigantic mechanical mess or car that not only drives, but it's also well designed and manufactured? Will your mechanic be able to fix your car quickly if it's really complicated and nothing is in place it supposed to be?

I came to the conclusion that in most cases we really should care about code design. Names matter, because they imply constraints and behaviors. If I choose wrong name for my class or method every other programmer will fall into my semantical trap and expect it to do something it doesn't do. Code should be placed in cohesive and thought trough way, because bug fixing starts with finding where the problem is. We don't need to reinvent the wheel - very often we just need to use one of the design patterns. Other programmers will recognize what we did and will be able to be productive more quickly. There are design patterns not only for class level, but also for whole enterprise systems and for integrating systems with each other.

Does good code design really cost so much? I think good programmer will write quality code unconsciously - this will be just integral part of process of writing it. In my opinion there is small difference in writing crap code and writing good code in terms of speed if you have required experience and good way it's just your natural way. If you don't have experience you could write bad code faster, but does it really pay off in long term? Maybe you should consider investing in learning how to write better code, so you can do it faster in the future? Wouldn't this be more profitable for you and you're employer? Finally - do you really can call yourself tech lead, senior developer or principal architect if all you care about is writing your code as fast as possible without thinking about quality?

What do you think about this subject? Let me know in the comments!