A library is essentially a set of functions that you can call, these days usually organized into classes.
Functions organized into classes? With all due respect, this is wrong. And it is a very common misconception of a class in object-oriented programming. Classes are not organizers of functions. And objects are not data structures.
So what is a "proper" object? Which one is not a proper one? What is the difference? Even though it is a very polemic subject, it is very important. Unless we understand what an object is, how can we write object-oriented software? Well, thanks to Java, Ruby, and others, we can. But how good will it be? Unfortunately, this is not an exact science, and there are many opinions. Here is my list of qualities of a good object.
Lines-of-Code (aka SLoC) is a metric with a terrible reputation. Try to google it yourself and you'll find tons of articles bad-mouthing about its counter-effectiveness and destructiveness for a software development process. The main argument is that we can't measure the progress of programming by the number of lines of code written. Probably the most famous quote is attributed to Bill Gates:
Measuring programming progress by lines of code is like measuring aircraft building progress by weight
Basically, this means that certain parts of the aircraft will take much more effort at the same time being much lighter than others (like a central computer, for example). Instead of measuring the weight of the aircraft we should measure the effort put into it... somehow. So, here is the idea. How about we measure the amount of times programmers touch the lines. Instead of counting the number of lines we'll count how many times they were actually modified—we can get this information from Git (or any other SCM). The more you touch that part of the aircraft—the more effort you spent on it, right?
Thus, in order to illustrate my strongly negative attitude to "mutability via setters," I took an existing commons-email Java library from Apache and re-designed it my way, without setters and with "object thinking" in mind. I released my library as part of the jcabi family—jcabi-email. Let's see what benefits we get from a "pure" object-oriented and immutable approach, without getters.
The subject may sound like a joke, but it is not. An empty line, used as a separator of instructions in an object method, is a code smell. Why? In short, because a method should not contain "parts." A method should always do one thing and its functional decomposition should be done by language constructs (for example, new methods), and never by empty lines.
I'm getting a few emails every day from programmers interested in working with Teamed.io remotely. The first question I usually ask is "what is your rate?" (we pay by the hour) What surprises me is how often people incorrectly estimate themselves, in both directions.
I hear very different numbers, from $5 to $500 per hour. I never say no, but usually come up with my own hourly rate estimate. This article explains what factors I do and don't take into account. These are my personal criteria; don't take them as an industry standard. I do find them objective and logical, though—so let me explain.
Twenty years ago, the best programmer was the one capable of fitting an entire application into a 64Kb .COM file. Those who were able to get the most out of that poor Intel 80386 were the icons of programming.
That's because twenty years ago computers were expensive and programmers were cheap. That was the time of the "hacker mentality." That time is over. That mentality is not appreciated any more, because the market situation is completely opposite.
Today, computers are cheap and programmers are expensive. This is the era of the "designer mentality," when the readability of our code is much more important than its performance.
When you hire a software developer (individual or a team), there are basically two types of contracts: fixed price or time-and-material. They are fundamentally different but the truth is that in either case—you lose.
In the eXtremely Distributed Software Development (XDSD) methodology everything is different, including the way we invoice our clients. Let's see what happens in traditional contracts and what changes in XDSD, which we practice in Teamed.io.
Every software project we work with is started from a Product Vision document. We create it during our Thinking phase. Even though the document is as short as two pages of English text, its development is the most painstaking task in the whole project.
There are a few tricks and recommendations which I'd like to share.
We usually design a Product Vision in four sections: product statement, stakeholders and needs, features, and quality requirements.
Do you have a software architect in your project? Do you need one?
Well, most agile teams do not define such a role explicitly and work in a democratic mode. Every important technical decision is discussed with the entire team, and the most voted for solution wins. When such a team eventually decides to put a "software architect" badge on someone's t-shirt, the most reputable programmer gets it.
The badge rarely changes his responsibilities, though. After all, the team stays the same and enjoys having technical discussions together, involving everyone. In the end, a software architect is more of a status than a role with explicitly defined responsibilities. It is a sign of respect, paid by other team players to the oldest and the most authoritative one among them. Right?