One of great things about conferences is discussions which are food for thought pretty frequently. For some reasons, probably because its not-very-big size, ACE Conference is specifically good at this.
Sometimes it’s as if you’re talking with someone about the project you know perfectly. You could spend hours talking why it was successful, failed or whatever outcome it brought, except no one is willing to listen about the project that much.
Anyway, you could bet that nothing is going to surprise you about the project. Like with real money. And then you have a chat with a nice guy, such as Marcin Floryan, and you talking about the project for whatever reasons and suddenly, completely out of the blue, you have epiphany.
Suddenly you ask yourself, or are asked, another why and you answer the question intuitively and you’re totally surprised with what you’ve just said. It’s like wow, that’s oh so obvious, how come I haven’t thought about it earlier? What a dumbass I must have been.
So thanks to Marcin I had this kind of epiphany. We were discussing one of my projects which, from technical perspective, was very successful. Now that you ask – yes, it was the project behind the Kanban Story, but that’s not a reason this time. The thing we were digging around was whether technical excellence is a good investment.
It’s a problem of many teams: there is much pressure over them so they retreat to the good old hacking instead of keeping good engineering practices or even introducing them in the first place. They incur technical debt which they usually pay back during stabilization phase or maintenance.
So what happens when we remove time pressure? I assume here we talk about at least a decent team and people who know their craft. In the very project we discussed it meant longer development but most of the time regression testing, deployment and maintenance went quickly and flawlessly. Given that we were deploying like once a week it would be a real nightmare if it was otherwise. But then I know projects where every deployment takes a couple of weeks and it’s just a long painful stream of epic fails.
If you’re working on the project and you care about code quality in a longer time span you actually start reducing costs, as no matter how application grows cost of regression testing, deployment and maintenance remains basically flat. On the other hand, in projects with big technical debt tend this cost is growing exponentially.
And this is exactly the point when you start winning.
Let’s take a few steps back then. Why are we winning? Because we have low costs related to the final parts of SDLC. Why is it so? Because we don’t really have any serious issues with deployment and maintenance. Why? Because the code is good-quality. Why the code is that good? Because we keep it that way with our best engineering practices. And the final why: why do we have all these practices in place? Because there was no time pressure so we were free to adopt them.
The last why was my epiphany. For some reasons I haven’t really asked myself about non-merit reasons of introducing, or not, best engineering practices. Well, we kind of know it’s good to adopt best practices, after all they have the word “best” in their name so they can’t be bad, can they? But then it is so common that teams deal with time pressure and they sacrifice engineering practices on the altar of fast coding, also known as the altar of crappy code.
So well, if I had to point the root cause of the success in this example I’d say it was reduced time pressure. And the funny thing is, in the long run we were more productive than we would be if we had to drop our engineering practices.
I don’t say lack of time pressure is universally good. Actually I know quite many people who just need time pressure to be productive, but if you assume a decent team of good craftsmen it shouldn’t really be an issue.