Palace Driven Development

A poor man and a rich man wanted to roast a rabbit. The poor man lit a bonfire, put the rabbit on a stick and sat by the fire holding the stick. The rich man snorted at such a simplistic rabbit roasting: What if rain comes while I’m roasting? What if somebody attacks me and steals my rabbit? I need something much more professional!Burj al Arab (Dubai, UAE)

So he decided to build a small hut to protect his bonfire. He hired some builders, and they convinced him that such a dignified man needs a real stove, not a shabby bonfire. He also needed an elegant dining room, or else he’s going to eat his roasted rabbit sitting on the sand. They agreed on the price and set on building the house.
Continue reading



I got a very interesting comment from Rick Pingry and I’m taking a liberty to respond to him in the post format, because I think his questions deserve so. In general, Rick expresses his doubts about going TDD all the way and raises some really good questions about practical side of TDD. What’s interesting (to me at least) is that he works on a C++ application, so it’s good to hear that even the C++ world is catching up with some modern trends :)
Continue reading

I didn’t have enough time

“I really didn’t have enough time for that…” — this is the most frequent excuse used by programmers for writing messy code, skipping refactoring, not writing unit tests etc. This is a poor excuse and there are at least two things wrong with it.

The first one is the unstated assumption that writing clean, tested, extendible code takes some horrible amounts of time (as opposed to writing quick & dirty code, which apparently takes no time). This is not true and I’m not the only one that thinks so. Of course, if you’re totally new to writing high quality code, it might take you some time to get fluent with it. But in this profession, you should be constantly learning anyway.

Also: if you take technical debt into account, you will see that writing high quality code is faster in the long-term because there will be less bugs, new features can be implemented faster and new developers can be brought in without extensive training.

The second thing wrong is the psychological aspect. In most cases it’s the developer that estimates how much time is needed for implementation[1]. So the question is: why don’t YOU include in your estimations the time needed to do it right? If implementing some feature right would take 5 days (because you know that this specific area needs heavy refactoring), why do you say “2 days” instead? Are you afraid of saying “5 days”? Is somebody going to fire you for that? Unlikely. Shout at you? Also unlikely. Can’t you stand a little shouting, anyway?

[1] I worked at several companies, from 3-people startup to large software house, from bank startup to global corporation, with wildly different methodologies and tools, and had not seen a single case when the developers were held responsible for estimations done by someone else.

My advice: estimate the time it would take if you would do this the best way you can imagine, including good design, the long overdue refactorings, unit, functional and integration tests (as needed), documentation and everything else you consider makes code better. And then stand for it. Fight for it, if you think it’s worth it.

But only if you really want to do all those things, that is, because the problem might be that you think they would be nice but are too lazy to do them. Maybe you don’t fight for it because you’re happy with the way it is and don’t care about your project’s future?

Of course, your estimation might be questioned (“why do you need so much of time for something so simple?”) or your manager might argue that “maybe you could do it in half that time” or “the CEO will be very upset if it’s not working by Friday” or “we have already spent a fortune on the advertising campaign, so there’s no way we can postpone the deadline” or the customer won’t stop haggling with you to do that in half time and for half pay. Life is brutal, or so they say.

Pointy-haired Boss

Do you really think your Pointy-haired Boss will tell you “I want you to take 3 days extra for refactorings”?

If you are questioned, explain what it takes to write good code, what the technical debt is, how clean code makes the development faster in the long run etc. Why do you expect your manager or customer to know what it takes to write high quality code and why it’s better for them? You need to educate them.

Make your manager understand the risks so they can make an informed decision. You might be forced to skip some of the elements anyway and finish sooner, but at least you will have higher margin for negotiation. It’s OK for me to take shortcuts if I know that my manager is aware of the risks, we feel the technical debt is under control and the situation is exceptional.

Similarly, if you’re in the startup, struggling to get the first version out the door with competitors breathing down your neck. Go ahead and take every possible shortcut to make it ready ASAP, I’d say, but be aware that you’re building the technical debt and you’ll have to pay it up sooner or later. That’s why many successful startups go through complete rewrites of their applications at later stages, I think.

Three brilliant ideas

Escher's RindThis is a short list of brilliant ideas that have fascinated me for some time now, but I doubt I will find any chance to use them in foreseeable future. These are not mine (sadly) but have been virtually haunting my mind since I learned them.

What I like in them is a combination of simplicity and out-of-the-box thinking that is characteristic to elegant inventions. It’s also cool that the core of these ideas can be expressed in one sentence, but it fundamentally changes the way you look at the problem. I decided to spread them not because I think you might use them right away but for the sheer joy of writing about beautiful ideas.

Using DNS as a load balancer

I first heard about it on this presentation by Jason Hoffman of Joyent at RailsConf Europe 2007 (this topic is covered on the slides from 128 up but go ahead and read all of it if you’re interested in big-time scaling). Jason was talking about many interesting things but this one idea struck me as one of the brightest I heard in a long time.

BelvedereBasically, if you run a Web application accessed worldwide, you can leverage DNS servers as a first-level load balancers by setting up different IPs for different areas of the world. You can make users in Europe use your European server, US users go to the US server and so on. Not only you get load balancing, but your users’ experience is a little bit better because the server is closer to them.

Of course, there are more possibilities and you don’t have to go by geography at all. There is also similar technique known as Round robin DNS.

Self-modifying viruses

In the old days (say MS-DOS or Win 3.1 days), the virus could employ many techniques to hide from anti-virus software, but their code was rather constant. Once the anti-virus was in control of the computer, it could easily find the virus by searching for a known sequence of bytes. Of course, there was a lot of mutations of each virus, but most of them were done by I-don’t-know-how-this-works-but-let-me-insert-my-nickname-here kids to impress their friends.

