Very often readers of my books ask me why I don’t publish them in digital format as e-books for Amazon Kindle, EPUB, FB2, or simply PDF. There are a few reasons. It’s time to summarize them all and explain why dead trees are the only way to go if you want to read my content.
Command and control has worked effectively in military units across the world for thousands of years. But apparently we’ve just discovered that the best companies are built on different verbs, which are inspire, delegate, trust, lead, innovate, etc. The question is whether we really uncovered something new that our predecessors failed to understand for ages or something else is going on.
I interviewed David West, the author of the Object Thinking book, a few weeks ago, and he said that classes were not meant to be in object-oriented programming at all. He actually said that earlier; I just didn’t understand him then. The more I’ve thought about this, the more it appears obvious that we indeed do not need classes.
We all know that inheritance is bad and that composition over inheritance is a good idea, but do we really understand why? In most all articles I’ve found addressing this subject, authors have said that inheritance may be harmful to your code, so it’s better not to use it. This “better” part is what bothers me; does it mean that sometimes inheritance makes sense? I interviewed David West (the author of Object Thinking, my favorite book about OOP) a few weeks ago, and he said that inheritance should not exist in object-oriented programming at all (full video). Maybe Dr. West is right and we should totally forget extends keyword in Java, for example?
Objects responsible for too many things are a problem. Because their complexity is high, they are difficult to maintain and extend. Decomposition of responsibility is what we do in order to break these overly complex objects into smaller ones. I see two types of this refactoring operation: vertical and horizontal. And I believe the former is better than the latter.
Each software team organizes its communications in its own specific way. Some use Slack, Trello, or GitHub; others just sit together in the same room. There are many methods and tools. I believe it’s possible to rank them by the amount of damage they cause to your project. This is the list of all of them I’m aware of at the moment.
Recently, I was trying to convince a few of my readers that a better understanding of an object in OOP would help us solve many problems in existing pseudo-object-oriented languages. Then, suddenly, the question came up: “What problems?” I was puzzled. I thought it was obvious that the vast majority of modern software written in modern OO languages is unmaintainable and simply a mess. So I Googled a bit, and this is what I found (in chronological order).
In most cases (maybe even in all of them), if-then-else can and must be replaced by a decorator or simply another object. I’ve been planning to write about this for almost a year but only today found a real case in my own code that perfectly illustrates the problem. So it’s time to demonstrate it and explain.
OK, the title is not exactly accurate. I’ve missed the “can” word. A distributed team can deliver code of much higher quality than a co-located one, and now I’ll explain why. Of course, not every distributed team can do that. Most of them can’t even deliver code that works, let alone quality code. But if a team—a distributed one—is managed according to the principles I’ll explain now, the quality will be much higher than the same team can achieve if co-located. What I’m going to show you is that working in a remote mode, if done right, guarantees higher quality of code. Surprised?
There are a number of levels you have to go through before your continuous integration pipeline becomes perfect. I found eight of them and presented my findings at DevOpsDays in Salt Lake City a few weeks ago (watch the video). Now it’s time to write them down and ask you—Which level are you at? Post your answer below.
You probably remember what I think about ORM, a very popular design pattern. In a nutshell, it encourages us to turn objects into DTOs, which are anemic, passive, and not objects at all. The consequences are usually dramatic—the entire programming paradigm shifts from object-oriented to procedural. I’ve tried to explain this at a JPoint and JEEConf this year. After each talk, a few people told me that what I’m suggesting is called ActiveRecord or Repository patterns.
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?
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).
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.
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.
I believe that several roles should be present in a majority of software projects. Managed by Zerocracy 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.
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.
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?
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.
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.
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.
A project manager is very often confused with a leader. However, they are two very different things. A project manager is the one who predicts the future, while a leader is the one who builds it. And, in my opinion, a perfect project manager is much more valuable for a project than a leader. If a leader is valuable at all…
“Convertible Notes” is what you most likely will hear the first time you get money for your first startup. They will give you cash asking to give them the convertible notes (or SAFE, which is very similar). Convertible notes are just a few pages of paper with two signatures at the bottom. Not too much to worry about. It’s basically a contract between your startup and an investor. Let’s see what exactly it says and what you, as a founder, should pay attention to.
Over the last six months, I’ve attended 18 conferences and heard over 30 keynote sessions, mostly about software development and management. I think I now know all the secrets of a successful keynote speaker. It doesn’t look so difficult to become one. Here are my thoughts.
Constants… I wrote about them some time ago, mostly saying that they are a bad thing, if being public. They reduce duplication, but introduce coupling. A much better way to get rid of duplication is by creating new classes or methods—a traditional OOP method. This seems to make sense and in our projects I see less and less public constants. In some projects we don’t have them at all. But one thing still bothers me: unit tests. Most programmers seem to think that when static analysis says that there are too many similar literals in the same file, the best way to get rid of them is via a private static literal. This is just wrong.
It’s not just about InputSteam, this class is a good example of a bad design. I’m talking about three overloaded methods read(). I’ve mentioned this problem in Section 2.9 of Elegant Objects. In a few words, I strongly believe that interfaces must be “functionality poor.” InputStream should have been an interface in the first place and it should have had a single method read(byte[]). Then if its authors wanted to give us extra functionality, they should have created supplementary “smart” classes.
Using object properties as configuration parameters is a very common mistake we keep making mostly because our objects are mutable—we configure them. We change their behavior by injecting parameters or even entire settings/configuration objects into them. Do I have to say that it’s abusive and disrespectful from a philosophical point of view? I can, but let’s take a look at it from a practical perspective.
Annotations were introduced in Java 5, and we all got excited. Such a great instrument to make code shorter! No more Hibernate/Spring XML configuration files! Just annotations, right there in the code where we need them. No more marker interfaces, just a runtime-retained reflection-discoverable annotation! I was excited too. Moreover, I’ve made a few open source libraries which use annotations heavily. Take jcabi-aspects, for example. However, I’m not excited any more. Moreover, I believe that annotations are a big mistake in Java design.
Revenue means cash that is coming into your bank account every month from your customers. Not investors. Customers, those who are buying your products or services. You are doing everything you can to make sure this number grows, mostly because you use this money to pay your rent, buy food, and settle that graphic designer’s invoices. Without revenue, your startup will die, right? Yes, maybe. But in my experience, growing revenue may kill it even faster.
Getters and setters are evil. No need to argue about this, it’s settled. You disagree? Let’s discuss that later. For now, let’s say, we want to get rid of getters. The key question is how is it possible at all? We do need to get the data out of an object, right? Nope. Wrong.
CDN stands for a Content Delivery Network. Technically, it is a bunch of servers located in different countries and continents. You give them your logo.gif and they give you a URL, which resolves to a different server depending on who is trying to resolve it. As a result, the file is always close to the end-user and your website loads much faster than without a CDN. Sounds good, but all CDN providers want money for their service and usually a rather complex setup and registration procedure. My pet project jare.io is a free CDN that is simple to configure. It utilizes AWS CloudFront resources.
Your success depends on the quality of your elevator pitch. Basically, your success doesn’t depend on much of anything else. The pitch is king. You have to impress the catcher investor in just a few seconds while the elevator is still moving (that’s where you are supposed to hunt for that prey). It’s not rocket science; you can learn a few basic principles and become an expert. Here they are, the principles.
There is a very typical mistake in pre-Java7 “try/finally” scenario, which I keep seeing in so many code reviews. I just have to write about it. Java7 introduced a solution, but it doesn’t cover all situations. Sometimes we need to deal with non-AutoCloseable resources. Let’s open and close them correctly, please.
I’m taking participation in over 50 repositories in GitHub. We manage all of our projects there. GitHub is sending me hundreds of emails every day. I’m serious. Hundreds! I tried to filter them somehow in Gmail, but it’s not really possible. Gmail filters are not powerful enough to understand the difference between different types of notifications, and there are many other problems. I decided to create my own simple filtering machine. It’s called wring.io.
There are tons of articles about resume writing. Literally, tons of them. And here’s yet another one? Well, maybe … but I don’t think so. I’ll try to give you a few practical hints for how to make your resume look “sexier,” and how to position yourself beyond the “good programmer” category and into the superstar zone. It may take a few years to truly pimp up your CV, but when it’s done, you will charge $100-plus per hour and face no hesitation from your clients in paying.
At Zerocracy, we’ve been getting about 10 resumes every day from programmers who want to work with us. We don’t do video or online coding interviews. We don’t ask you to solve any puzzles or demonstrate your algorithm-writing abilities. Moreover, when we decide not to hire you, we honestly and openly explain why. And we almost never offend anyone. So how exactly does it work? There are a few basic principles I would like to share.
I strongly believe that while it is very effective to structure an organization in a democratic and sociocratic way, a project should be managed completely different. A project should resemble a dictatorship, authoritarian or military hierarchy with a single strong, result-oriented leader who gives explicit orders that are never doubted by subordinates and an explicitly defined hierarchy.
Debugging is “a process of running a program/method interactively, breaking execution flow after each statement and showing…” In a nutshell, it is a very useful technique … for a bad programmer. Or an old programmer who is still writing procedural code in C. Object-oriented programmers never debug their code—they write unit tests. My point here is that unit testing is a technique that completely replaces debugging. If debugging is required, the design is bad.
Design Patterns are … Come on, you know what they are. They are something we love and hate. We love them because they let us write code without thinking. We hate them when we see the code of someone who is used to writing code without thinking. Am I wrong? Now, let me try to go through all of them and show you how much I love or hate each one. Follow me, in alphabetic order.
Do you check the input parameters of your methods for validity? I don’t. I used to, but not anymore. I just let my methods crash with a null pointer and other exceptions when parameters are not valid. This may sound illogical, but only in the beginning. I’m suggesting you use validating decorators instead.
Let me put it this way: $15 per hour for a senior Java developer—is that cheap or expensive? It’s cheap, right? Right. What would you say if I told you this cheap Java developer hardly writes two primitive lines of code per day? You’re paying $600 every week but rarely getting anything back. How cheap is this Java guy now? My point is that using hourly rate as a cost indicator is a very bad idea, whether with outsourcing or in-house teams.
“You’re a good programmer. I’m a great entrepreneur. This is a breakthrough idea. Help me build it. I don’t have cash, but I will give you equity. Deal?” I hear this at least once a month, and I always say no. Not because I don’t like your idea. Indeed, it is really interesting. And not because I’m too busy. I would definitely find time for a good idea. It’s not that. I say no because I don’t think you’re a good entrepreneur.
Punishment … how do you prefer to do it? There are many ways to punish employees; some are rather effective, while others simply don’t work. This is not an exact science. Actually, I would say it’s an art. You must be creative, innovative, and very open-minded. You never know which method of punishment will work with whom. Some people respond to one method, while others may completely ignore it. The overarching goal, of course, is to make employees scared of you, their boss, so they will obey enthusiastically. Here is a list of the most effective methods.
This is what Wikipedia says about this: “High turnover may be harmful to a company’s productivity if skilled workers are often leaving, and the worker population contains a high percentage of novices.” I agree. However, I believe that low turnover may also be very harmful.
In my How Much Do You Cost? post last year, I said open source contribution is a very important factor in defining who is good and who isn’t, as far as programmers go. I was saying that if you’re not contributing to open source, if your GitHub profile is not full of projects and commits, your “value” as a software developer is low, simply because this lack of open source activity tells everybody that you’re not passionate about software development and are simply working for money. I keep getting angry comments about that every week. Let me answer them all here.
