I’m hard-coded

About a year ago I paired on the certain problem with a client tech lead. I wanted to hard-code some stuff in a PHP class, he wanted to externalize this configuration to the database. After all, he convinced me that we should do it in the the database. Cool.

It appeared that one of the managers heard the whole discussion. Then, during iteration kick-offs and some other different occasions he used to say: “please don’t hard-code it“.

I asked one dev lately why did he externalize certain piece of configuration (I could bet my head that it was never gonna change).

He said: “I didn’t want to hard-code it and it’s only 2 more properties in the configuration file”.

So I told him about YAGNI. And I told him that our wonderful configuration file has now 230 properties. Oh by the way, we use 10 of them.

Hard-coding is such a dirty word.

On my current project, only Spring is configured in 120 xml files, proud 1 MB in total. I think entire universe is configured there.

My theory is that many people think that if it’s not in xml then it’s hard-coded. And since hard-coding is such a dirty word… well everything ends up in xml or properties file.

Maybe I’m weird but I prefer to configure my java apps using java, ruby apps using ruby and so on. Fortunately I am not the only one!

• In guice you configure dependencies in java code. I waited too long for that. Thank you guice.
• Rails apps have only few lines of configuration (database settings) and everything else is pure ruby code.

Configuring is such a noble thing. It’s just wise to remember that configuring is not equal to xml file. For java apps I tend to configure in java:

• it’s smaller, more KISSy (no supporting code to read configuration).
• lets me use refactoring tools to change configuration (e.g: in Spring you have to keep xmls in sync with your java refactorings).
• lets me use compiler to validate configuration (e.g: there is absolutely no way you can set “dummy” to the integer field). I can focus on solving problem rather than implementing configuration validation.
• usually doesn’t require documentation. Provided that class/method/variable names in your code are sensible. And I’m sure they are.

In the old days distinction between hard-coding and configuring was clear: written in C++ class = hard-coded = bad; written in script/properties file = configured = good. Unfortunately this understanding of hard-coding is still valid today: some think that having a constant in java class is dirty, let’s then add a new property to the system!

Sometimes externalizing configuration is perfectly valid, but it applies only to small number of properties. Those are usually: different on various environments, changed frequently, changed by non-developers, etc.

In the world of Configuration Over Hard-coding my stance is Hard-coding Over Over-engineering. Sounds a bit stupid but I couldn’t think of anything better.

Happy hard-coding!

paying the tech debt off

I so like comparing incurring a tech debt to taking a financial loan: You borrow Quality, in order to buy Time.

There is a car I want to buy. But I’m already overdrawn in Bank.

• If I buy the car now I will overdraw my limit and the bank will nail me with additional fees (Bastards, don’t have enough). I’ll pay off later.
• On the other hand I can pay some debts off and buy the car next month (and in meantime enjoy super-sonic public transport brought to you by district line).

In life I would definitely buy the car and worry about debts later. So what I cannot drive it? (some say that food is more important than gas but I’m not so convinced). At least I can wax it.

In software buying a car is a functionality to implement and being overdrawn is like having a tech debt. What would you do? Would you plug the functionality first and then refactor the debt? Or rather first make the place in the system and then implement the story?

Some thoughts about pros and cons of both approaches:

Implement first

• I can reliably measure the gravity of tech debt because I have to implement the story first and feel all the pain. I will know exactly what’s the interest rate for tech debt. It will be easier to make a conscious decision whether to pay it off or not.
• I will know better how to refactor it later since I did the story first. I will have all the information: code-wise understanding of the tech debt and knowledge about the story (technical requirements, code-wise problems).
• I waste time. Hacking in the story first takes long. Then the refactoring takes long. If only the refactoring was first the story could have taken 5 minutes…
• Let’s say I spend a day on implementing a story. Next day the business wants to know why am I refactoring piece of functionality that already works? I try to explain the tech debt and how easy will it be to implement future similar stories. Oups. Did I just forget about YAGNI?

Refactor first

• I may not be certain if paying tech debt off was really necessary. Perhaps implementing the story first was not too bad…
• It’s faster. Initial refactoring prepares a decent landing zone for new functionality. Implementing a new story after is blind fast.
• Let’s say I spend a day on refactoring. Next day It’s easy to tell the business that I couldn’t implement the story until some refactorings (paying the tech debt off) were in place.

Sometimes I can mix both ways but generally I prefer to refactor-first. It’s just faster and in my experience proved to be better. I hate to refactor-after because it leaves me the choice not to do it. I don’t like having choices – I prefer to fine-tune my approach/practices/process so that in front of me there is only one choice, one path. The right path of decent code.

bi-yearly review

In Thoughtworks I’m just before my bi-yearly review. I collected feedback from co-workers and clients.

Learning is important but learning about yourself crucial. The best tool to do that is asking for feedback. You can elaborate how important the feedback is but I’ll be quick. It’s the best.

To finish my review, I wrote few words about what I learnt in past 6 months. Here is the whole lot, things I learnt:

• i fond of pair programming
• i fond of frequent retrospectives
• how cool is eating lunch from Exmouth Market somewhere in the nearby park and chatting with fellow TWers about life and software
• ubuntu on my laptop laptop is a great thing unless you want to do anything else than coding
• i will never be able to write how much I learnt because I would have to write a book

longing for pair programming

Recently I’ve been delegated to consult for the designers team. I spent few iterations on improving: 1. software that helps designers, 2. processes (should I call them barriers?) between them and the developers.

Before I got back to the real work I received a neat farewell-poster.

Muscles are real, obviously (that’s why I don’t go to gym – I’m afraid I could burst).

As soon as I got to the front line of real story implementation, I realized how I missed pair programming.

Why?

Pair programming is a rare win-win deal:

• If you’re better than your pair you can teach and preach how to do things right 8=) This is how Thoughtworkers roll.
• If you’re worse than your pair then learn and suck in the experience. This is what I like the most.

Pair programming means passion and fun. Those are the most important ingredients of a recipe for decent software.