The above code is probably how most of Rails programmers would go about implementing a “user has many posts/post belongs to its author” scenario. It’s the tutorials-approved way. But when you look at it from a architectonic point of view, you have just created a circular dependency.Continue reading

Recently I have been doing some job interviews (as an interviewer, not a candidate). Although I hate being schematic and try to come up with new & interesting questions for every candidate, I always ask My Favorite Interview Question, which is:

The answer for that immediately tells me, whether the candidate has broader horizons or is just a doing-what-I’ve-been-told-to-do drone.

So, what’s a bad answer? Anything along the lines of “DI allows you to configure your dependencies and inject them by a framework.” Seriously, that’s an answer that I would come up with if I had not even the faintest idea what DI is, and I get it from developers who claim several years of experience, working with Enterprise Java and all that stuff.

Even worse: candidate mentions XML in the first sentence. I mean, what are they thinking? Is “using XML” among the benefits of Dependency Injection? (I would say it’s a cost, not a benefit, but let’s leave that for another rant.) My point is, DI and XML are concepts from totally different and unconnected levels.

When you use DI, you might want to have your dependencies automatically injected, for that you might want to use the Spring framework (if it’s a Java project), and then you might want to configure it with XML files. See how many steps it takes to connect DI and XML? On each step you could decide to use something else, so there’s a good chance that you end up with no XML at all. And yet, XML has been imprinted so deep in Java developers’ brains that you might hear “DI lets you configure your classes with XML.”

OK, so what qualifies as a good answer (at least according to me)? Anything from “DI improves testability because you can easily mock dependencies” to “DI enables loose coupling” to “DI enables flexibility” to “I don’t see any benefits of DI, therefore I don’t use it” even.

In fact, any answer in form of “I don’t see benefits of X, therefore I don’t use X” is better than “I use X because they told me to/everyone uses it/that’s how it was always done.” It shows that you made a conscious decision about using or not using X. Of course, I would still like to know why you don’t want improved testability or loose coupling. But at least this is something that can be further discussed.

And the best answer would be that you don’t use DI, DI just happens when your code is testable and loosely coupled. So, if you happen to be interviewed by me, you will be asked this question, too. Now you probably know what answer would satisfy me. And if you get the job, that would probably be the first case of someone benefiting from reading this blog :)

it may be difficult to spot a trend in it. That’s why people use charts and other visualization tools and there’s a lot of them (you could use Excel, Google Charts, gnuplot, sparklines etc.).

However, sometimes it’s not possible or convenient to use any of this tools. In such cases, you can easily create a simple ASCII-art style chart. Doesn’t this look better?

MONTH

COUNT

2011-10

417

########

2011-09

903

##################

2011-08

1051

#####################

2011-07

759

###############

2011-06

835

################

2011-05

647

############

2011-04

393

#######

It’s actually so embarrassingly obvious I would not bother posting about but in the last couple of days several people told me that they think it’s a great idea that they wish they knew earlier. So here it is.Continue reading

While you weren’t watching I went and created a small iPhone app: WeekProgress. Don’t expect too much functionality (or sense!) there – it was born mainly for learning purposes. It features a main screen and 3 (three!) screens worth of settings.

Working week progress bar

On the main screen you’ll find a progress bar that tracks your way through the working week. It starts at 0% on Monday morning and goes to 100% on Friday afternoon. The settings allow you to select working days and change working hours, so you can adjust it to your schedule.

Changing working hours

And it’s free! And it features insightful and funny comments! And it looks like a couple of folks already installed this! So what are you waiting for?

Why? Oh why?–you say… It’s because the IT Management appointed checkstyle and checkstyle has been configured to complain about Magic Numbers.

Checkstyle skips 0, 1, and 2 by default as too frequent, that’s why only numbers from 3 up are defined as constants here.

The developers did not bother to replace the Magic Numbers with some meaningful constants, they just got rid of the warning with a couple of what should rather be called “refucktorings”.

As an added bonus to the last block of code, the NUMBER_OF_LOOPS constant is read from configuration file, so theoretically there could be other number of results, but the code here is hardcoded to provide 5 of them. I suspect that the NUMBER_OF_LOOPS was meant for something else, but since it happened to have the desired value, it has been “reused”.

The developers probably heard somewhere that “you should use StringBuilder for string concatenation” and followed that advice religiously, ignoring the fact that it’s only applicable for string concatenation inside a loop.

So, the code is sprinkled generously with comments that might be useful only to someone without any knowledge of Java syntax whatsoever (but then how would they know what is a comment?) but if you check how much of the public API has javadoc, it’s less than 5%.

Conclusion

You can’t force the developers to write better code just by forcing the use of metrics, coding conventions, standards etc. You need to educate them. They need to understand the rationale behind each rule or advice and accept them. Otherwise they will game the metrics out of laziness or maliciousness and you’ll get code like above.

You know what future is now? The one you mentioned one month ago, when you said “let’s copy and paste for now and fix it in the future.” And the one from “we’ll add unit test for that in the future.” And when will this “later” from “we’re going to refactor this later” happen? Later, of course.

Your “now” is the “future” in which former developers hoped to find some time and fix all the problems. They never did, of course, and now you are pushing even more into the future, for yourself or your successors. It’s like taking a huge debt intended for next generations to pay up and then taking even more debt just to pay the interest. It’s like a Ponzi scheme in development :)

If you always decide to cut corners “now” and fix it in the “future”, that future never comes. Instead, you’re setting yourself up for the future of constantly putting out the fires and wondering why your application cannot be more stable.