Escher's famous self-drawing handsThen the self-modifying viruses came. The basic idea is that on the machine code level there are many different ways to achieve the same result. For example, instead of loading the constant 12345 into a register, you might zero the register then add 12345 to it, you could push 12345 on stack then pop it into the register, you can load 9999 then add 2346 (or use any other arithmetic operation). If you want to modify some variable in memory, you can load it into different registers or you can set up the stack pointer so the next pop will read this.

When you get the idea, the possibilities of obfuscating the code are endless. This method allows you to generate a new mutation of your virus that does exactly the same thing but not even one instruction is the same.

There are even more advanced techniques, like reordering the blocks of code, which requires you to track all the jump instructions in your code, but once you do that, you can rearrange the blocks of code in virtually every way. And this is no black magic, the operating systems and linker programs have been doing it for years now.

Escher's Metamorph

I can’t find the original article, where I first read an analysis of actual metamorphic virus and a very good explanation of these techniques, but if you want to learn more, these links are good place to start: and

Of course, this all leaves you with one fundamental question: how do the anti-virus programs deal with this?

Memory pool with a free list

Escher's WaterfallAnother rather low-level idea that allows fast finding of free slots in an array of preallocated objects of the same size. What’s really clever is that free slots contain pointers to the next free slot thus creating a linked list of slots. This way you need only one additional pointer (to the first free slot).

Each time you need to allocate a slot, you grab what’s under this pointer and update it to the address of next free block (found at the beginning of this block). Deallocation mirrors this process by storing the current pointer at the beginning of deallocated block then setting the pointer to the address of this block. Thus allocation and deallocation work in constant time O(1).

This is probably the most easily employable technique of the three I described, so whenever you find yourself building some kind of cache or pool manager (of database connections or worker threads etc.) remember the term “free list”. Learn more from Wikipedia articles: Memory pool, Free list. This algorithm is used by Ruby’s virtual machine: Garbage Collection and the Ruby Heap (starting at slide 13).

Reality check: is your project meaningful?

Here is a simple reality check for you: do models (entities) in your project tend to have names like Item, Content, Object, Data or ContentItem? If so, your project may not be meaningful to your users. You’re probably going to (or already do) have problems in communicating with them.

You see, the end users and domain experts don’t think in this terms. They don’t order “items” to build some “thing”. They order laser cannons and remote controllers to build a giant laser-beam-shooting, remote-controlled robot.

Giant Robot

That's what they're building.
So you better do a good job with what YOU are building.

If you call some entity an Object it means you don’t really know what it is and what it does. I bet the domain experts don’t call it an “object”, they call it “a part used to build a giant robot”. Can you see how much more information is given by a good name? Your “object” is a Part, so it has some technical characteristics, it belongs to some robot(s), it is probably stored in some warehouse, it may have a price, versions, dependencies, requirements, subclasses etc. This list could go on and on.

Laser Canon

A laser canon, not just an “object”…

On the other hand what does the name Object tell you? From my experience, it tells you that the developers don’t understand the users, the users don’t understand (and hate) the application, the specs are missing or outdated and no-one is able to identify a single use-case for the system. In short, not much of a success.

So, what’s your favorite meaningless name?

On salary negotiation during job interview

I have mixed feelings after reading the article The answer to the toughest interview question on salary negotiation during job interview. Also, there is much valuable advice in the over 160 comments, but some of them only deepen the confusion.

Penelope’s advice is to never give your desired salary, but make the interviewer state their range first (using your slick negotiation techniques). Some of the commenters agree with this while other say that it’s best to simply state a number that will satisfy you and you’ll either get a job with a satisfying salary or not get a job that you would not accept anyway. I’d like to share my experiences, which are somewhat different from most of the people commenting there, mostly because the situation and apparently the law is different here in Poland.
Continue reading

TDD makes you deliver faster

I’m sick of hearing the same old song again and again: “we wanted to try TDD but it would make us go slower, and we wouldn’t make the business friendly deadlines so, you know, maybe next time”. This is bullshit. A myth. An urban legend. Not true. The truth is just the opposite: TDD makes you deliver faster. How can this be?

Well, it’s true that TDD makes you write more code than if you wouldn’t write automated tests at all. But, anyone who knows a little bit about programming will tell you that actual banging at the keyboard (i.e. writing or editing code) takes only a small fraction of programming time. Of course, this varies between developers and, of course, I didn’t measure it, but I’d estimate it to take only 10% to 50% of productive time (i.e. not counting the time developers spend surfing the net or attending the meetings).

All of the rest is consumed by various coding related tasks: thinking, designing, discussions, brainstorming, committing to the repo or updating from it, waiting for the code to build and/or compile (optional of course), digging through the docs, browsing help and forum sites.

And, if you’re not practicing TDD, you also have to waste a lot of time on debugging the application, manual testing (restarting it, logging in and navigating to the screen on which you can observe the effects of your changes to the code (again, optional), and fixing the regressions you introduced (not all though — only those that you noticed (and chose not to ignore) on your way to the above mentioned screen).

So, instead of wasting enormous amounts of time and effort on manual testing and debugging, the effects of which vanish into thin air with the next line of code you change, why not start writing automated tests and have these same tests executing over and over, automatically, for the project’s whole lifetime?

And one more thing about debugging: while working for 2,5 years with Ruby on Rails projects that have been done with TDD and/or had high level of test coverage, I hadn’t used a debugger. Not even once. Unbelievable for Java folks, but true.