I’m going to start this blog with a short explanation of the reason behind patterns of software design. Many of us heard about them. Some use the patterns from time to time, but most treat them like a religion.

Software design patterns isn’t a religion. It’s a practical asset for those who actually want to spend less time developing software. In many projects, it seems ludicrous to care about code complexity. I worked with developers who considered those things ‘aesthetics’ (read ‘unimportant’). Yet speed was the real thing for them.
Fuck speed. Fuck memory, fuck response time, fuck database indexes. Let us hold on for a moment and answer a simple question: do we know how to design good software? Using programming language and having experience with a certain framework isn’t enough. Most of us know how to combine several tools to create a software product. Some developers are very technical and they would go deep into specifics of every little thing. Speed and performance shine on a pedestal while hardware’s getting cheaper every day. By all means, I’m not against fast code. Yet in a well-designed software system, optimization is a polishing step, unless you have speed requirements set from day one.

I see we, developers, have two fundamental issues:

  1. The tendency to care about details more than the whole picture.
  2. The preference of immediate benefits in favor of much bigger values somewhere in future. We don’t want to waste time now to save it later.

When you find those issues in young developers—it’s ok. But old foxes usually don’t change. I’ve seen developers working on the same level for years. They feel significant, yet kinda funny because with time the only thing that changes is their speed :) Many companies like to see 10+ years of experience in a resume. That experience is controversial. What if you hire someone who’s been developing shit for 20 years and never improved? Ask them to code quick sort and you’ll learn nothing. Ask how caching works in Rails and you may find an experienced Rails user, but not a good software developer.

What’s important is whether a developer has been using design patterns, understanding their purpose and value. The key reason behind software design patterns is to spend fewer resources. Less time and money. That simple. If your software requires too much man hours—you have bad software. Why do you want to hire someone who increases your expenses? Why developers should do patching instead of developing? Each new feature makes software more expensive to maintain. Bad design results into an exponential growth of development cost. Good design is linear.

This blog is going to be about software design. Post by post I’ll explain the importance of it. I’ll show you how to create better software by focusing on essentials.

Thank you for spending time on this article. Stay tuned!