Quite recently I've spend some time on discussing the development efficiency & how things have changed within last few years: you don't need whole development factory to achieve something meaningful. If you use modern tools & development techniques PLUS you have capable & motivated people you can achieve wonders using a small team. That's all true, but reality is much more complex, several additional conditions have to be met - some of them are about Development Agility.
The key point about the development agility is that its reduction is frequently caused by some kind of technical inertia, that may not be that easy to get rid of: legacy application, vast volumes of data, license restrictions. And that's why people who came to me were saying things like that:
Hey, I agree with what you've written, but we have to live with this database and nothing can be done without that.
or ...
Sadly, getting rid of that legacy code would take months - it's not feasible until late 2017, I believe ...
or ...
We just don't work this way here. We don't automate the tests because we've agreed to put more preasure on business features our management has promised to the client.
or ...
How can one test the End-of-Day procedure without executing the actual End-of-Day? That's why we need 3 actual days to manually re-test all the changes in this code...
When I hear things like that, I have two prepared answers:
Victimship
Those of you who know me personally are aware of how I hate all the corporate bullsh!t, including the corporate lingo. But there are some exceptions and this particular word is among them: The Victimship.
What's victimship?
Basically, victimship is looking for excuses instead of solutions. The excuses may be just & right - the situation is someone else's fault, there are objective factors that prevent us from doing something, increase the risk of difficulty level. BUT are you really doing everything you can to reach the goal? Aren't you stopping too early? Too easily? The goal is not to find a good excuse, but to actually make things happen -> it's always a team game and the more people share the same goals the better.
- Yes, this module has no unit tests. But they won't appear out of thing air ...
- Yes, this database is 15 GBs - but you can either cry or start doing something about that. Like RIGHT NOW.
- Yes, the process is fully manual, because no-one bothered yet. Wanna be the first one instead of b!tching on your predecessors?
- Yes, all the guys who have written this code do not work here anymore. Does it mean we should raze the things down to the core?
The worst thing you can do is to shrug:
Hey, it's not me who has screwed up in the first place. I have a good excuse.
But the second worst thing is to get discouraged because of the size or complexity of the problem:
Goddammit, it's 2200 classes & it takes 40 minutes to get compiled. Nothing can be done about that, let's just pretend we didn't notice anything. Move along!
The shit sometimes may be truly overwhelming, but in such case, I have another answer:
The Shovel Method
It's funny, but I've heard the same name from two different people, who didn't know each other (I think ...) - from the first one in 2003 & from the second one in 2006 or 2007. They have one thing in common though - they are both very smart & I think I've learned a lot from both of them. But to the point - what's the shovel method about?
Let's assume you're facing the huge, complex, sophisticated problem ...
- Visualize it as a humongous pile of dung in front of you ;D The pile you need to dig through
- Don't try to measure it ...
- Don't try to analyze it thoroughly (explore its structure, anomalies in density & composition) ...
- Don't meditate on how huge & inaccessible it is (we're never dig through all that crap...)
- ... instead of all of that:
- get the shovel from your back ...
- go straight to the pile ...
- ... and start swinging your shovel to get the crap behind your back - swing after swing, get this shit out of your way piece by piece
It's THAT simple.
Instead of analysis-paralysis & crying about how hard & burdensome things are - start doing something! The faster you start, the sooner you end. Just to make sure we understand each other:
- doing minor, meaningless improvements that has nothing in common with the actual constraint / bottleneck is just waste of time & effort
- not every change is an improvement, but there's not improvement without a change
- once you are convinced that you're right & able to defend your position - rather beg for forgiveness then for permission :)
- no-one says you need to fix whole world in one big bang - improve gradually, step-by-step, swing-be-swing ...
Yes.
Just. Do. It. (zillion trademarks violated ...)
