Convince Me!

  • 869 words
  • four minutes to read
  • comments

I've already explained how I understand the role and responsibilities of a software architect. But one question still remains unanswered, and it often turns into a problem in our projects: What does a software architect do when the project sponsor doesn't like his technical decisions? The architect implements something in a certain way, and the sponsor (or its representative) says that it's not exactly how things should work. What's next?

continue...

The Law of Demeter Doesn't Mean One Dot

  • 481 words
  • two minutes to read
  • comments

You've probably heard about that 30-year-old Law of Demeter (LoD). Someone asked me recently what I think about it. And not just what I think, but how it is possible to keep objects small and obey the LoD. According to the law, we're not allowed to do something like book.pages().last().text(). Instead, we're supposed to go with book.textOfLastPage(). It puzzled me, because I strongly disagree. I believe the first construct is perfectly valid in OOP. So I've done some research to find out whether this law is really a law. What I found out is that the law is perfect, but its common understanding in the OOP world is simply wrong (not surprisingly).

continue...

Who Is an Object?

  • 972 words
  • four minutes to read
  • comments

There are thousands of books about object-oriented programming and hundreds of object-oriented languages, and I believe most (read "all") of them give us an incorrect definition of an "object". That's why the entire OOP world is so full of misconceptions and mistakes. Their definition of an object is limited by the hardware architecture they are working with and that's why is very primitive and mechanical. I'd like to introduce a better one.

continue...

Twelve Mistakes in Agile Manifesto

  • 1698 words
  • 7 minutes to read
  • comments

Nowadays, Agile Manifesto is a Bible of numerous software teams. It contains 12 principles which show us how software development should be organized. These principles were invented in 2001. Generally, I like and agree with all of them. However, in practice, most software teams misunderstand them. Consequently, here is a summary of what's going on and my interpretation of each principle.

continue...

Key Roles in a Software Project

  • 308 words
  • two minutes to read
  • comments

I believe that several roles should be present in a majority of software projects. Managed by Teamed.io according to the principles of XDSD, we've got all of them in our projects. However, beware that in other management methodologies, these roles may have different meanings. This blog post is mostly for people who work with us, either as clients or freelancers.

continue...

Data Transfer Object Is a Shame

  • 450 words
  • two minutes to read
  • comments

DTO, as far as I understand it, is a cornerstone of the ORM design pattern, which I simply adore. But let's skip to the point: DTO is just a shame, and the man who invented it is just wrong. There is no excuse for what he has done.

continue...

Singletons Must Die

  • 439 words
  • two minutes to read
  • comments

I think it's too obvious to say that a singleton is an anti-pattern as there are tons of articles about that (singleton being an anti-pattern). However, more often than not, the question is how to define global things without a singleton; and the answer to that is not obvious for many of us. There are several examples: a database connection pool, a repository, a configuration map, etc. They all naturally seem to be "global"; but what do we do with them?

continue...

How to Hire a Programmer

  • 1120 words
  • five minutes to read
  • comments

I get asked this question very often: Where and how do you find and hire a good programmer? Since I'm a programmer and I manage software projects, I'm supposed to know the tricks. I do, of course; there are many of them, but the list below succinctly summarizes the most important ones.

continue...

Don't Use Java Assertions

  • 240 words
  • a minute to read
  • comments

There are basically two ways to validate a situation in Java and complain when something unexpected happens. It's either an exception or an assertion. Technically, they are almost the same, but there are some small differences. I believe that exceptions are the right way to go in all situations and assertions should never be used. Here's why.

continue...

11 Mistakes Conferences Keep Making

  • 1338 words
  • five minutes to read
  • comments

I was talking yesterday with a few friends who were software conference organizers. They were asking about my opinion of the conferences I've recently attended. Basically, they were interested to know what I would suggest for improvement. So, I decided to summarize it in a list of the most typical mistakes all conferences keep making and give them some ideas. Remember, I'm judging from a speaker's position. The most serious mistakes and pieces of advice are at the bottom.

continue...