Do it only when you need it

Writing good quality code is somehow jumbled and not an easy task to do. To be honest, it's a matter of your experience - the more code you write, the easier is to make it reusable and easy to understand. As a beginner I tended to write many layers of abstraction, which were supposed to separate all the concerns. At least it's something many books and tutorials for "rookies" say - create a lot of abstraction, use this, use that - it will help making your code maintainable. To make a long story short - it's a complete bullshit.

The more abstraction you introduce in your code, the harder it is to understand it. You can divide your 50 LOC method into three different ones, which JIT compiler will inline anyway - but is it something you're doing because you know it's the right thing to do? You can introduce all those builder, singleton, abstract factory patterns - but are there any evidences you're delivering any value to the codebase? In most cases we're doing something because a mysterious man - the author of the most popular C++/C#/Java book - said so. We're building the foundations of our skills basing on fairy tales, which are completely irrelevant in a real world.

Very few people proclaim a very easy and straightforward rule - do it when you need it.

The rules are simple. Don't introduce a pattern if don't need it yet(and never introduce it, if you don't understand it). Don't introduce an abstraction, if you're not sure what your code is going to look like. Don't divide your methods or classes just for a sake of dividing them. Whatever refactoring you're about to do - do it only if you need it.

I believe this is from all the misunderstanding of TDD comes from - people have learned, that they should refactor their code always, no matter how it looks like. They forget, that they should use their intuition rather than blindly following all the rules.

The curse of the babble

We talk. We, as developers, software engineers - whatever you call us - we talk. We talk about implementation details, we talk about our toolset, we talk about performance issues. This this a part of our job - if you don't talk about your code, ideas or problems - you have a problem. To be honest, people are just designed like that - you can talk before you can write. However, there is a one specific "talk", which I believe is a curse and hits whole IT really hard.

Have you ever tried to introduce a new tool for your team? It can be a build server, a source control system or a new library. In most cases it is pretty easy - someone gives an idea, you discuss it, point possible problems. Maybe someone is more experienced with this tool and can decide whether it is a go/no-go. Mostly it is a moderate(or not - you know, each dev knows better) discussion and you can close it within an hour, no strings attached. You know why such discussions are the most definite ones? Because devs know the best, what they expect from a tool and what it can give a team.

On the other hand it is not always true, that a team decides. This is especially true for big companies, which involve tons of bureaucracy. You cannot decide on your own - you have to ask your manager, your architect and your director. There are some DevOps engineers and middleware specialists also. Don't forget to ask your mom, your wife and your dog. You have to ask everybody because everybody knows what you need better than you.

Have you mentioned everyone in your email requests? Good, now let them meet and talk. Let them babble, let them discuss all those things they hardly understand. Just imagine:

  • Dev: Hi All, we need a TeamCity instance accessible for us so we can test our .NET apps build process.
  • Mgr: Hi Joe Director, my team wants a TeamCity server so they can work with it.
  • Joe Director: Architect, don't we have such thing in our infrastructure?
  • Architect: No, we have Hudson only - they should be OK with it. Do they want a whole server? They have to ask our server team.
  • Dog: Bark, bark!
  • Dev: I said we want only a TeamCity instance + we want to build .NET apps...
  • Mom: Your grandpa gave a TeamCity your grandma instead of a wedding ring, I will try to find it...
  • Finance: It costs 1,999.00, we can't afford it this year.
  • Joe Director: What?! I have to pay  2000 for this Hudson server?
  • Wife: Are you getting  2000 extra this month? I'll go shopping, wow!
  • Dog: Bark, bark!
  • Mgr: Why do we want to test build process anyway? Can't you just use MSBuild?
  • Dev: We want to test the 'whole' process and by the way - TC is free!
  • Architect: Is it free? Is it enterprise enough? What about integration? Last year we bought enterprise ESB solution for $100K and since we haven't started to implement it yet, I have to know whether this SimCity will work with it.
  • Finance: SimCity? Can we also get it?
  • Dog: Bark, bark!

Sounds familiar? I think everyone knows that feeling.

They will talk for a month considering whether a tool you mentioned is needed for you. They will spend their time discussing, arguing and trying to prove, that they can or cannot afford it. They don't care, that they will spend money while talking. They will spend much more that your tool costs. Funny fact that they don't seem to care about it.