Devoxx 2012 was nice. 3400 nerds invading Antwerp to talk about new frameworks, languages, and geek out over a set of RaspberryPi‘s. But it also confirmed a new “pet peeve” this grumpy old architect is developing.
I am currently working on the largest, most challenging project my company has ever been in. It has a huge codebase, we’ve been working on it for over 3 years now, and it still is only partially live. During the past years, the market changed, the customer changed it’s mind, new tools and frameworks have come and gone.
People come and go too. New developers bring new ideas, new energy, new insights. But before they do that, they troll for a bit. Complaining about the used frameworks not being new and sexy, or the IDE not being to their personal taste. Or the versioning system not being Git. When solving problems, they trust their “instinct” more than they trust the documentation, only to learn the answer was in the documentation all along. It always takes a while for new developers to settle. Maybe it’s resisting to change. Maybe it’s outside their comfort zone. But the most important: Maybe it’s because it has problems they don’t have the answer to, and it scares them
Real projects have real problems. Scaling problems. Load problems. Stupendously boring problems. Problems which upset the customer. Problems that are hard to fix. Because we suck at it.
Most new languages and frameworks are aimed at solving the developer’s problem of having to build a solution fast. But they fail to help in building a fast solution. Because tools don’t solve these problems; good technicians do.
Frameworks need to be abstract to be usable. It’s up to us to make it fit the customer’s problem. Using big abstraction to build a screen on a single database table is not a real world problem. It generates piles of very generic, inefficient code.
Instead of constantly switching frameworks in chasing the performance promise, developers should understand how to buid efficient code, without hiding behind a framework or caching mechanism that supposedly solves that for them.
Firing a query on a database shouldn’t be easy. It should be hard. Because it generates load, and makes your application harder to scale.
I like learning new stuff as much as you do, but the reality of today is that fixing, refactoring and expanding an existing project is far more likely than creating a new project. A good developer learns new frameworks and languages. A great developer learns to understand the existing application, the customer and the problem at hand.
Learning or building a new framework is just procrastinating. Because fixing existing code is hard, and you don’t thoroughly understand why it is doing what it does.
Stop forking. Start fixing.
Aha, I dig this vibe. Not everybody understands that frameworks are created to solve problems, but that the problem it solves might not be the problem of the customer, but more the problem of the developers (specifically the _first_ developers).
Although I deal with the same things day in, day out, I find it very hard to come up with a good clean example to illustrate this. I think it would give more insight into the real complexity and challenges. But such an example would almost by definition be too large to be a simple example. Darn you paradox!
All this remind me of Alex’s Soapbox. (http://thedailywtf.com/Series/Alex_0x27_s_Soapbox.aspx), maybe there is some wisdom there.